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.
Work on items that will realize the greatest amount of business value across the enterprise
When teams need to work together, they should focus on getting the most business value ready to be realized.
Collaborate with each other in order to maximize the realization of Business value across the enterprise
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.
Ensure that all work is 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.
Take the necessary steps to sustain or increase predictability
Much of the waste created is from work being done across teams. Each team must attend to how its work affects others.
Keep the work throughout the value stream 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.
Encourage everyone to strive for continuous improvement
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?”
Many executives have been led to believe that Agile is inherently less predictable than a waterfall approach. However, Agile, when wrapped in Lean Thinking, can be more predictable because it enables working directly on the true causes of unpredictability in software development. Waterfall’s large projects and stage gate approach cause delays in feedback, workflow, testing and integration.
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?”
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.
SAFe can be applied to smaller scales than those for which it was designed by treating it, not as an “off-the-shelf” approach, but rather as a thinking framework and collection of valuable practices to be mined according to an organization’s situation.
While this is good for the consultants who ride these waves, it doesn’t serve clients well. No “solution” works for every organization or even most of them, because no two organizations are at the same place when they become ready to make significant improvement.
There is undoubtedly value in most “solutions.” However, a turnkey solution is not the path to the results an organization desires. Rather, the way to success is for the experts in the organization’s condition–its members–to understand their situation at the time they become ready to change. Then they can choose what helps with their actual needs. You should never change something just because someone says “that’s the way our solution says you must do it.”
It seems fairly simple to use the framework part of SAFe and not do a heavier than needed release plan. When the full degree of SAFe planning isn’t needed, perhaps because there are fewer teams or a natural alignment between the parts of the system being developed, we can adjust the planning event to be lighter. The key is to adjust the degree and length of the planning. The two-day SAFe planning event is just as much about socialization as it is about planning. Be sure to include lots of communication between the teams, even if you organize, for instance, with shared kanban boards and skip SAFe’s dependencies board.
Different communication mechanisms are needed at different scales. You will need to decide on the mechanisms you need at your scale. These kinds of conversations, though, create an opportunity to do SAFe in a lighter way than prescribed. This enables us to get the holistic view of things without adopting anything overly heavy.
A major benefit that SAFe at any scale provides is a set of useful default management agreements. These address:
Preventing unwarranted interruptions to development teams
Requiring all teams to have the same cadence so that they can synchronize frequently
Running the teams in a test-first manner
A lightweight implementation of SAFe provides a framework within which to do Kaizen (small-step incremental improvement) to refine the structure of the organization as well as its management system.
The bottom line is that anything can be applied in too rote a manner…and this happens more often than not. Don’t just accept any prescription of a framework or method without first asking, “does this serve the needs my organization is actually experiencing?” If the answer is no, then skip the prescription; there are plenty of other prescriptions available for the needs you have without adopting any for those you don’t.
There are two ways to think of SAFe: as a whole template to which you conform your whole organization, or as a thinking framework with multiple practices that you can mine to address different development needs.
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.
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.
Pendulums swing between extremes. Agile started out as a freewheeling movement in which there was little place for either management or for “laws;” i.e., cause-and-effect relationships like gravity-and-falling. Everything was to be invented by the “self-directed team,” which, it was assumed, would be more innovative as a result and would always end up doing things the best way. Continue reading “How Can We Release Innovation in Software Development? (Leveraging “Laws”)”
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.
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).
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.
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.
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.
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.
Teams finally get to the point where all of the work done for the feature is completed and they can now integrate their work.
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 (“consumption”) 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.
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.
James Sutton, Marc Danziger, and Jim Trott talk about transformation, systems thinking, the borders that Agile erects that can inhibit scaling, coaching, and why Lean thinking requires you to start with understanding the existing culture.
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 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.