The topic of Agile Process Maturity is gaining wide interest within the agile community. Although, Scott Ambler, the distinguished agile guru, has been quoted as saying, “It will be some time before the agile community is mature enough to embrace an agile maturity model,” [1] there are a number of other recognized agile experts who have also written about the need for an agile process maturity model. I don’t always like maturity models, but I do like mature processes. Years ago I wrote in the CM Journal: “Agile must mature into process methodologies that explain what each of the team members has to accomplish and by when.” [2] This is slowly happening today. My article will address what I believe we need to do in order to embrace agile process maturity.

How Agile Are You?
Are you really agile? It can be very difficult to gain consensus on what agility really requires. Obviously, embracing the Agile Manifesto’s [3] twelve principles is a good start. Your team could be considered agile if it consistently delivers working software that satisfies your customer. But the truth is that many teams embracing waterfall also develop great code that thrills customers. Similarly, motivation, healthy work environments, and self-organizing teams were around a long time before agile—as was holding meetings to review what works and what doesn’t—although we called them post-mortems instead of retrospectives. So, what exactly makes a process uniquely agile?

Uniquely Agile
Utilizing processes that are lightweight and low ceremony sounds like it would be more uniquely agile, and it is. Rapid iterative development is also found in other methodologies but clearly has a strong agile flavor. Embracing changing requirements, even late in development, is important along with making changes at the last responsible moment [4]. This latter principle is described in Lean Software Development, which shares many values with agile. Continuous integration with fixed timebox sprints gives the development process an agile orientation. So, how do you really know when you are agile?

You Know You Are Agile When
Agile environments have lots of face-to-face interactions, contact with end-users, and frequent releases. You know you are agile when you have a daily stand-up meeting (even though you have lots of chairs around), information radiators, and your requirements are described in epics and stories. Agile also values technical excellence, simplicity, and measures productivity using terms like velocity and burn down charts. All of this is true and reasonable, but I am going to describe a different view of what a mature agile process contains.

Mature Processes
Mature processes are well understood, fully traceable, and consistently implemented throughout the organization. With a mature process, stakeholders know exactly what they are supposed to do on a daily basis, and their managers know exactly what has been completed and what remains to be done. More importantly, mature processes manage risk effectively with full transparency to those above. IT governance means that senior management can make the right decisions based upon accurate and up-to-date information. I am going to take this a step further and suggest that agile process maturity should also coexist and align with non-agile development methods.

Co-existence with Non-agile
Maturity can also mean that your processes are able to function within the structure of an organization that may require a waterfall software or systems lifecycle. I have worked in many organizations where the day-to-day operations included daily stand-up meetings, rapid iterative development, and information radiators constantly disseminating the details of the development effort to all responsible stakeholders. Nonetheless, senior management received their status updates that allowed them to effectively communicate with venture capital executives putting up the money and members of the board of directors who had to review corporate data with analysts and stockholders alike. It is my view that this hybrid approach is becoming the norm and presents the best of both worlds. Yes, mature agile can function, when necessary, within a waterfall development environment, but this is only possible with the right amount of automation.

Automation and the ALM
Application lifecycle management (ALM) provides the needed structure to manage the entire software development lifecycle. Recently, I had the pleasure of being the technical editor for Mike Hüttermann’s new book on agile ALM [5]. This book provides a comprehensive description of open source and lightweight toolchains that automate the entire ALM process, from beginning to end. Automating the agile ALM process is essential and one of the prerequisites for a mature agile process. It is also essential to embrace all of the required functions.

It Is Time to Clarify the Items on the Right
The Agile Manifesto states: “While there is value in the items on the right, we value the items on the left more” [6]. Every project that I have worked on required processes and tools. Similarly, documentation is essential and, in my world, needs to be comprehensive. Planning—usually through a project management office—and signed contracts are also essential. I have not found clear and unambiguous support for how to manage these items on the right, and we need to match that with the same fervor that we focus on the items on the left: individuals and interactions, working software, customer collaboration, and responding to change.

