Does a little Agile go a long way or is Agile an all-or-nothing proposition? For companies confronting the inadequacies of traditional software development methods and looking at alternatives, this is an important question.
Agile is certainly an attractive process to companies that want to respond quickly to their customers’ needs, adapt to rapidly shifting environments, and accelerate the time it takes to develop and ship new or improved products. But, it also represents a major shift in thinking—especially when traditional attitudes about software development are ingrained deeply among the members of a development team.
With the size of those teams often reaching into the hundreds and even thousands, some companies are warily eying the task of shifting the thinking of that many people and asking, “How much Agile do we really need?” Is it possible to realize some of the benefits of the Agile methodology without going “all in”?
Everybody on Board
For an Agile project to work, everyone involved with the project needs to be on board with Agile. If someone in the chain of stakeholders is not, eventually, something will go wrong. If the entire company is following the Agile methodology, that chain might need to extend on up to the business stakeholder, which, for a smaller company, could even be the CEO. Because Agile is such a radical departure from the traditional approach to software development, it can only be effective if everyone is speaking the same language.
Here are some of the key concepts everyone in an Agile process should understand:
Things Could Change
In contrast to the traditional development process, in which a single product has several set-in-stone requirements at the outset, without consideration that they might change, Agile calls for more flexible goals. Features may change over the course of the project, and if anyone involved is not prepared for that—is expecting the features to remain well-defined from start to finish—it could cause confusion for this person and the entire team.
The Product Owner
The product owner is an extremely important role in the Agile process because product owners speak for the customers. They are the ones who identify which features of a product will deliver value to the business and which are less important. Unfortunately, lack of a product owner or the unavailability of a product owner is a common failing of many Agile projects. If the product owner is too busy to answer questions, or doesn’t understand his or her role, the team will lack the critical information they need to keep their work on the right track and the product will begin to drift away from what the business and the customer really needs.
The backlog, according to the Agile methodology, is the ongoing list of requirements for a product. It can include features as well as bug fixes—anything deemed necessary for the product. The key to working with a backlog is to not let it stagnate. The backlog should be continuously reviewed and prioritized according to the business value of each item. Anything in the backlog that is no longer valuable should be discarded, for example, an older technology made obsolete by a newer one. Careful backlog maintenance will ensure a team’s energy is directed only towards work that creates value.
Collaboration is the engine that powers Agile. The continuous feedback and sharing of knowledge drives the process forward. When “heroes” try to go it alone, keeping information for themselves and ignoring aspects of the project that fall outside their specific areas of expertise, this engine comes to a halt. Sometimes these heroes are just stuck in their ways. They figure what’s worked for them before should always work. But fortunately, more often, hero syndrome is just a symptom of a lack of understanding. Once these heroes understand how they can benefit from the sharing of others, they’ll be more apt to collaborate themselves.
The Definition of ‘Done’
There’s done—when the bulk of the work required for a certain task is completed—and there’s what we call “done done.” “Done done” is when a task is really completed. This is when it has reached the common definition of what a finished task should be and the team member can move on to something else. For example, “Your task is done when your commit your source code to SVN.” Or, “Your task is done when you pass the acceptance criteria.” Whatever it is, the definition of “done” should be understood and adhered to by all members of a team, otherwise sprints will end with incomplete tasks and will fail.
To return to the question with which this article began, how much Agile is enough Agile? Clearly, there are certain elements without which the Agile methodology is ineffective. The five identified above are some of the most critical.
Still, it is possible to implement Agile on the small scale and grow from there. One of the best ways to do that is to isolate a small cell within a larger traditional software development environment and use Agile for that project (or element of a project) alone.
For example, on a recent project, we worked with a software team that had become accustomed to traditional development methods. We were finding it difficult to get the entire team working according to the Agile methodology. So, we split the team in half, one using Agile, the other not. As the Agile team demonstrated the value of the process, we gradually increased its size and decreased the size of the traditional team, until everyone was on board with Agile.
Then things really started to move.
By starting with small, self-contained Agile units, and scaling up, companies can benefit from the Agile methodology without the difficulty of implementing it before everyone is ready to get on board.