- Overview
- Thinking Lean
- 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
Thinking Lean
Lean was originally developed to streamline manufacturing.1 However, the principles and practices of Lean thinking are now deeply embedded and extensive in software, product, and systems development. For example, Alen Ward,2 Don Reinertsen,3 Mary and Tom Poppendieck,4 Dean Leffingwell,5 and others have reframed Lean thinking in the product development context. Combined with these ideas, we developed the SAFe House of Lean (described next), which was inspired by the Toyota ‘House of Lean’ and others.
Goal: Value
The ‘roof’ of the house represents value and the goal is to deliver the maximum value in the shortest sustainable lead time, while providing the highest possible quality to customers and society. High morale, emotional and physical safety, and customer delight are also goals with economic benefits.
Pillar 1: Respect for People and Culture
By itself, a Lean-Agile approach cannot implement or perform any real work. Indeed, people do all the work. Respect for people and culture is a basic tenet of Lean. SAFe enables people to evolve their own practices and improvements. Management challenges them to change and may guide them. However, individuals and teams learn problem-solving and reflection skills and are accountable for making the appropriate improvements.
To evolve into a Lean organization, the enterprise’s culture will need to change substantially. Respect for people and culture should also be extended to relationships with suppliers, partners, customers, and the broader community; all of those parties are vital to the long-term success of the enterprise. When there’s real urgency for change, culture improves naturally. First, understand and implement SAFe values and principles. Second, deliver winning results. Cultural change will surely follow.
Pillar 2: Flow
The secret to successfully implementing SAFe is to establish a continuous flow of incremental value delivery based on continuous fast feedback and adjustment. Continuous flow enables quicker value delivery, effective built-in quality practices, constant improvement, and evidence-based governance.
The principles of flow are an important part of the Lean-Agile mindset:
Understanding the full value stream
Visualizing and limiting Work in Process (WIP)
Reducing batch sizes
Managing queue lengths
Additionally, a Lean organization focuses intensely on reducing delays and eliminating waste.
Pillar 3: Innovation
Flow builds a solid foundation for value delivery. But without innovation, both the product and the process will rapidly decline. To foster innovation, Lean-Agile leaders must do the following:
Understand and implement the Japanese concept of ‘Gemba,’ which advises management to ‘get out of the office’ and into the workplace. The workplace is where actual value is produced and products are created and used. As Toyota’s Taiichi Ohno has said, “No useful improvement was ever invented at a desk.”
Provide a regular time and space for people to be creative. Time for innovation must be purposeful and become part of the regular development rhythm. SAFe’s Innovation and Planning (IP) iteration provides one such opportunity.
Avoid the trap of focusing solely on the ‘tyranny of the urgent’ iteration. Innovation cannot occur with 100% utilization and constant firefighting.
Apply innovation accounting6 to establish early, nonfinancial, actionable metrics that provide fast feedback on the important elements of the solution’s new concepts, features, and its associated business model.
Validate innovations with customers and then ‘pivot without mercy or guilt’ when the hypothesis needs to change.
Pillar 4: Relentless Improvement
The fourth pillar is relentless improvement. It guides the business to become a learning organization through continuous reflection and adaptation. A ‘constant sense of competitive danger’ drives the aggressive pursuit of improvement opportunities. Leaders and teams systematically do the following:
Optimize the whole, not just the parts, of the organization and the development process.
Consider facts carefully and then act quickly.
Apply Lean tools and techniques to determine the root cause of problems and apply effective countermeasures quickly.
Reflect at key milestones to openly identify and address process shortcomings at all levels.
Foundation: Leadership
The foundation of Lean is leadership, the starting point of team success. The enterprise’s managers, leaders, and executives are responsible for the adoption and success of the Lean-Agile paradigm. To be successful, leaders must be trained in these new and innovative ways of thinking and exhibit the principles and behaviors of Lean-Agile leadership.
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, the foundation for cross-functional, self-organizing, self-managing teams. The second half of this chapter is devoted to this critical element of SAFe.
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. 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 as describing an ongoing journey of discovery to increasingly embrace Agile behaviors, a journey with no end. 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 five major releases as of this writing.
Where We Find Value
We’ll discuss the values shortly, but the final phrase of the manifesto is also 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 binary decision between two choices (for example, working software versus comprehensive documentation), but that’s not the intended meaning. Both items have value; however, the item on the left has more value (for example, working software). The Agile Manifesto is not rigid or dogmatic. Instead, it embraces the need to balance the values based on the context.
Individuals and Interactions over Processes and Tools
Concerning 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 you’re captive to a process that isn’t working, then you may know what you’re doing, but ‘what you are doing’ may not be working. So, favor individuals and interactions, then modify processes accordingly.
In a distributed environment, tools are critically important to assist with communication and collaboration (for example, video conferencing, text messaging, ALM7 tools, and wikis). This is especially true at scale. However, tools should not replace face- to-face communication.
Working Software over Comprehensive Documentation
Documentation is important and has value (for example, user help, system models, regulatory/compliance documentation). But creating documents for the sake of complying with potentially outdated corporate governance models has negative value. As part of a change program, governance, as reflected in part by documentation standards, needs to be updated to reflect the Lean-Agile way of working.
One form of documentation, software requirement specifications, is particularly tricky, and one might assume that the authors of the manifesto were concerned about their over-constrained effect. Too often, requirement specifications cause Big Design Up Front (BDUF) and project delays consistent with waterfall thinking. They frequently constrain development to overly complicated specifications—early, ‘fixed point’ solutions—that are often impractical to implement.
Rather than create detailed documentation too early—especially the wrong kind—it’s more valuable to show customers working software to get their feedback. Therefore, favor working software. And document only what’s necessary.
Customer Collaboration over Contract Negotiation
Customers are the ultimate deciders of value, so their close collaboration is essential in the development process. To convey the rights, responsibilities, and economic concerns of each party, contracts are often necessary—but recognize that contracts can over-regulate what to do and how to do it. No matter how well they’re written, they don’t replace regular communication, collaboration, and trust. Instead, contracts should 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. Instead, favor customer collaboration. An approach to more agile contracts is highlighted in chapter 17, ‘Lean Governance.’
Responding to Change over Following a Plan
Change is a reality that the development process must reflect. The strength of Lean-Agile development is in how it embraces change. As the system evolves, so does the understanding of the problem and the solution domain. Business stakeholder knowledge also improves over time, and customer needs evolve as well. Indeed, those changes in understanding add value to our system.
Of course, the manifesto phrase “over following a plan” indicates that there is in fact a plan. Planning is an important part of Agile development. Indeed, Agile teams and programs plan more often and more continuously than their counterparts using a waterfall process. However, plans must adapt as new learning occurs, new information becomes visible, and the situation changes. Worse, evaluating success by measuring conformance to a plan drives the wrong behaviors (e.g., following a plan in the face of evidence that the plan is not working).
Agile Manifesto Principles
The Agile Manifesto has 12 principles that support its values.9 Listed here, these principles take those values a step further and specifically describe 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.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference for the shorter time scale.
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.
Working software is the primary measure of progress.
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 tunes and adjusts its behavior accordingly.
Most of these are self-explanatory. They need no elaboration, except for a discussion of applying the Agile Manifesto at scale, which is covered next.
The combination of values and principles in the manifesto creates a framework for what the Snowbird attendees believed was the essence of Agile. The industry is the better for the extraordinary business and personal benefits conferred by this new way of thinking and working. We are grateful for it.