Implications of Enterprise Focus in Scrum
When Chet and I began thinking about our talk for the 2017 Scrum Gathering, we considered the quotations below, which seemed to us to be in conflict, at least in practice.
Agile is Mindset.
– Steve Denning (and earlier, Alan Shalloway)
I invented Extreme Programming to make the world safe for programmers.
– Kent Beck
As we talked more about what we wanted to say, we found some common ground. Let’s dig in a bit:
Enterprise Focus
Agile is Mindset.
– Steve Denning
Steve Denning is active in bringing Agile ideas into the corporation, writing in Forbes and elsewhere. The three words above sum up his viewpoint quite well for just three words. If people up higher in the organization take on the “Agile mindset”, they’ll begin to build a company that gains the benefits that Agile can bring. It’s hard to argue with that.
The world of “Agile” is strongly focused on the corporation these days. The magic words are “Scaling”, “Enterprise Coaching”, “Agile Leadership”, and the magic methods include Enterprise Scrum, LeSS, and the particularly aptly named SAFe. The Project Management Institute is well under way on a second assault, er um, effort to bring Agile ideas to Project Management, in a joint effort with the Agile Alliance. The Scrum Alliance is generating new certificates as rapidly as their PDF formatters can generate.
Corporate “Agile” is everywhere. And that’s not a bad thing, because the ideas can’t thrive until the mindset has been spread widely enough within the enterprise.
Effective Agile Development
I invented Extreme Programming to make the world safe for programmers.
– Kent Beck
Agile Software Development done poorly makes the world unsafe for programmers, as discussed in the entire Dark Scrum series on this site. Perhaps more interesting to the enterprise: Agile Software Development done poorly drops the benefit of the ideas almost to nothing.
It’s easy to see that we all have a common goal: do Agile Software Development well. Let’s explore what that means to our organization, our investment, and our management.
Classical Organization
One way of looking at this is that the conventional corporation is built like an upside down tree, with powerful managers at the top, pushing commands and control downward, until finally good stuff is squeezed out of the company at the bottom, where most of the actual work gets done. When a company has this mindset, Agile becomes an unprecedented opportunity to micromanage product development teams. See “Time was …”.
Agile Organization
For Agile ideas to work well – frankly for any modern management approach to work well – the corporation should be thought of more like a real tree, with the trunk of the C-level and the branches of management all supporting the healthy green leaves where the work gets done.
When organizational support is properly in place, and when the development teams are executing Agile ideas well, the result is a healthy tree. (Let’s pretend that the picture below looks like a healthy tree. :)
Unfortunately, when support is not suitable, or when development teams do not know how to build software in an Agile fashion, the leaves are not as productive. They turn brown and begin to fall away.
This leads, all too often, to what we call Dark Scrum, where well-intended stakeholders mistakenly oppress the teams, actually reducing effectiveness while trying to improve things. This is unpleasant for the team. Far more important to the organization, it inevitably results in slower progress and a weaker product.
Proxy Management (Fortune-Telling)
Classical managers are used to considering proxies rather than actual progress. They look at “earned value” or how many Jira items are done, or how estimates compare to actuals. While these indicators used to be the best we could get, in today’s Agile terms they are little better than reading tea leaves or finding animals in the forest by examining their droppings.
To find a better way, let’s begin by considering the “Time-Money Box”. Every manager – probably every employee – has some flexibity in how much they can cost the company, in terms of time and money, before they get in trouble. Inside the zone, they are healthy. Outside, they may be in trouble. Typically, the amount of time or money we can waste gets smaller as we get closer to the leaves of our tree. And that’s exactly what we’ll count on.
Invest with Time-Money Boxes
Generally, no manager is entirely sure how much flexibility they have if they get too close to running out of time or money. As they get closer to the edges, they become more nervous and begin inspecting and guiding their projects ever more carefully and actively. This is natural, and prudent, even though it’s often not very effective.
The manager does best to stay well inside the healthy zone. In terms of their projects, that means that they want to be sure everything is going well, In conventional management of conventional projects, you’re back to the crystal ball. In the case of an Agile method, there’s a much better way.
To be sure that they stay well inside their healthy zone, the manager provides a smaller Time-Money Box to those who report to them. By monitoring the effort at the end of each of these boxes, the manager has a clear understanding of how the effort is going and has flexibility to help it succeed.
We repeat this investment pattern all the way out to the leaves where product development is done.
Then, however, we hit an important question. Here we are, out at the leaves, with our Agile product development going on. How can we find out better than with tea leaves and fewmets, how the product effort is progressing?
Manage by Increment
Scrum offers a “simple” fix for the Dark Scrum situation, and like most simple things, it isn’t necessarily easy. Scrum requires that both stakeholders and development switch away from measuring things in a predictive fashion, using proxies like estimates and guesses. Instead, Scrum asks that we measure ourselves by directly examining what we have built so far.
Scrum demands that the team build a Product Increment, and centers all the key activities around the increment. We plan the next increment. We review it. We reflect on our difficulties in producing it. We refine our understanding of the shipped product by examining each Increment.
Management gives development teams a series of Time-Money Boxes. After each and every box, they examine the running, tested, fully-integrated software increments which the teams have produced. With tangible software in hand, management has the best possible sense of the future, the best possible material on which to base plans, the best possible basis for planning upcoming incrments.
As time and money add up in orderly boxes, the product matures. At each stage, management can pick the most important things to do next, ensuring the best possible product by any desired time or expenditure. And since every increment is running and tested, we’re ready to ship on time, with the best possible combination of features.
This is a new way of working, for most organizations. It requires that corporate stakeholders give up their old measures and questions, “When will you be done”, “How much will it cost”, “What will we have”. Instead, we jointly look at what we actually have, the real product as it exists so far, and we jointly decide what to do next.
For this reason, all the current enterprise focus is a good thing. Over time, it can help the “Agile Mindset” to spread into the organization, providing the necessary support to the working Agile teams. We can think of it as a kind of fertilization of the trunk and branch, making them healthy so that they can and will provide the support that the teams really need.
This enterprise focus is based on a very simple truth: Agile ideas are not obvious and it is not obvious how to apply them. The conventional corporation, with the best of will, was created to control the “leaves”, not to set them free. This inversion of the corporate hierarchy isn’t just a nice metaphor: it’s what really needs to happen.
And it is not enough. It is absolutely not enough. All the corporate focus, all the moistening and all the fertilizer are not enough to ensure effective product development at the leaves.
For stakeholders to have the opportunity to turn their attention to the Increment, and to turn around their management style, the developers need to be able to produce the Increment. This, too, is a new way of working. Developers are commonly used to building for a long time before anything works at all, and organizations expect long periods of testing and integrating at the end of a long and dreary project. The Agile team produces a bright and cheerful, working, integrated, tested Product Increment every couple of weeks! And they have to learn how to do that.
Notice that our picture above shows the sun, shining on the leaves of our corporate tree, as well as care directed at the trunk and branches. For success in Agile development, the organization needs to provide that sun.
The trunk and branches don’t automatically know how to manage in an Agile fashion. They don’t know how to finance efforts in an Agile fashion. They don’t know how to make product investment decisions, or how to specify products, in an Agile fashion. That’s why all this enterprise focus is basically good: it helps the organization learn how to manage itself in an Agile-compatible way.
Management doesn’t know how to operate in an Agile fashion. Why should development magically know?
The leaves of the tree, the product development teams who build whatever you’re building with Scrum or Agile ideas, don’t know how to do it either! They weren’t born knowing how to do this any more than you were. They need to be shown, just as you do. And just as it takes time for people in the trunk and branches to see that this really works, it takes time for development teams as well.
Development teams do a different kind of thing from that of the stakeholders. The stakeholders help them plan an iteration or “Sprint”, a couple of weeks of effort. Then the developers work for a couple of weeks and show the stakeholders what they’ve built. This “Increment”, as it’s called, is required to be a running, tested, integrated “product-so-far”. It won’t have every feature we hope it will have some day, but it will have every feature built so far, done, tested, working.
This isn’t easy. (Development is never easy. If it were, stakeholders would do it themselves rather than put up with all those expensive weird-looking developers. But it’s hard, so we hire people who can do it.)
Unfortunately, even though they look weird, developers aren’t born knowing how to build in an Agile fashion any more than managers are born knowing how to manage in an Agile fashion. They have to learn.
Developers have to learn to produce a running, integrated, tested Increment. Software development has historically been done with integration and testing at the end. That won’t do for an Agile situation, so developers have to learn to do new things.
I have never seen a hyper-productive Scrum team that didn’t use Extreme Programming development practices.
– Jeff Sutherland
The co-creator of Scrum, Jeff Sutherland, has made this explicit, as shown in the pull quote here. To be productive in an Agile software development situation, developers need to have new skills, including testing as they go, incremental design and development, and refactoring. They need to learn how to produce the Increment, and how to use it, jointly with their stakeholderss, to communicate what has been done and to decide what to do next.
Developer training and support is plentiful. Among the best alternatives are the Certified Scrum Developer program, which is based on the “XP Immersion” classes that Kent Beck, Bob Martin, and I created. And of course, Extreme Programming (XP) remains the repository of solid approaches to development in the Agile fashion. Web resources abound as well. We point here to only two, James Shore and J B Rainsberger, who are among the best.
Summing Up
Management needs to invest using Time-Money Boxes and manage by examining the increment. Development needs to work within Time-Money Boxes to deliver running tested software increments.
There are support, coaching, training, and on-line resources available for both management and developers, and both managers and developers need support, coaching, training, and other resources.
Action Steps
- The company’s product stakeholders need to understand that just as they need some help and education to do their part in a move toward Agile ideas, the developers need help and education as well. A ScrumMaster course isn’t enough to tell a developer how to do their part. Trainers and coaches need to be sure that all the stakeholders understand this.
- Make sure that teams know that they can begin to turn around even the darkest Dark Scrum by producing a solid Product Increment, and focusing their planning and reviews on reality rather than proxy measurements and guesses. And make sure that they know how to do it.
If you focus on the Increment and bring everyone up to speed on creating and using the Increment, you’ll get the most value from your Agile investment. This is the best way we know how to do it – in fact, it’s the only way.
