Chapter 11. Management’s Role in Lean-Agile Development

“Management is doing things right; leadership is doing the right things.”

—Peter Drucker

“You have to manage a system. The system doesn’t manage itself.”

—W. Edwards Deming

Lean-Agile Management

How you view managing is the key to a successful transition to the Lean-Agile enterprise. In Lean-Agile, the focus is on managing the value stream and leading people. This includes the creation of knowledge about the product, the formation of an infrastructure to build the product, and the creation of the product itself. A visible workflow makes it much easier to align everyone with the goals of the business and improve the flow of value to customers. Management watches for anything in the process that impedes or blocks that flow of value. Great software can emerge from your organization when you lead with the value stream in mind.

For example, it is common for management to track the number of unfixed bugs. It seems like natural approach to assess how a team is doing. Lean-Agile thinking uses a different approach: Instead of worrying about fixing the bugs, we should concern ourselves with what is causing them. Unfortunately, many Agile approaches don’t have a well-enough defined value stream to get consistent answers. Lean’s mandate for a well-defined value stream provides new opportunities for management to lead the team in discovering the source of bugs. Bugs indicate a problem in the process. What could be allowing these bugs to occur or remain? By focusing on our value stream, we can detect these problems and correct them. Perhaps it is that testing is not being done until the end. Perhaps it is that large amounts of work are batching up, which leads to delays in detecting bugs, which increases the impact when a bug is found. Fix the process and reduce bugs. The Lean-Agile manager drives the organization to fix the process by identifying and removing delays, impediments, and blockages in all of the value stream’s processes. These fixes may depend on just the team or they may rely on relationships with other teams.

Creating the Environment

Developing Agile teams that are well formed and hyper-productive requires an environment that fosters team growth, healthy group dynamics, and good team behaviors. Such an environment does not just happen. It requires a leader with good insight, focus, and understanding about what is required. Leaders set the stage for cultivating the needed behaviors rather than trying to train the behaviors “into” the team.

Lean cultures develop in the same way. They are the outcome of leadership that is focused on applying Lean principles up and down the organization and across the enterprise. It is common to hear about the need to change the culture of a company. Unfortunately, it isn’t possible to change culture directly. Company culture results from the conversations that people have about how the company behaves—and these are based on their experiences with management and how managers behave.

Changing culture involves changing the system of management. Fortunately, Lean helps us here. Lean suggests that management can improve results by improving the system within which their people work. Management needs to assist teams in creating proper visual controls so that the teams can do their work better. These same controls enable management to see how they need to coach their teams. By focusing on improving management systems, people’s experiences in the organization will change. And that changes the company’s culture.

In Lean-Agile, the manager has two primary responsibilities:

• Setting the outcomes or goals expected of the team

• Assisting the doers in improving their processes and their workspaces to facilitate getting their jobs done

Carrying out these responsibilities involves helping the team focus on continuously improving the process, eliminating waste and delays. The result should be ever-increasing ability to deliver value to the customer.

The Lean-Agile manager should be relentless in raising awareness of the two biggest wastes in software development: delays and building what is not needed. As impediments to the value stream are uncovered, the well-formed team should be motivated to root out and fix these as part of their daily work.

Lean-Agile’s Balanced Approach to Management

Many people in our industry have wondered why “Taylorism”¹ is so rampant today. Is it because that is how we were brought up in our families or schools? Perhaps. But as we mature, haven’t we learned that this approach does not work? And yet, we stick with it. As risks mount, command-and-control feels safe.

1. “Taylorism” is the tendency toward command-and-control styles of management, as espoused by Frederick Taylor in the early twentieth century.

Or we have read about delegation and supporting our people, trusting them to do the work. It seems democratic but it feels like abdication and certainly promotes its own set of problems.

Lean thinking provides an alternative: Delegating work and the methods to achieve it while still retaining responsibility for the outcomes. Lean suggests several methods and tools that create visibility into challenges that teams encounter. These include value stream mapping, visual controls, walking around, being involved in problem solving, and kaizens.² This visibility enables managers to help teams develop and improve without emotions and blame getting in the way. The manager can point to the value stream map or visual controls to spot issues, ask the developers about processes they are following, and help them investigate root causes of issues. This provides a way for a manager to support and encourage the team—without taking over—while retaining full visibility to what is going on and how she can contribute. While Lean provides many tools, visual controls are particularly useful since they provide information on what is happening now. Chapter 8, Visual Controls and Information Radiators for Enterprise Teams, discusses visual controls.

