I recently went to a seminar in Durham on Agile Development Methodologies. This seminar was sponsored by AccuRev and Anithillpro (UrbanCode). I learned a little bit, some of my core beliefs were re-enforced, and I was a bit surprised by the level of Agile development my company was at compared to other companies that were represented at the seminar.
So, first of all, for those not acquainted with the term Agile, here is a link to wikipedia’s description and below is the Agile Manifesto. I have been told that any presentation on Agile should include the Agile Manifesto. So, while this is not a presentation, I believe it to be valuable to see it in black and white.
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
There is also the related “Twelve Principles behind the Agile Manifesto”.
So what did I learn in this brief seminar? One of the main take-aways from the seminar was directly related to the last line of the Manifesto. This was probably skewed a bit because the seminar was sponsored by a tools company. But, I learned that the items on the right are important so long as they support the items on the left. That is, if someone tells you that they are doing Agile therefore they do not use tools, write documentation, or plan their design. They are not doing Agile. Tools, Documentation and Design are very important, so long as they support the items on the left.
What were some of the things that helped re-enforce my core beliefs? First, Agile requires management and executive by-in and participation. Too often a team that practices Agile Development falls flat. One reason for this is that the management and executives either, 1) do not have by-in to the process and do not promote the process. Or, and what I believe to be the worse of the two scenarios, 2) they do not participate in or own the process. The success of any development methodology hinges on management and executive participation.
Second, and related, is the priorities of the development team need to be clearly represented and talked about daily. The Product Owners are key to making this happen. If a Product owner is successful at transforming executive Value Story Cards to Story Cards for the development team and move them through the swim lanes, then the project has a great chance for success. If this is difficult for the Product owner and priorities are not clear, the team is doomed. If the executive wants this specific feature to be a part of this sprint then the Product owner needs to be adept enough to help the executive decide what feature will NOT be a part of that sprint. This is a give and take. I believe this to be one of the most challenging aspects of Agile to overcome.
What surprised me? Well, in short, I was surprised by how much further along my company is in practicing Agile Methodologies than most of those organizations represented at the seminar. And yet, how far away we are from implementing some of the key principles. I am excited that we are moving closer to adopting these principles but the realist in me knows that we have a ways to go. Especially in the area of priority setting. We continue to learn and move closer, like most teams. And, I am encouraged.
The Agile Manifesto is an important step in the evolution of Software Engineering. When an organization follows the principles associated with the Manifesto there is no limit to what they can accomplish.
Tell next time…
