- 4.1 Goals of Agile Process Maturity
- 4.2 Why Is Agile Process Improvement Important?
- 4.3 Where Do I Start?
- 4.4 Understanding Agile Process Maturity
- 4.5 Applying the Principles
- 4.6 Recognition by the Agile Community
- 4.7 Consensus within the Agile Community
- 4.8 What Agile Process Maturity Is Not
- 4.9 What Does an Immature Agile Process Look Like?
- 4.10 Problems with Agile
- 4.11 Waterfall Pitfalls
- 4.12 The Items on the Right
- 4.13 Agile Coexisting with Non-Agile
- 4.14 IT Governance
- 4.15 ALM and the Agile Principles
- 4.16 Agile as a Repeatable Process
- 4.17 Deming and Quality Management
- 4.18 Agile Maturity in the Enterprise
- 4.19 Continuous Process Improvement
- 4.20 Measuring the ALM
- 4.21 Vendor Management
- 4.22 Hardware Development
- 4.23 Conclusion
This chapter is from the book
This chapter is from the book
This chapter is from the book
4.4 Understanding Agile Process Maturity
Agile process maturity can be understood in many different ways. The most obvious measure of agile process maturity could be in terms of the degree to which the practices adhere to the agile manifesto and the agile principles.5 I usually refer to this as a purity measure to indicate the degree to which the process follows authentic agile principles. As a consultant, I am usually called in to help with situations that are less than perfect. This pragmatic reality does change the fact that we want to approach implementing the agile ALM in a manner that adheres to and benefits from agile values and principles.
In order for this measure to be valid, we need to operationalize these principles. So let’s consider what following agile values and principles really means in practice and how we can strive for the most effective agile practices possible.
4.4.1 Adherence to the Principles
Mature agile requires that we adhere to the agile principles that we reviewed in Section 3.7. In this book we seek to educate you on software methodology in a way that empowers you to apply these principles and create a software lifecycle that is best for your project and your organization. One of the ironies that we often see is that some agile practitioners are the least “agile” people in the world, insisting on there being only one right way to become truly agile. I disagree, and we hope to share the best practices in creating an agile ALM that you can tailor to your own special requirements.
4.4.2 Repeatable Process
Agile processes, just like any other process, must be repeatable. It does not help to have an agile ALM unless it can be used repeatedly to achieve the desired results. We have seen many agile teams struggle with repeatability because they depended upon the guidance of individual players rather than understanding that agile is still a process that should yield the same results, regardless of who is performing the task—assuming the proper level of skills and training.
Agile process maturity should be understood in terms of repeatability. Another important issue is scalability.
4.4.3 Scalability (Scrum of Scrums)
Organizations often pilot agile methodologies in one particular group with spectacular results. The truth is that the participants in the agile pilot are often hand-picked and among the best resources in the organization. But agile processes must be scalable so that other teams within the organization can also be successful. We discuss the critical success factors for scalability throughout this book and then tie them together in Chapter 19, “Integration across the Enterprise.” If you want a scalable process, then you need to start by ensuring that your approach is comprehensive.
4.4.4 Comprehensive (Items on the Right)
Agile processes must be comprehensive so that everyone understands what needs to be accomplished, including interdependencies and deadlines. The agile manifesto aptly notes the following:
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.6
Mature agile processes value the items on the right so that we can ensure our processes are comprehensive, including processes and tools, comprehensive documentation, contract negotiation, and following a plan.
Comprehensive processes are essential, as are transparency and traceability.
4.4.5 Transparency and Traceability
Mature agile processes are transparent and traceable. Transparency is fundamental because you want everyone to understand what is being done and how their work impacts (and is impacted by) the work of others. You also want to be able to verify that steps have been completed. Processes that are transparent are easier to understand and follow, ensuring that everyone understands the rules of the road. Being able to go back and verify that each step was completed successfully is also essential, particularly when regulatory compliance is required. In addition, you want to be able to provide transparency to senior management through effective IT governance.
4.4.6 IT Governance
IT governance provides visibility into the organizational processes and existing operations so that senior management can make accurate decisions based upon the information that is available. I always explain to my colleagues that IT governance is essential because this function enables senior management to make the right decisions based upon accurate and up-to-date information. You can even look at IT governance as managing the right information “up” to those who are in the position of making decisions. In some large organizations, agile projects may be in progress at the same time as non-agile projects. Mature agile processes must be able to successfully coexist in these real-world hybrid environments.
4.4.7 Coexistence with Non-agile Projects
The elephant in the room for agile is the number of non-agile projects that exist within an organization that is working to implement agile. We have seen many organizations where existing non-agile projects were already underway, or perhaps existing team members were just not comfortable with taking an agile approach. Mature agile application lifecycle management often requires coexistence with non-agile projects. Coexistence is a sign of maturity, as is aligning with industry standards and frameworks.
4.4.8 Harmonization with Standards and Frameworks
Many organizations must follow the guidance provided in industry standards, including ISO 9000 or frameworks such as ISACA COBIT or the ITIL v3 framework. Mature agile processes can easily align and harmonize with the guidelines provided by these well-respected industry standards and frameworks. This includes meeting the requirements of Section 404 of the Sarbanes-Oxley Act of 2002 or safety standards such as those commonly required by the automotive, medical engineering, or defense industries. Mature agile helps improve quality and can align well with IT controls that are reasonable and appropriate.
The agile manifesto notes that it is more important to be able to respond to change than to simply follow a plan. However, mature agile processes must still be able to create adequate plans that will help guide the development effort.
4.4.9 Following a Plan
Planning is essential for the success of any significant endeavor. Too many agile enthusiasts erroneously think that they don’t need to create comprehensive plans to guide the software and systems development effort. The dark side of planning is that sometimes those creating the plan refuse to admit what they do not know. Mature agile processes plan as much as possible and communicate those plans effectively. Unknowns should be identified as risks, which are then mitigated as part of the risk management process. Many years ago W. Edwards Deming noted the importance of “driving out fear.” Agility admits when it does not have enough information to specify the details of a plan. Decisions are made at the “last responsible moment.” Mature agile processes embrace comprehensive plans but also do not attempt to plan out details that cannot yet be specified.
4.4.10 Continuous Process Improvement
Process improvement is a journey that must be continuously harnessed throughout the software and systems lifecycle. The mature agile process embraces continuous process improvement at both a deep technical level and at a pragmatic business level. Improving your technical processes is mostly focused on avoiding human error while maintaining a high level of productivity and quality. Improving your business processes can be a bit more complicated.
Do you make satisfying the customer through early and continuous delivery of valuable software your highest priority? Does your agile ALM process harness change for the customer’s competitive advantage and welcome changing requirements, even late in development? Your delivery cycle should favor shorter iterations, with delivering working software frequently, from every couple of weeks to every couple of months. Developers and businesspeople should be working together daily throughout the project. Projects are built around motivated individuals, and they are provided the environment and support they need and are trusted to get the job done. Information is best conveyed face to face, and working software is the primary measure of progress.
The agile ALM should help all the stakeholders maintain a constant pace indefinitely in what is known as sustainable development. There is also continuous attention to technical excellence and good design, including a focus on simplicity—the art of maximizing the amount of work not done. Self-organizing teams produce the best architectures, requirements, and designs. At regular intervals, the team reflects on how to become more effective and then tunes and adjusts its behavior accordingly. These principles have formed the basis of agile development for many years now. In order to understand them, you need to consider how to operationalize and implement these principles in practice. Then we will show how they fit into and, of course, facilitate the agile ALM.