2. Kaizen is a Japanese word meaning “change for the better.” A kaizen is a highly structured brainstorming session used to generate ideas for an alternative work method to solve a particular challenge.

In Lean-Agile, the manager is essential in helping teams avoid waste. Teams often can’t recognize waste in their own work processes (which can seem like water to a fish) or can be overwhelmed by how to address the issues (the impediments can feel insurmountable). These might occur either because the problem is outside the scope of the team’s work or the team has no authority to make changes. Or the team may see the problem and, being very passionate and committed, may get so focused on solving it that they don’t know when to stop trying to fix it.

In any of these cases, the team’s ability to work is impeded. If they are kept up-to-date, the visual controls make it apparent to the outside observer when the team is impeded.

It is at this time a manager can provide a useful interruption to get the team to reflect on what’s causing its lack of progress. While management should not provide a solution to the problem, getting the team to pull back and avoid going down a rat hole can be a big waste saver.

Create Knowledge within the Team

Technical product delivery requires specialists in many different technology areas. Certifications tend to create organizations that break down work and assign it to the specialist who can complete the individual task in the shortest amount of time. Lean-Agile managers must create knowledge within their organization and have a clear understanding of the harmful impact of pushing work through their teams in this manner. Tactical moves that bring short-term, sub-optimal efficiencies should always be challenged as detracting from optimizing the flow of completed work up and down the value stream. An example of good Lean-Agile leadership is to resist the logical urge to assign work based on skill set in an attempt to maximize short-term efficiency.

In other words, we can often save time by cross-training people in skill areas that are specialized or otherwise in short supply. Even though these newly trained people may not have the speed or quality of the specialist, they can alleviate the bottleneck that ensues during heavy loads. Thus, we do not have to cross-train to be able to handle each step in the best manner possible but just to remove the bottleneck that extends the cycle time during heavy loads.

The lesson from this is that “keeping people busy” is not only an administrative headache, it also creates barriers to a good team environment. Managers supporting Lean-Agile development must pay attention to creating a teaching/learning culture that values specialists but requires them to perform their work with a mentoring approach to others and to be willing to learn skills outside their immediate area of expertise. This is counter to most tactical management beliefs, which attempt to fully utilize each skilled specialist by breaking down tasks and assigning them based on which individual can most efficiently do the work. This sub-optimization results in creating large batches of unfinished work, which we know increases cycle time in a nonlinear fashion. The strategic alternative is instead to create Lean-Agile teams that can adjust and adapt to changing business needs and whose main focus is on completing prioritized work as quickly as possible with no technical debt.

Get to the Root Cause

Adhesive bandages are great to have around the house, especially in a household with kids. Skinned knees somehow lose their sting when properly bandaged with a cartoon character. They also work wonders on hikes to cover hot spots about to cause blisters (if caught early enough). But if you are a serious hiker, you probably should not depend on bandages to prevent blisters; instead, you should attack the real problem and buy boots that fit properly—which leads to the following example.

A large financial-services company with an impressive IT division required both detailed weekly status reports and up-to-date project plans for all in-flight projects. This best-in-class shop was both Waterfall and process-centric, and it had built a software-factory model organized by the process area (e.g. business analysts for requirements, UI developers, mid-tier developers, database developers, architects, system testers, and so on). Project managers had the tough role of assembling matrix teams that had to navigate through the institutionalized Waterfall process and specify a committed date, using a given amount of resources. To keep control over projects underway, detailed weekly status reports and accompanying project plans were required by upper management to track the status of deliverables underway in each phase of each project.

I once participated in a meeting of project-management process experts for this company. The group met regularly to share practices and to improve the IT project-management process. Two experienced project managers enthusiastically presented a new tool that they were about to roll out to all project managers in the organization. These two project managers had worked overtime to create a very impressive application that could synch up project plans with status reports, both of which were required by upper management on a weekly basis. There had been many complaints about how redundant it was to have to maintain both project plans and status reports. With this new tool, the deliverables could be maintained in one place and standardized weekly status spreadsheets would be created automatically. For a nice added touch, the spreadsheet had color-coded tabs for each phase in their Waterfall methodology. The project managers were enthusiastic about how much value this tool created. What do you think?