Alignment with Standards and Frameworks
I work mostly with organizations that have comprehensive regulatory requirements and utilize industry standards (e.g., IEEE, ISO) and frameworks (e.g., Cobit, ITIL) to guide their daily activities. We need to develop agile standards that harmonize to non-agile standards and demonstrate that agile methods can be just as disciplined and reliable as non-agile methods. If you are interested in the effort to develop standards to support agile, then please contact me via my email address shown below Agile practices are extremely effective and can also harmonize with non-agile practices described in existing industry standards and frameworks.

Conclusion
Agile has blossomed and provides tremendous value in terms of facilitating improved quality and productivity. Agile works, but it will provide even more value as it matures into a repeatable and sustainable process model. We all owe a dept of gratitude to those whose leadership helped pave the way for agile to go mainstream. I am working on another book that will discuss agile process maturity and would love your feedback on both my views on this topic as well as your own!

[1] Email exchange on September 5, 2011

[2] CM Journal, January 2008, Behaviorally Speaking by Bob Aiello (http://www.cmcrossroads.com/cm-articles/cm-journal/9995)

[3] http://www.agilemanifesto.org/principles.html

[4] Learn constantly - Learn as much as possible before making irreversible decisions http://www.poppendieck.com/

[5] Hüttermann, Michael. Agile ALM: Lightweight tools and agile strategies. Manning 2012

[6] http://www.agilemanifesto.org

[7] Aiello, Robert and Leslie Sachs. Configuration Management Best Practices: Practical Methods that Work in the Real World. Addison-Wesley, 2010.
 

Trackback(0)

TrackBack URI for this entry

Comments (3)

Subscribe to this comment's feed

David Chassels said:

... This may be a surprise for technical led people but business logic has never changed since commerce started; indeed business is actually quite “simple” if you focus on supporting people at work where all information is created. The communication technologies to deliver are both complex and challenging but do not change the fundamentals of business; it is about people, internal and external to the organisation and IT is there to support secure delivery. When you look at how people work irrespective of the required function there are relatively few work task types, human and system, including the user interface that address all business driven issues? So why repeatedly recode for every function in a business? It has been proven in action the biggest challenge being describing what it is in the context of the current complexity and getting good folk like you to believe! It is the first enterprise level “agile software” and a new alternative to COTS and custom coding. As for my vision I believe this is the start of commoditising business software; a step change long over due?

report abuse vote down vote up

October 23, 2011
Votes: +0

Bob Aiello said:

... Hi David, I am not sure what you mean by "only" a methodology. Yes - there are software development methodologies. Independent from that is the issue of whether or not there is a gap between business and IT. Obviously, Agile brings a lot to the table when it comes to bridging the gap between business and IT. Who said that we are coding business logic that never changes? I always assume that anything can change. I am not sure how you would remove coding from the business application build. We have been trying to make programmers more productive by creating frameworks for application development since the days when I used tweezers to remove cards from the card readers. (I am not that old but I worked for a non-profit with an old IBM 360/30 :-) I don't agree that we need to remove coding from the application build and I don't believe that we get good code that way. What is your vision (channeling Steve Jobs now :-)

report abuse vote down vote up

October 23, 2011
Votes: +0

David Chassels said:

... Agile is only a methodology and is treating a symptom not curing the illness of the gap that exists between business and IT. Why in the 21st century are we still coding business logic that never changes? What is needed is a complete change in how we build applications. In 2008 Bill Gates said “future applications should use only around 10% of the code that is used today” seeing this as “the holy grail of development forever”. So let’s focus on the cure remove coding from business application build. What is needed is “agile software” build flexible custom solutions no coders – its long over due and brings business software into the commodity market like the rest of “IT”?

report abuse vote down vote up

October 23, 2011
Votes: +0

Write comment