Posts

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)

Continue reading “Attending to Flow Through the Development Group”

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 >

 


Note

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)

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 (“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.

Figure 7. Work selected for first iteration to enable feedback of one slice of functionality

Figure 8. Work selected for second iteration to enable feedback of another slice of functionality

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

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”

Archive: