Not all development groups are organized in the same fashion
There are several patterns of flow through development groups. The factors that affect this are when products:
Not attending to these organizational issues can make it difficult to achieve flow through the teams. An easy solution is to do a planning event that identifies dependencies 2 to 3 months out, such as SAFe does. While this will help, it creates challenges on its own:
To better understand the problem of the needs of these organizations, let’s look at a few of the most common.
Mostly independent teams
The first case to look at is when there are several development groups that are mostly independent. This is shown in the following figure.
This structure is relatively easy to manage. This is a common structure for development organizations for less than 75 people. After that almost all organizations require some support group as shown in Figure 2. Independent development groups are easy to manage and can be planned on a per sprint basis. Big room planning is not needed, but often good for its social aspects. Also, because of the size of the organization it is often affordable.
Simplest case typically found for development groups greater than 50 people
For most organizations over 50 or so people in the development group, figure 2 is more common. This requires a bit more planning or the use of Kanban. Kanban at the application support to products can usually manage how to handle dependencies. But in order for this to work, MBIs must be used to sequence the work being requested so that the support teams know which are the most important to get done. Another practice to improve flow is to temporarily assign people from the application support teams to the teams that need them.
Application and Platform Products
As the cloud becomes more popular we’re seeing more and more often that applications share a common platform which may be a product in and of itself.
Manufacturing Supply Chain IT
Many companies have the challenge of multiple horizontal platforms that are products in their own right supporting multiple vertical applications that require them. A common example is Manufacturing Supply Chain IT.
What’s Required to Solve these Differences
There are two essential concepts required to solve these challenges:
Seeing how to manage flow can be accomplished through the A Simple Guide to See if a Change Will Be an Improvement later in this book.
The next FLEX course is currently being scheduled in August in southern Orange County, CA. If you want to learn more about FLEX you can take an online course at the Net Objectives University. If you want to learn about how to adopt FLEX in your organization please contact the author, Al Shalloway
Part VI: Resources on the Net Objectives Portal
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?”
This page has been moved. Please see https://portal.netobjectives.com/articles-public/scrum-by-example/
This blog covers some of the ideas in the first session of our upcoming webinar series on Tuning SAFe. It’s actually an adaptation of our Lean-Agile experience into the SAFe model so it will be useful for anyone attempting or doing Agile at scale. Continue reading “Four Things You Must Do At Scale”
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?”
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)?”
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:
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 at scale takes more than Agile in teams. This article lists several of the most-important elements of this picture of Lean and therefore Agile at scale. Continue reading “What Traits Are Typical in Successful Agile at Mid-Scale and Above?”
One of the biggest challenges of a large enterprise is to choose the set of projects that will realize the greatest return on investment (ROI) possible. To achieve this, organizations use some form of product-portfolio management. Continue reading “How do We Maximize Value Across Many Programs / Portfolios?”
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.
This approach works with either kanban or Agile approaches. It is possible and simple to achieve a level of predictable work throughput and to do effective release planning. Continue reading “How Can We Deliver the Most Value from Available Resources?”
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?”
If you go to almost any Agile conference these days, the topic of SAFe is sure to come up. You are virtually certain to hear some good things and an equal number of bad things about it. There is no question that SAFe provides some value, but why the vehement insistence by many Agile consultants that SAFe is not Agile? Also, even though many companies that are using it, why are many not very excited about it? Exploring the answers to these questions can give us insights into why and how to use SAFe more effectively. Continue reading “What Is the Good, the Bad and the Ugly about SAFe®?”
Sometimes what’s best for your company is not what’s best for your organization. What do you do then? Continue reading “What do You do When What’s Best for the Company Is Different From What’s Best for the Organization?”
Join the Discussion
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:
Much of the time, the functionality required to deliver business value is substantial enough to require being worked on by multiple teams. A good way to coordinate those teams is usually to make them part of a larger cross-functional team). However, organizing this way is not always possible or effective. Sometimes people try Scrum-of-Scrums, but that often doesn’t work either. And SAFe has its own way of coordinating teams, but can be too heavy for the smaller mid-scale organizations (50-100, while mid-scale can go up to 300).
A good alternative at mid-scale is to start with a program-level backlog and apportion the work into backlogs for the teams in such a way that the work done during sprints performed in parallel by all the teams will combine to deliver a larger piece of functionality that can be demonstrated to the customer. Continue reading “How Can We Coordinate Multiple Teams? (Shared Backlogs)”
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.Continue reading “Start Stronger, Get Better, and Do More”
Al Shalloway and Jim Trott talk about the Guardrails System, a holistic system of six agreements that people in an organization make that work together to keep all roles across the value stream aligned and on track in the transition to Lean-Agile. Continue reading “The Net Objectives Guardrails System”
Join the Discussion
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:
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.Continue reading “Justifying TDD”
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.Continue reading “Lean-Agile Budgeting”
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.Continue reading “Middle Management and Lean-Agile”
Software development requires several things to be done to be effective and efficient. While these may not have been well-known 10 years ago, they are fairly well known now Continue reading “What Is Required at Scale | Effective Agile at Scale”
A discussion of Net Objectives’ approach to Agile which is about fast delivery of business value in a predictable, repeatable manner. Continue reading “An Executive’s Guide to Agile | Effective Agile at Scale”
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.Continue reading “Management and Trust”
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.
In our consulting work and our dialog with other consultants, we have learned that success at scale requires attention to four essential aspects: Continue reading “Product Portfolio Management: Essential for Agile at Scale”
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.Continue reading “Going Beyond Scrum, Part 2”
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.Continue reading “Going Beyond Scrum, Part 1”
This show continues a chapter by chapter discussion about the new book, Lean-Agile Software Development: Achieving Enterprise Agility, by Alan Shalloway, Guy Beaver, and Jim Trott.
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.Continue reading “Lean Portfolio Management”