The packaging of ideas represented by “agile” includes elements pertaining to organizational culture and elements pertaining to processes and practices. Although many of us would like to see organizations adopt useful elements in both areas holistically, in my experience it is not the case that the two are welded together. Instead, cultural aspects and mechanical aspects affect work flow and outcomes differently and independently.
In most organizations that have adopted “agile” methods, people have embraced a subset of the mechanical elements of “agile” development, but they have no understanding of the cultural aspects and, in many cases, no interest. Yet, I think it’s fair to say they are “using” or “doing” agile development. It’s definitely possible to employ some of the mechanical aspects of “agile” development in the context of an otherwise-traditional organizational structure and culture. It’s happening all over the world right now. Because of this reality, I often use the word “agile” to refer only to the mechanical aspects. I sometimes run afoul of agile practitioners because of this.
When I suggest that the use of “agile” methods does not automatically mean we are doing adaptive development, some agile practitioners protest. A recent discussion on Twitter that began with a comment about “respect for people” highlighted this difference in perspective. I’ve been pondering the question since the exchange on Twitter, and it seems to me the reason for the friction may be that others include a wider range of ideas than I under the umbrella term, “agile.” I do understand that in principle “agile” implies both cultural and mechanical aspects. In practice, though, the two can be independent and have different effects on outcomes. If we ignore that reality, we stand to miss something important in our work.
I appreciate the cultural aspects of “agile” thinking, and I have seen them have a profound, positive effect. However, it is more typical for organizations to implement just some of the mechanical aspects of “agile” development without changing their culture or underlying assumptions about management, people, or work flow, and they achieve improvement over whatever they had been doing previously. At the same time, it is not uncommon for an organization to have many of the cultural attributes associated with the “agile” school of thought without implementing any of the mechanical aspects. They, too, seem to get their work done. It seems clear to me that the cultural and mechanical aspects are orthogonal. I think there is value in being able to separate the two when we analyze the conditions in an organization.
When it comes to adaptive development, I’ve learned over the years that the primary determining factor is not the process model, technical practices, or organizational culture; it is the way the money flows. Things always happen according to the way the money flows. When we have a predefined, fully-allocated budget up front, then using incremental methods for the rest of the work will have a relatively small effect. We could call it BBUF — Big Budget Up Front. The mechanical aspects of “agile” development provide a better-lubricated approach to embracing change than traditional change control procedures, but they can’t rise to the level of adaptive development when they are constrained by BBUF.
Here is one anecdotal example. I worked on a project for a mid-sized client, along with another coach and several technical people from an “agile” consultancy who were skilled at XP practices and were good technical mentors. “Agile” was new to the company, and they went about it in a very rational way. They created team work spaces and adopted all the necessary practices, including team collocation, poly-skilled teams, and direct stakeholder participation. They were more open-minded about doing things differently than most organizations that first experiment with “agile” methods. It was a promising start.
But the budget allocation was fixed in advanced, and was approved by an executive committee that normally met once per year. The primary professional qualification to become a member of the budget committee was humorlessness. Any changes to the budget had to be approved by the same committee in special session. It was a big deal to ask for this sort of special session and a very uncomfortable position for a manager to be in. So, managers tended to work around it.
The inflexibility of the funding model was the only non-“agile” factor in the situation. It channeled all management decisions about the projects undertaken by the two teams. One of the projects had originally been envisioned as two separate projects. Early on, we determined they could be combined and handled by one of the teams. Throughout the project, which lasted for several months, all management reporting had to be split in two and allocated to the two separate budget buckets that had been originally defined. It was procedurally too difficult to reframe the budget to fund a single project.
Another side-effect of BBUF in this case was that the high-level feature list (or Product Backlog) was effectively treated as a traditional Work Breakdown Structure (WBS) — that is, it was treated as the complete and final definition of 100% of scope. In turn, that caused our measurements of velocity to be reduced to nothing more than a status report of percentage of scope completed to date. Whenever there was a need to “adapt,” stakeholders perceived it as “scope creep.” Nothing “adaptive” about it.
Much of the potential value of the “agile” approach was lost. Things still moved along better than would have been possible using other methods and both projects were ultimately delivered, but it was definitely not adaptive development, although that had been management’s original goal.
This isn’t a new concept. An approach to management called Beyond Budgeting has been taking hold in Europe over the past several years. Among other things, it calls for incremental funding based on periodic decision points when people re-assess the risks, costs, and potential return of all initiatives in flight. An approach like that keeps the available funds liquid until the last responsible moment, and enables people to increase or decrease the funding level, priority, and resource allocations of initiatives based on emerging business realities. That’s what I call adaptive. If you aren’t doing that, then you probably aren’t really doing adaptive development even if you are following some sort of “agile”-friendly process.
You make a good point about the term agile having multiple interpretations. Truly agile software development teams require that the entire business be agile, not just the technologists. Many people discover (the hard way) that getting everyone on board the agile train is very hard to do.
As for budgets, I believe that budgets and dates should be frozen. Software features, hopefully in the form of user stories, should be allowed to float. When time or money runs out, the project is over. If agile principles have been properly applied, the software should be ready for delivery. It may not contain all of the features that every person wanted but it should be good enough. That’s agile.
yep – just like “deep throat” used to tell Woodward and Bernstein, “Follow the money!”. The bottom line is that the funding model cant differ too drastically from the lifecycle-model.
However, there are those in the Agile and SE communities that have been making some headway on this. There is the Incremental Funding Model (IFM) proposed by Mark Denne and Jane Cleland Huang in their book “Software by Numbers”, as well as subsequent work by Barry Boehm on the so called “Incremental Commitment Model” (now if only we could get them used more often – or perhaps that is a bit of a chicken-and-egg problem)