Lean principles would suggest that this tool, however well intended, will not fix whatever problems these well-meaning project managers face (other than producing a status report). It is merely a bandage that makes the current situation more tolerable, makes it easier to create status reports, thereby supporting a questionable process. The real question is, “What value do the reports provide to the customer?” Really, no direct value. So we should ask, “Why are we doing them?” In this particular case, it is fairly clear that we are doing them because we have a lot of work-in-process we need to manage.

Using the “Five Whys,” we should continue by asking, “But why do we have all this WIP?” (Answer: Because we’re doing large batches of work that require coordination.) And “Why are we doing large batches of work?” (Answer: Because we are following a Waterfall process.) We come to see that these reports are actually an accommodation of following an inefficient process and trying to reduce the pain that results.

How do we solve this? Agile methods would not require such a detailed reporting system and would make coordinating resources simpler. Agile methods also provide visual controls that remove the need for the wasted, redundant work of creating status reports in the first place.

As a manager in a Lean-Agile enterprise, you must acquire this new way of thinking—get at the root cause of the problem first, to ensure that the tool is adding value, and not merely bandaging over a more fundamental issue. Lean thinking guides us to look first to the value stream and commit to continuously eliminating anything that does not add value—from the flow of ideas to delivered solutions coming out of our organization.

Agile Software Development is Not Anarchy

There is a large contingent in the Agile community that has embraced Agility as a way to throw off the “tyranny” of management. We are not in this contingent. We believe that management is an essential part of any Agile transition. When undertaking an Agile transition, it is imperative that management be involved. This is what convinces us that the only viable Lean-Agile transition strategy is one with top-down leadership and bottom-up implementation. Lean management provides us with managers setting visions and outcomes while coaching teams and improving the organizational structure within which they work. Management creates the context in which the team works. This context is set according to many factors, but it must be sensitive to the team’s needs.

We believe a Scrum-alone approach, even supplemented with Scrum-of-Scrums, is not sufficient. Consider managing a group of firefighters in action against an intensive blaze. Let’s say we have a crew of 100 firefighters organized into ten teams of ten. We would assign each of these teams to attack a different area of the forest fire. Scrum would suggest that each team do the best they can and coordinate efforts with a Scrum of Scrums (probably with walkie-talkies in this instance). Lean would have a leader at the top giving objectives to the ten teams and keeping them coordinated. The manager would expect each team to organize themselves for the best way to fight the fire in their own situation—but the objectives would be set from above (the manager). No micromanagement here—rather, managers set a vision, giving direction and coaching as needed. Note the difference if one of the right things to do is let one section burn so as to work on others. The “Scrum” firefighters may feel abandoned—their part of the forest got burned. But the “Lean” firefighters are more explicitly part of a larger group and more easily identify with the bigger picture that was being managed.

There is no question that there are managers out there who are, unfortunately, somewhat similar to the pointy-haired boss in Scott Adams’s Dilbert. Lean says we must transform these bosses, not merely get them out of the way. Compare this with the original intent of the Scrum’s Daily Meeting:

People who are not committed to the project and are not accountable for deliverables at the meeting do not get to talk. They are excess overhead for the meeting.

Management is not excluded as long as they are accountable for deliverables. Later, Ken Schwaber and Mike Beedle (Schwaber and Beedle 2002, 40) define the Daily Meeting as composed only of team members, explicitly removing management from it—and subtly implying management is not accountable for deliverables. Whether intended or not, the result we’ve seen is that Scrum teams tend to insulate themselves from management. This is done with both the Daily Meetings, where management is excluded or at least derided (calling them “chickens”), and by having the Scrum Master essentially play the role a good manager can play without the HR responsibilities.

Lack of Management May Equal Lack of Success

Scrum works by exposing inadequacies or dysfunctions within an organization’s product and development practices. The intention of Scrum is to make them transparent so the organization can fix them. Unfortunately, this seems to happen less frequently than one would like. The Scrum community generally concedes that about three in four of organizations implementing Scrum will not succeed in getting the benefits from it that they hoped for. The explanation is that many organizations change Scrum in order to accommodate the inadequacies or dysfunctions in the organization rather than solving their organizational problems.³ The implication is that Scrum gives them the tools to see but not to change.

3. Schwaber, AgileCollab 2008.

