Attending to Flow Through the Development Group

< Using the Intake Process to Educate Leadership     ToC    The assessment timeline for a development group of less than 125 people >

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:

  • the number of applications that interact with each other
  • the number of different development platforms (e.g., IOS, Android)
  • have vertical applications riding on top of horizontal applications (e.g., MSCIT)
  • the number of support groups for the applications
  • the amount of dependency on shared services (e.g., Business Intelligence, documentation)

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:

  • interruptions that occur will push stories out, resulting both in breaking the plan for managing dependencies and having the analysis work done on those pushed stories to be redone
  • requirements will be stale towards the end of the program increment
  • makes any pivoting more expensive
  • removes focus because people are now thinking in terms of the program increment
  • long range planning without the use of MBIs often spreads out the time that releasable items are built
  • Parkinson’s law (work will fill the available time) comes into play

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.

Figure 1: Independent development groups

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

Figure 2: More common organization structure

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.

Figure 3: Applications with platform support

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.

Figure 4: Applications with multiple platforms (MSCIT)

What’s Required to Solve these Differences

There are two essential concepts required to solve these challenges:

  1. the use of MBIs so that cost of delay can be computed on releasable items
  2. use of organization wide OKRs so that MBIs can be sequenced based on consistent business value – allowing low level decisions to be tied back to high level business value
  3. an understanding of Flow so that teams can be organized to reduce hand offs, interruptions and delays in general

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.

< Using the Intake Process to Educate Leadership     ToC     The assessment timeline for a development group of less than 125 people >



Two online FLEX courses are now being offered – FLEX for SAFe, and Adopting FLEX (the first course in becoming a FLEX trainer).

If you want to learn about how to adopt FLEX in your organization please contact the author, Al Shalloway.

The Guardrails During Implementation and Integration

< Product Managers and Product Owners     ToC     Teams and Agile Coaches >

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.

< Product Managers and Product Owners     ToC     Teams and Agile Coaches >



Two online FLEX courses are now being offered – FLEX for SAFe, and Adopting FLEX (the first course in becoming a FLEX trainer).

If you want to learn about how to adopt FLEX in your organization please contact the author, Al Shalloway.

What Is the Executive Role in Lean and Agile?

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?”

Why Is SAFe Popular?

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?”

Why Agile Should be More Predictable Than Waterfall

Al Shalloway

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.

Continue reading “Why Agile Should be More Predictable Than Waterfall”

Acceptance Test-Driven Development: A Quick Introduction

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”

How Easily Can We Import a Lean or Agile Framework Into the Organization?

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?”

What Organizational Concepts Matter the Most to Agile at Scale

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”

What Makes an Organization “Mid-sized” (or Above)?

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)?”

How can We Use SAFe® in Smaller Organizations?

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:

  • Managing workload
  • 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.

What Value Does the Middle Manager Add in Mid-Scale Agile?

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?”

How Can We Deliver the Most Value from Available Resources?

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?”

How Can We Release Innovation in Software Development? (Leveraging “Laws”)

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”)”

How Does Agile at Scale Increase the Delivery of Business Value?

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?”

Skills that Developers Need to Acquire in an Agile Transformation

Skills that Developers Need to Acquire to Achieve an Agile Transformation

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:

  1. Programming. The programmer needs to know how to program. The act of taking a design and implementing it in a language and environment.
  2. 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.
  3. Refactoring. Pre-factoring (before you make changes to the code) and Post-factoring on legacy code to deal with the code smells.
  4. 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.
  5. Testing. This can be learned from the testers in the organization.
  6. Estimation.
  7. DevOps. Looking further down the value stream, extending the definition of done into deployment. Continuous Intergration is just the start of this.
  8. Process Improvement. This is a discipline that the entire team must embrace.

How Can We Coordinate Multiple Teams? (Shared Backlogs)

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)”

Groupthink and Fear as Team Killers

Groupthink and Fear as Team Killers

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.

Using Guardrails to Tie Business to Technology

page_webinarsAugust 15, 2016
Al Shalloway | Recording | Slides (PDF)

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”

Middle Management and Lean-Agile

Middle Management and Lean-Agile

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”

Product Portfolio Management: Essential for Agile at Scale

Product Portfolio Management: Why it is critical for Agile at Scale

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”

Going Beyond Scrum, Part 2

Going Beyond Scrum: Part 2

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”

Going Beyond Scrum, Part 1

Going Beyond Scrum: Part 1

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.<--break->

Continue reading “Going Beyond Scrum, Part 1”