- Overview
- Thinking Lean
- Embracing Agility
- Applying the Agile Manifesto at Scale
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
Embracing Agility
The right half of the Lean-Agile Mindset is, of course, Agile. In chapter 1, “Business Need for SAFe,” we introduced the Agile Manifesto. It provides the foundation for empowered cross-functional, self-organizing, self-managing teams. The rest of this chapter is devoted to it.
The Values of the Agile Manifesto
Figure 3-2 illustrates the Agile Manifesto and is followed by a description of its four values.
)
Figure 3-2. The Manifesto for Agile Software Development
We Are Uncovering Better Ways
The first phrase of the manifesto deserves emphasis: “We are uncovering better ways of developing software by doing it and helping others do it.”
We interpret this phrase as an ongoing journey of discovery to increasingly embrace Agile behaviors, a journey that has no ending. SAFe is not a fixed, frozen-in-time framework. As soon as we uncover better ways of working, we adapt the framework, as evidenced by more than four major releases as of this writing.
Where We Find Value
We’ll discuss the values shortly, but the final phrase of the manifesto is important and sometimes overlooked: “That is, while there is value in the items on the right, we value the items on the left more.”
Some people may misinterpret the value statements as a decision between two choices (for example, working software versus comprehensive documentation). But that is not the intent. Both items have value; however, the item on the left has more value (for example, working software). The Agile Manifesto is a mantra for us not to be rigid or dogmatic in our approach but instead to embrace the need to balance the values depending on the context.
Individuals and Interactions over Processes and Tools
People build software and systems, and that requires teams to work together effectively. Processes and tools are important, but they do not replace individuals and interactions.
With respect to process, Deming notes, “If you can’t describe what you are doing as a process, then you don’t know what you are doing.” So, Agile processes in frameworks like Scrum, kanban, and SAFe do matter. However, a process is only a means to an end. When we’re captive to a process that isn’t working, you may know “what you’re doing,” but “what you’re doing may not be working.” So, favor individuals and interactions and then modify processes accordingly.
In a distributed environment, tools are critically important to assist with communication and collaboration (for example, video conferencing, instant messaging, ALM7 tools, wikis), especially at scale. However, tools should not be used as a substitute for regular, face-to-face communication.
Working Software over Comprehensive Documentation
Documentation is important and can provide great value (for example, user help, models, story mapping, regulatory/compliance documentation). However, creating documents for the sake of complying with outdated corporate governance models does not provide value. As part of a change program, governance needs to be updated to reflect the Lean-Agile way of working.
Software requirements specifications are tricky, and one could assume that the authors of the manifesto were particularly concerned about them. Too often, they cause Big Design Up Front (BDUF) and project delays consistent with waterfall thinking. They frequently constrain development to overly detailed written specs that are not always practical (or desirable) to implement. Moreover, people usually do not know what they want until they see it working in action.
Therefore, it’s more valuable to show your customer working software and get fast feedback, rather than create comprehensive documentation (especially the wrong kind) too early in the process. The goal of software development, after all, is to create innovative solutions, not a library of documents. Therefore, favor working software. Document only what’s necessary.
Customer Collaboration over Contract Negotiation
Customers are the ultimate deciders of value. Determining value requires close collaboration on a daily basis. Contracts are often necessary for communicating and agreeing on the rights, responsibilities, and economic concerns of each party. But all too often, contracts over-regulate what is to be done and how to do it. No matter how well they’re written, contracts are not a replacement for regular communication, collaboration, and trust. Contracts should be written to be win-win propositions. Win-lose contracts usually result in poor economic outcomes and distrust, creating short-term relationships instead of long-term business partnerships. Favor customer collaboration.
Responding to Change over Following a Plan
Change is a natural part of software and systems development, a reality that must be reflected in the process. The strength of Lean-Agile development is in how it embraces change. The process of product development is about converting uncertainty to knowledge. As the system evolves, so does the understanding of the problem and solution domain. Business stakeholder understanding also improves over time, and customer needs evolve as well. Indeed, this variability adds value to our system.
Of course, the phrase “over following a plan” means that there actually is a plan. Planning is an important part of Agile development. Indeed, Agile teams and programs plan more often and more continuously than teams using a waterfall process. However, plans must be adaptable as new learning occurs, new information becomes visible, and the situation changes. Worse, measuring conformance to a plan drives the wrong behaviors (following the plan over empiricism) and should be avoided.
Agile Manifesto Principles
The manifesto has 12 principles that support its values. Listed here, the principles take the values one step further and describe more specifically what it means to be Agile:
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
Working software is the primary measure of progress.
Deliver working software frequently within a couple of weeks to a couple of months, preferring a shorter timeline.
Business people and developers must work together daily throughout the project.
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
Continuous attention to technical excellence and good design enhances agility.
Simplicity—the art of maximizing the amount of work not done—is essential.
The best architectures, requirements, and designs emerge from self-organizing teams.
At regular intervals, the team reflects on how to become more effective, and then fine-tunes and adjusts its behavior accordingly.
Most of these are self-explanatory, so no further elaboration is needed, except for a discussion of applying the Agile Manifesto at scale, covered next.
This combination of values and principles in the manifesto creates a framework for what the Snowbird attendees believed to be the essence of Agile. The industry is the recipient of the extraordinary business and personal benefits of this new way of thinking and working. We are grateful.