Understand the value stream is the workflow, not the people in the workflow, from concept to consumption of value.
Attend to the entire value stream. If you don’t get cooperation of portfolio or product management, make the cost of this visible.
Use Minimum Business Increments (MBIs) when enhancing existing products. Use MVPs for what they were intended for – discovering if you have new products. Don’t confuse the two.
Create semi-autonomous teams that have all the skills required to create the MBIs.
Do your PI planning by focusing on removing delays in workflow in the completion of MBIs. This lowers waste while lowering cost of delay.
Use dependencies identified in PI planning to Improve your organization’s value creation structure
The guardrails are our agreements with each other across the enterprise. Each role and phase, however, manifests these agreements in different ways. The following provides more detail on what the guardrails mean during implementation and integration.
Promise: Create psychological safety
Safety on a team is very important. People should be able to safely disagree with decisions even they are to abide by them after being made. Also, quality issues must be able to be safely pointed as. If estimation is being done people should be able to freely discuss their beliefs without fear of repurcusion. Safety often takes additional time to foster, but it results in better results as well as a much better work environment.
Promise: Accelerate value realization
When teams need to work together, they should focus on getting the most business value ready to be realized.
Promise: Collaborate proactively
Collaboration is key. One team cannot refuse to help another team if what the other team is working on is of more value to the organization. This helps teams look at the bigger picture.
Promise: Make all work and workflow visible
The work of the teams must be made visible so other teams can see both what is coming their way and how their work will affect others.
Promise: Increase predictability
Much of the waste created is from work being done across teams. Each team must attend to how its work affects others.
Promise: Keep workloads within capacity
Each team must include planned and expected requests from others. They should also respect the workload of other teams that they make requests to.
Promise: Improve Continuously
Teams are not just to improve themselves, but to help teams in the value stream they work in as well.
The primary responsibilities of an executive in a transformation to Lean and Agile include (1) defining and reinforcing the objectives for the transformation, (2) establishing guardrails that keep the transformation “within bounds,” (3) ensuring that the effort gets the necessary level of resources and support, and (4) providing feedback at the level of the entire system, something that only an executive can provide. This article provides the barest bones of explanation; each responsibility will get further attention, in turn, in other articles in this clinic. Continue reading “What Is the Executive Role in Lean and Agile?”
SAFe is a very practical approach to applying Agile in mid- to large-scale organizations. This is in large part because SAFe implements a number of practices derived from Lean, and that have proven effective in these larger organizations. This article describes how SAFe implements several of these practices. Continue reading “Why Is SAFe Popular?”
Ken Pugh and Jim Trott talk about ATDD: who is involved and who leads the effort, what is involved in writing acceptance tests, how ATDD compares with regular “analysis” you have done in the past, how ATDD compares with TDD, and the language of Acceptance Tests. Ken describes why he is so passionate about ATDD and the tangible benefits he has seen with his customers. They wrap up with some practical ways you can learn more about ATDD and what Ken has in store next. Continue reading “Acceptance Test-Driven Development: A Quick Introduction”
Agile and Lean transformation compels profound and often unexpected changes to an organization. If you carry out other re-organization plans at the same time that you are undergoing this transformation, you will dilute the benefits of Agile and Lean, complicate and prolong the timeline for their adoption, and set up unnecessary conflicts. Continue reading “Should I Put Re-organization Plans on Hold?”
Steve Thomas and Jim Trott talk about internal coaching in Lean-Agile transformations: why coaches are needed, what is involved, the difference between internal and external coaches, who makes good coaches, can manager make good coaches, how to develop internal coaches, coaching as a career, and metrics to use. Continue reading “Bringing Your Internal Coaching to the Next Level”
Frequently, middle managers have struggled to find their place in an Agile transformation. If we add Lean to the mix, it becomes easier to see the role that these managers need to play. Maintaining flow and increasing the capacity of the team are the two primary contributions that a middle manager can make. Continue reading “What Is the Role of Middle Management in Lean and Agile?”
No framework will ever fit a specific organization without some custom tailoring. Organizations are complex systems, with many superficial similarities. However, as experience implementing frameworks shows, there will always be some need to adjust the framework to accommodate the structure, culture, skills, and other important traits of a specific organization. Therefore, leaders and managers need to incorporate these adjustments into their transformation strategy. Continue reading “How Easily Can We Import a Lean or Agile Framework Into the Organization?”
The team is responsible for its process. Teams employ their local knowledge about what is required to do their work, complementing required enterprise standards. The team agrees to use and improve its own processes. Processes exist to serve the people, to help them get their work done. No process is perfect; when problems arise, the team is responsible to stop, change the process, and start again, all without affixing blame to any one person. Continue reading “What Organizational Concepts Matter the Most to Agile at Scale”
In teams, peer-to-peer relationship is the glue that coordinates everyone. In larger organizations, peer-to-peer relationship can no longer keep the higher number of people connected well enough to accomplish a shared purpose.
That is when Lean ideas and structures pick up and create… This article discusses differences between team-sized and mid-scale or above, and some factors to consider in determining where an organization fits on this spectrum. Continue reading “What Makes an Organization “Mid-sized” (or Above)?”
A framework is only heavy if it prescribes more than what is needed to get the most value for the effort expended. While SAFe can be used in an overly-heavy way, that is not the intent nor the best practice. This article discusses what in SAFe is definitely needed and what may be optional based on. Continue reading “What Is It That Can Make SAFe® Heavy?”
Agile thinking emphasizes self-organization and personal initiative. We want these active in our organizations. However, when this emphasis is taken to an extreme it can imply that there is no place for managers. Some Agile leaders have even said this explicitly.
Lean-Agile, however, says that management and especially middle management has an important role in Agile. It becomes a force-multiplier for organizations in mid- and large-scale organizations. This article describes what middle management can do and how it benefits the Agile organization. Continue reading “What Value Does the Middle Manager Add in Mid-Scale Agile?”
To produce the most value from your available resources in the allowed time, as soon as possible release first the part of the system that is truly necessary to have a viable business product. Restrict the time allowed for building this core part to only the time your estimates say it needs and don’t use all of the calendar time available.
Agile is often described as iteratively building software in increments. It is more effective to think of it in terms of being the incremental delivery of business value. Software by itself is not useful. Software that helps deliver business value is. The focus should be on the value to the business, not on the software. While we all know the importance of “time-to-market,” investigating how this relates in the software arena is particularly useful. Continue reading “How Does Agile at Scale Increase the Delivery of Business Value?”
Amir Kolsky, Rob Neppel, and Jim Trott talk about eight essential skills that developers need to acquire to work in an Agile transformation. Some of these skills are certainly taught in university; some are not as common… but are still essential. These are essential for any professional developer.
The essential skills are:
Programming. The programmer needs to know how to program. The act of taking a design and implementing it in a language and environment.
Design. Creating a good Object-Oriented design based on design patterns. Depends on understanding the specification. The challenge in Agile is that the specification is always changing. You need to know how to create emergent design. TDD helps here.
Refactoring. Pre-factoring (before you make changes to the code) and Post-factoring on legacy code to deal with the code smells.
Analysis: Domain analysis and technical analysis. Working with stakeholders to understanding the specifications and to create specifications up front on what is necessary. ATDD is essential here. Communication is critical here because developers are actively engaged in every aspect of the process. ATDD and TDD helps to facilitate communication.
Testing. This can be learned from the testers in the organization.
Estimation.
DevOps. Looking further down the value stream, extending the definition of done into deployment. Continuous Intergration is just the start of this.
Process Improvement. This is a discipline that the entire team must embrace.
Scrum suggests having self-organizing cross-functional teams. In the prior chapter we saw how violating this rule of cross-functional teams can cause problems. But sometimes large applications require specialization at the component level, making true cross-functionality impossible. The same difficulties we saw earlier show up, but in a different manner and may not always be recognized. One method that has been attempted to coordinate different component teams in Scrum, is called Scrum-of-Scrums. Unfortunately, there is not much experience in this approach working well. In this chapter, I’ll propose another method – that of coordinating the backlogs of the teams involved – to lower the amount of coordination needed while achieving quicker feedback loops. This also helps create the sense of a larger team, one which all members of the smaller teams involved can relate to.
Patterns of challenge
Teams complete iterations relatively well, but are not able to deliver in a timely manner. This occurs then each team is working on some component of a feature well, but does not coordinate well with the other teams that are needed to complete the business capability that this component is a part of.
When product size prevents true cross-functional teams
There are often valid reasons to have teams building components for other teams. For example, there may be a component team that builds modules for different applications of a company. Unfortunately, a side effect of this is that true cross-functionality is lost. When this situation occurs, what is the best method to avoid the delays that occur when cross-functional teams are not present?
Building by iteration, integrating at feature level
Let’s look at the situation where we have a hundred or so developers organized around two or more product lines which we’ll call Product Line A and Product Line B. Each of these applications has their own component team that develops shared methods. There is also a component team that works across applications (Figure 1).
Figure 1: Organization of company with component teams for two different product lines
In many ways this is just a larger scale example of the earlier problem discussed in The Value of Cross-Functional Teams. One solution would be to create cross-functional teams that had folks from each application, the component team(s) for the application and the component team(s) that ran across applications (in reality there was more than one team for each of the type of components being built). If this is possible, I would recommend it. But what if it weren’t? How would you do the work?
This is a situation I’ve seen many times. Unfortunately, there is a symptom that often occurs with this type of team structure. This is that teams can often write and test code within their iterations, but that actually getting something out the door takes much longer. I remember working with a client that had very good expertise with Scrum telling me that all of their teams finished writing and testing their stories each iteration but that actually delivering something took a couple of months. These two statements did not really jibe with each other so we did a little Value Stream Mapping to see what was happening.
The teams involved represented a cross-section of teams – all together working to develop a set of functionality. I illustrate the teams as grayed out in Figure 2.
Figure 2. Teams collaborating together
Let’s look at a representation of the value stream of the work these teams do. Figure 3 shows how the work of a feature is spread out across these teams. Each team gets a backlog consisting of their part of the feature.
Figure 3. How work is assigned to the three teams involved
The teams now take these backlogs and work at their own discretion. This typically means they are not well coordinated as shown in Figures 4, 5 and 6.
Figure 4. Work selected for first iteration (sprint)
After completing their first iteration, the teams select work for the second iteration. Notice that while the work from the first work may be completed, because each team did not coordinate with the other teams in which work they took off the product backlog, they were unable to do any significant integration after the first iteration.
Figure 5. Work selected for second iteration (sprint)
Teams finally get to the point where all of the work done for the feature is completed and they can now integrate their work.
Figure 6. All parts of feature have been done across the teams
Of course, now we have to integrate the combined pieces. The challenge is that it’s been several weeks that we’ve been working on these different parts of the system and integration will take longer than if had been doing it on a continual basis. It’s also not possible to show functionality until this point so our feedback loop is much longer than the length of the iteration.
Building and integrating across the feature level
The question arises how to solve this challenge. Lean flow tells us not only do we want to have the time from start (“conception”) to completion (“realization of value”) as soon as possible, but to have as few delays as possible along the way. This means quick feedback loops along the entire value stream. Clearly it is better to get feedback to show the customer as soon as possible. Scrum as well implies this. If we are supposed to deliver working software at the end of every iteration, even though it’s not possible for each team to do so, it is clear that the team of teams should be delivering working software every iteration.
Therefore, instead of giving the teams their backlogs independently, they should be split up in a way that the work done each iteration will deliver a piece of functionality that can be demonstrated to the customer. This is shown in figures 7, 8 and 9.
Figure 7. Work selected for first iteration to enable feedback of one slice of functionalityFigure 8. Work selected for second iteration to enable feedback of another slice of functionalityFigure 9. Work selected for second iteration to enable feedback of last slice of functionality
The improved feedback cycles that this method provides enables demonstration of the software at a much quicker pace and lowers the amount of integration work required. This also allows all of the teams a greater vision of what they are building.
A new distinction arises: The Macro-Team
At the first client at which I suggested this, one person said that all I was doing was creating a bigger team. I think he’s right. That is, instead of three teams that have to work together, we now have one larger team working together. The insights provided to do this, however, come from understanding Lean flow. It was clear that building software that wasn’t able to be demonstrated was the problem. The missing piece was focusing on how to shorten the feedback loops and the optimization across the teams involved. This underscores my observations for years that Scrum, under the context of Lean flow, is much more effective than Scrum alone.
Summary: A pattern of success
Software development should be guided by two things: the customer and getting feedback without delay across the entire value stream (within the context of adding business value, of course). When work is split across multiple teams, it is important that a larger team be kept in mind. By providing the work in a coordinated way to this macro-team, the coordination required by the components of the team is reduced. This larger team is the smallest team that can deliver value to the customer. The product backlog for this larger team should be managed so value is delivered, or at least demonstrated, on a iteration-wise basis.
Marc Dangizer and Jim Trott talk about the problems teams often face when no one on the team is willing to acknowledge the challenge if others don’t (groupthink) or because they are afraid of what the consequences might be if they do (fear). In either case, the team is far worse off because issues get addressed only when they are unavoidable – rather than early when it might have been easy.
Lean and Agile teams are not immune to this but Lean-Agile practices can make it less likely. And a true Lean-Agile culture can make it never happen.
We cover questions such as:
Why it is helpful to a coach to focus on groupthink and fear. And why it is not always bad.
As a manager, team member, or senior leader, how top spot groupthink and fear
Whether and how Lean-Agile helps to address groupthink and fear.
How to address this when you have mixed cultures, some that are happy to challenge and some that seek to preserve group identity.
If you are a coach or are engaged in Lean-Agile transformation, I am sure these questions have occurred to you.
Agile transformation is never easy. We have found it useful to have people to agree to follow a select number of agreements. Following these agreements both makes our work more effective as well as increases our collaboration. We call these agreements ‘guardrails’ because if we see that we’re not following them we can take corrective action. Continue reading “Using Guardrails to Tie Business to Technology”
Scott Bain and Jim Trott talk about overcoming the challenges people often have to adopting Test-Driven Development in their organization. A big part of doing TDD effectively is coming to an agreement as to what it is, why we want to do it, and how to do it.
Guy Beaver, Kelley Horton, and Jim Trott discuss Lean-Agile Budgeting, a critical, though often an overlooked, topic in Lean-Agile Transformation. Budgets are powerful statements about direction and levers for changing behaviors which is critical to realize transformation.
Dr. Tom Grant and Jim Trott discuss the implications of Lean and Agile software development for middle management. The role is changed, with different skills and behaviors required. Managers transition from being directive to enabling teams to be self-organizing. There are changes in performance evaluations, metrics, and power dynamics. They get into the team’s life “just enough” in order to be helpful.
On July 16, 2012, Alan Shalloway and Esther Derby held a twibinar conversation on Trust and Management. Talking with each other and with attendees who participated via Twitter, they got into the important topic of trust in the organization, one of the necessary foundations for being able to scale Agile in the organization.
We frequently hear about organizations who have had good success with Agile at a team level – good productivity gains, higher quality code, good morale – but then they have problems getting Agile to work “at scale.” They have a hard getting collections of teams to work together. They don’t see the hoped-for impacts on the bottom-line across the portfolio of work to be done.
Chapter 5 of the book, Lean-Agile Software Development: Achieving Enterprise Agility, discusses “Going beyond Scrum.” This is a big chapter, so we are taking it in two parts. Last time, we talked about the importance of optimizing the whole and taking a holistic view of the team if you want to be able to impact the enterprise. Now, we turn to two more key factors: the importance of managing your workflow and the value of accessing and using the good practices that have already been learned by others.
Chapter 5 of the new book, Lean-Agile Software Development: Achieving Enterprise Agility, discusses “Going beyond Scrum.” This is a big chapter, so we are going to take it in two parts. First, we want to consider the implications of the maturing and segmentation of the Scrum community and two key factors required for being able to scale Scrum to an enterprise: taking a systemic approach and looking at the team holistically, how it fits with and must work within the organization. Next time, we will look at Kanban, managing the flow of work, and using the Scrum clinic to (reusing) good practices learned by others.
This show focuses on Chapter 4, Lean Portfolio Management. The premise is that managing the work you are feeding the team is more important than how well the team works.
August 15, 2016