It is not enough simply to expose organizational inadequacies. Even if the issue is somehow exposed, will you notice it? And if you notice it, will you feel that you can do something about it? And if you feel that you can do something about it, will you feel that management supports you? And will the problem actually get fixed? There is much to be done between initial awareness and ultimate resolution. The management involvement espoused by Lean-Agile methods provides insights into solving many of these challenges that standard Agile approaches don’t address.

It would be like your stockbroker saying, “Here is your monthly statement. Notice how it exposes every bad decision you’ve made in the stock market. Now, to fix things, you need to stop making these bad decisions. You need to inspect when you bought stocks at the wrong time and adapt to make the proper purchasing decisions. What I absolutely don’t suggest you do is accommodate your bad decisions by continuing to buy high and sell low.” Apologies for the comparison—it is both ridiculous and not fair. But it exposes the fallacy of saying that because you see a problem you recognize it as something you can fix or that you know how to fix it.

We believe that many of the dysfunctions that Scrum teams run into are in the organizational structure of the enterprise within which they exist. For example, staff may be organized around roles, which can make it difficult to create teams that can swarm on problems. Sometimes these organizational issues are easy to see and not that hard to fix. But other times they are hard to see. Or they are accepted as “just the way things are” and not as something to be worked on.

Many of those that can be worked on require management’s involvement. Managers must see, firsthand, how the teams are being impacted by their policies. This will enable them to make necessary changes. Unfortunately, Scrum’s basic practices and roles tend to insulate teams from management. Avoiding bad management by insulating yourself from it is an accommodation of the problem. Ironically, this isolation does not help first-line managers learn to avoid micromanagement. This insulation is an accommodation of an impediment—the very thing Scrum suggests you cannot do.

Improving Management with Lean Thinking

We all have seen how difficult it is to change habits. Tales abound about developers learning proper coding techniques only to revert to familiar, but poor, habits when crunch time occurs. This is true of people in general—when a crisis is on, we return to old habits. The same is true for managers. Many managers got to where they are by being more capable than others in a crunch. When the chips were down, they often were the ones who led the way, who surmounted the challenge and achieved the goal. Now, they are managing people who need to be able to do this. One of their jobs is to coach people, to empower their staff so they’ll be able to achieve results. When things are going smoothly, most decent managers can do this. However, when crunch time comes, it is all too easy for managers to just jump in and fix the problem.

This isn’t a good idea: It results in micromanagement and inhibits the team from learning and creating their own solutions. By providing visual controls, however, a Lean manager can see the team’s results and work with the team to improve them. Coaching to achieve the needed outcomes provides a way for managers to keep their eye on the end result but enable the team to get there.

Summary

Lead from a belief system that always seeks to maximize the amount of completed, high-quality, value-added work coming out of your organization. Using Lean and business-driven principles, this work should always be prioritized by highest return, whether determined by profit, sales, client importance, or any other factor determined by the product champion. Resist the urge to keep people busy. Knowledge of queuing theory helps reinforce the importance of cross-functional teams that have the capacity to retool rapidly based on changing priorities.

Try This

These exercises are best done as a conversation with someone in your organization. After each exercise, ask each other if there are any actions either of you can take to improve your situation.

• Think of a time that a manager was able to provide an outside perspective that helped solve a problem that the team was mired in. Are there ways to facilitate this happening more often?

• Consider when process was added because of a failed or challenged software delivery. What was leadership’s role in determining the process? Were true root causes addressed or were organizational barriers too large to overcome? Were impacts to finishing prioritized work considered? Was cycle time considered? Why or why not?

• Do layers of process make it easier or harder to minimize work-in-process?

• If a process requires traceability, do you consider it a good process? Why or why not?

• How can leadership in your organization bring visibility to completion of prioritized work?

Recommended Reading

The following works offer helpful insights into the topics of this chapter.

Kennedy, Harmon, and Minnock. 2008. Ready, Set, Dominate: Implement Toyota’s Set-based Learning for Developing Products and Nobody Can Catch You. Richmond, VA: Oaklea Press.

Mann. 2005. Creating a Lean Culture: Tools to Sustain Lean Conversions. New York: Productivity Press.

Reinertsen. 1997. Managing the Design Factory. New York: Free Press.

Schwaber. 2008. AgileCollab. www.agilecollab.com/interview-with-kenschwaber (accessed June 19, 2009).

Schwaber and Beedle. 2002. Agile Software Development with Scrum. Upper Saddle River, NJ: Prentice Hall.