With the all the hype in recent years regarding Agile software development, one does not have to look very far to find a team or organization claiming to be Agile when in fact their methodology is anything but Agile. Recently, I was discussing this phenomenon with a colleague. The conversation focused how Agile should be defined. What is the true test as to whether or not an engineering team is Agile? What does it mean to be Agile? I thought I would take a few minutes and share with you what it means to me.
There are many Agile-like characteristics which can be evaluated as to a team’s level of agility. However, I believe there are three key principles that must exist in order for a team to be Agile.
When your Agile project starts have you committed to a fixed set of features using a fixed set of resources to be completed on a fixed date? If the answer to this is “Yes”, then it is impossible to be Agile when making changes to the project scope to ensure a high-quality on time release. Sure to be controversial, it is my belief that projects with these three variables fixed simply cannot be Agile.
Does your project include a series of increments or iterations that require the completion of “releasable” or “working” software” (defined, developed, and tested) at the end of each increment? Completing working software in an incremental approach enables the team to re-evaluate the project scope at the end of each iteration. This is the foundation for having the ability to make decisions at the end of each iteration. If none of the features are complete and tested until the end of the project, it is too late to re-asses and ensure an on-time successful release.
Does your project allow for the team members to operate in an empowered fashion in which each team member has some ability to influence the methodology and engineering practices? One of the key principles in Agile is believing the people who manage and build the project day to day know the most about the changes that need to be made. If the team does not have the empowerment to self-adjust then there is no mechanism to be Agile.
While it is true most Agile methodologies call for much more than these three items, these represent (in my opinion) the foundation for operating in an Agile way. Adherence, to these key principles as one transitions to Agile is critical to the long term success of the transformation. In short, “Variability”, “Incremental Completion”, and “Empowerment” are the most critical Agile characteristics. All other Agile concepts support at least one of these. For example, automated testing enables incrementally releasable software.
So, is it possible to be half-Agile? It may very well be. However, projects not containing the three principles above will struggle to be successful with their transformation to this new and exciting methodology.