Skip to main content

Is your agile transition building a train but ignoring the track?

Every development effort produces two results. The first result is obvious – that is the product or service you are trying to create. The other is more easily overlooked: the development effort also produces a team that creates the product or service, and the organization around that team.

Today, many companies use Scrum and other agile frameworks in their development teams to build better products. But do they use these same techniques to create higher performance organizations? Mostly they don't. Even some frameworks for “scaling agile” don't really address how the leadership improves the effectiveness of the organization.

With the right relationship between development team and leadership you can dramatically improve your ability to create good products quickly. To understand this relationship, and how the Scrum Team and the various Scrum roles should interact with the rest of the organization, let's look at two examples of modern train systems: the DLR in London and the TGV in France.
Docklands Light Railway train at Pontoon Dock, CC-BY-NC-2.0, Michael Day
I came to understand the relationship between the product and the team while riding on the DLR to the Scrum Gathering in London last year. The Docklands Light Railway (DLR) connects downtown London with London City airport, Canary Wharf and other important destinations.

This train is amazing! You walk into the station, flash your credit card at the entrance – beep – you can enter! Walk to the platform and a display tells you to the minute when the train will arrive. The train pulls in, doors open, people get off, you get on, the doors close, and off the train goes. This cycle repeats a few times until you get to your destination. Doors open and you get off, flash your credit card on the way out (half the price of a paper ticket) and you are done. No human intervention from start to finish!

I thought, 'Wow, if there is an example of what you can accomplish in the 21st century, this is it!' But… what is it like to actually ride in the DLR? The dinosaur ride at Disney World comes to mind. Bump, shake, lurch, rattle, roll…. Take a look at the track in the picture above. See that dip? If that were on a ski slope, you would go airborne! See the sharp angle changing tracks? You feel every junction and turn, and it can't go very fast through such a sharp angle. While I don't know if this is literally true, it sure feels like they haven't maintained the track since the DLR opened in 1987, and the average speed of the DLR train is under 50 km/h.

The PBKA TGV, CC-BY 2.0, Rob Dammers
Now let’s look at a high-speed train like the Paris to Amsterdam TGV: we see smooth, flat tracks, limited radius curves and other optimizations for high speed operation. And a pleasant side effect is a smoother ride. This train can provide service at 300km/h.

How does this relate to your Scrum team? As a Scrum Master (or other leadership roles outside the Scrum Team), your focus is on creating the high speed “track,” that highly optimized environment that enables information to flow rapidly and effectively, so that your teams can build great products quickly! The Scrum product owner and other product management functions are focused on what to build; the Scrum Master and other leadership on enabling everyone to work effectively.

In an agile company, leadership fixes impediments to performance and improves the organization's ability to deliver value over time. How important is it to fix impediments? On certain segments, this TGV is only capable of 200 km/h, because the track only has enough power for that speed. Like with the TGV, if leadership would fix the impediments, the teams could go much faster.

What is the easiest way to achieve this? To have a leadership team that has a vision for the organization and uses Scrum to manage its work of fixing impediments and implementing the vision. Depending on the scope of the team and its mandate, this might be called the Impediments Resolution Team, the Departmental or Enterprise Transition Team, or even the Enterprise Action Team if the top leadership of the organization is involved. Regardless of the scope, their job is to take care of the track.

Who is in this team? Assuming you are transitioning a department, then the Team Leaders and Scrum Masters or other process coaches will be members of the team. The top manager of the department will probably be Product Owner, because this person has the authority to make changes in that department.

The key to success is that the Scrum Masters and the traditional managers see themselves as part of one team whose common goal is to improve their part of the organization. Unlike the weekly status meetings, where the status of many issues gets discussed, but problems get solved slowly, the “IRT” (or whatever you call this team) uses Scrum to focus on and solve a small number of issues at every cycle. Just as your developers get better at getting features done using Scrum and delivering, the Impediments Resolution Team gets better at addressing issues that slow down the organization.

How is this different than what you were doing before? By creating an IRT and using Scrum to fix your impediments:
  • You give your leadership and management the same high performance framework that you give your development teams. Your “track” can match the potential of your trains.
  • You connect the production teams directly with the leadership team, so information flows quickly and effectively up and down the organization.
  • You lead by example. By making agility something you do at the leadership level, rather than something you tell your staff to do, you set an example that others will happily follow. You reduce the uncertainty and fear around transitioning to an agile approach, which makes it much more likely that you will succeed!


Popular posts from this blog

Sample Definition of Done

Why does Scrum have a Definition of Done? Simple, everyone involved in the project needs to know and understand what Done means. Furthermore, Done should be really done, as in, 'there is nothing stopping us from earning value with this function, except maybe the go-ahead from the Product Owner. Consider the alternative:
Project Manager: Is this function done?
Developer: Yes
Project Manager: So we can ship it?
Developer: Well, No. It needs to be tested, and I need to write some documentation, but the code works, really. I tested it... (pause) ...on my machine. What's wrong with this exchange? To the developer and to the project manager, "done" means something rather different. To the developer in this case, done means: "I don't have to work on this piece of code any more (unless the tester tells me something is wrong)." The project leader is looking for a statement that the code is ready to ship.

At its most basic level, a definition of Done creates a sh…

Explaining Story Points to Management

During the February Scrum Breakfast in Zurich, the question arised, "How do I explain Story Points to Management?" A good question, and in all honesty, developers can be an even more critical audience than managers.

Traditional estimates attempt to answer the question, "how long will it take to develop X?" I could ask you a similar question, "How long does it take to get the nearest train station?

The answer, measured in time, depends on two things, the distance and the speed. Depending on whether I plan to go by car, by foot, by bicycle or (my personal favorite for short distances) trottinette, the answer can vary dramatically. So it is with software development. The productivity of a developer can vary dramatically, both as a function of innate ability and whether the task at hand plays to his strong points, so the time to produce a piece of software can vary dramatically. But the complexity of the problem doesn't depend on the person solving it, just …

Money for Nothing, Changes for Free

“Money for Nothing, Changes for Free” encourages both customers and suppliers to focus on value.

A key advantage of Scrum projects is that at least once per sprint you have something that could be shipped and no work in progress. You can change direction every sprint, and you can reevaluate whether the project is a good investment or if your money could be better spent elsewhere. Abrupt cancellation is risky for the supplier.

While the concept of an early-exit penalty is not new, Jeff Sutherland gave it a unique allure with his allusion to the Dire Straits hit.
Desired Benefit Incentivize both customers and suppliers to focus on functionality that provides genuine value.
Structure This works with Agile software projects because there is little or no work in progress. After each Sprint, functionality is either complete or not started. Work is basically on a Time and Materials basis with a cost target, often with the intention that the project should not use up the entire project budge…