To get stuff done, don’t tell your people to use an Agile framework. Really. Here’s why.

Most of the frameworks are based on Scrum. Scrum tells you to decompose work into small tasks that can be completed in a 2-week “sprint”.

That sounds like a good approach, right?

It might actually be a good approach for simple things. But if you are building cutting-edge things, it is not – it is a terrible approach.

What we have lost in this approach is a feeling of responsibility for outcomes. So if you feel that people don’t seem all that responsible for getting things done, improving, or making the right decisions, that’s why.

A person who has studied Scrum will say that stories are outcomes. They are, but they are too tiny. I am talking about significant outcomes – entire capabilities. We need people to be thinking bigger – that is, if you are building cutting edge things. If you are building simple or ordinary things, then thinking small is okay.

Focus on Capabilities

For cutting edge things, we want groups of people to take on entire capabilities.

For example, suppose the product is an online clothing retail system. Suppose also that we have realized that it needs to really stand out and be something that people will tell their friends about.

During a strategy session, we decide that to achieve that, we are going to make it possible for people to see themselves in the clothes. We have been advised by our resident AI expert that AI can probably be used to do that, using an image that the customer uploads.

Sign up for blog posts!

We never share anyone’s contact information with third parties.

We don’t even know if the goal is a viable one yet – if it will work well enough to please customers. So we first task our AI experts with creating a prototype that verifies that this can technically be done with good results.

Should we use Scrum for that? I would not advise it: a prototype is actually an applied research activity, not a pure development activity. You can’t really plan it out because people will be trying things and changing their approach day by day. I know because I was once on an applied research team.

Assuming that the prototype works well, we now need to create the real thing – the production version. The prototype is probably limited in many ways, and is missing a whole range of usability features. It is probably also slow and has manual steps too. It might not be scalable, and so it will fall apart in real use. Therefore we need to design a usable and practical version from the ground up, but incorporating the techniques proven by the prototype.

Before trying to create a design for the production version, we should state our goals for the first release. These might be:

It needs to wow people. Otherwise, they will form a negative first impression, and our chance at generating buzz will fizzle. Toward that end, we feel that these are needed:

People see themselves in a chosen outfit, and feel that it is realistic.
It works for a range of body types.
It works for the range of clothes in our catalog, or most of them.

People find that the system is usable and easy to understand.
It works well – there are not frequent problems of any kind.

It’s now time to plan the work. Here’s where things go wrong.

If we are using an Agile framework such as Scrum or SAFe, we will follow the steps and describe the new website features as epics and ultimately decompose the work into small units of work called “product backlog items” and eventually “sprint backlog items”, which most people call “stories”.

Work Backwards

Scrum or SAFe will tell us to define epics and decompose those into features and eventually small stories that can fit into short “sprints”. A sprint is just a time-boxed period of work, usually 2-weeks. (Sprints are a dysfunction too, but that’s a topic for another article.)

According to Scrum, each sprint should have a single “sprint goal”, in terms of what gets accomplished by a development team.

But let’s put that aside for a moment. Suppose we work backwards from the envisioned first release, and identify milestones along the way to building it. It is very unlikely that each of those milestones will fit nicely into a single 2-week period.

Instead, what we will find is that there are parallel workstreams that intersect. For example, we might decide that the fastest way to create the system is to do something like this:

Workstreams that build capabilities are composed of sequences of activities.

As you can see, there are parallel workstreams involved, and they all converge at “Usable for customers, and ‘wows’”.

Each of these blue activities is designed to add a capability to the system. If you put estimated times on each box, you will be able to spot critical paths – streams of activities that govern how fast you can get to the final milestone.

It is unlikely that all of these activities fit nicely into a 2-week interval to comprise a sprint goal. Some will be shorter, and some longer.

It is also unlikely that a single team-wide goal for a 2-week sprint can be defined at any point. Instead, there are separate streams of activity.

Thus, the core premise of Scrum, that one can decompose the work into sprint goals, with everyone focused on that single goal, is not a good fit.

Backlogs Have Insufficient Visibility

Another problem with Scrum is the division of work into “sprint backlog items”, which as I explained most people refer to as “stories”. Again, it sounds perfectly reasonable, but what happens is that people obsess over those, and lose sight of the actual milestones. I cannot count the number of pointless discussions that I have witnessed about how to split sprint stories.

Instead, it is better to let groups of people define tasks and change those tasks day by day as they discover what is working.

Tasking out is good, but the milestones should be the driver. If you have someone task it out and then hand that to programmers, they will dutifully complete those, but there was probably a better way that you will never know about, because you didn’t challenge the programmers to create the capability.

Yet another problem with the Scrum approach is that work completion is now governed by completion of the stories. Yet it could be that the essential capability was created before all the stories were completed. You can’t decide to shift resources to another capability yet, because your plan is based on completion of stories – that’s your focus. In other words, planning by stories makes your plan rigid.

It is a rare person who can manage by stories but be able to see beyond the stories to capabilities. The two views are cognitively opposite: one is reductive and the other is inductive. One approach requires an accounting mindset and the other requires a capability mindset.

A focus on capabilities is more flexible, because you can assess, “Is the capability enough to wow the user, even if there are some features that have not been added yet?” A capability-mindset product lead might even visit a customer and show the current system and ask them. The customer might say “wow!”or they might say “Yes but we really need those other features”.

If it turns out that the current state of the capability is sufficient and wows, it might be a good idea to shift work to another capability, since capabilities are what enable people to do things with your product.

Notice how dynamic this is – the original plan was probably not quite right, and we are pivoting along the way, depending on how the capabilities turn out. We might even adjust the vision for the release, as we obtain feedback from prospective customers.

Participate

There is also an insidious behavior that a task or story focus generates, which I alluded to earlier.

Team leads (or Scrum Masters) and managers start to manage by tasks in terms of how they manage and deal with their people. They become administrators instead of leaders.

Again, that’s fine for non-cutting edge work. But for products that need to wow, and that push the envelope on what they do, a task-centric focus is a terrible one.

Instead, a focus on capabilities is more effective. Stop looking at task lists and what has been checked off: it’s fine for the basic tasks, but for the cutting edge work, have a capability focus.

Talk to the people doing the work – don’t obsess over their tasks. Ask about their approach. Ask about issues. Listen well. Be encouraging. Watch for tradeoffs, such as “Do we invest more in making this reliable versus getting the feature more usable?” Use business judgment, but defer to technical judgment too. And try to understand all aspects of the work – business and technical. You don’t need to be an expert, but you do need to grasp the basics: otherwise it is impossible to have real conversations about tradeoffs.

A leader of a tech team’s job is to generate quality discussions and drive to good decisions, quickly. Again and again. That requires that leaders participate, with inquisitiveness, support, and occasional decisions on direction or hard choices.

Also, metrics are really important – metrics about capabilities. In our example above, what is the performance that we are measuring in the lower workstream? In the middle workstream, what percent of our catalog has been made to work well with the new system? In the upper workstream, how confident are we in the integration? – that is, how thorough are our integration tests?

Leaders need to challenge people to measure the right things, but in the end be responsible that the right things are being measured – metrics that inform about the actual capabilities that are being built.

What Does This Really Look Like?

You might be wondering how to actually implement what I am saying. Do we ditch Scrum?

Yes. But thoughtfully.

First of all, we have said a lot about how leaders need to behave. We described them as having a “capability-mindset”. We explained that they need to be participative yet not micromanage. These leadership behaviors are skills. They must be improved in people if you want things to go well, because most people do not know much about leadership, and often the models that they see are not good ones. Training and mentoring is needed.

Assuming that you have people with good leadership skills, you should gather with your key people and challenge them: If we were to focus on capabilities rather than stories, what would a plan look like?

Most Agile frameworks use some kind of work backlog. Instead, we advocate a roadmap approach. Unlike a backlog, a roadmap includes a time dimension.

In business, time is really important. Thus, instead of defining low-level stories and putting them into a bottomless backlog, we recommend identifying the key capabilities that you want to demonstrate, and lay those out on a timeline.

Differentiate between hard dates and flexible or aspirational dates. If most dates are hard, then you are in trouble, because it is very difficult to predict how long cutting-edge product development will take. You can estimate, and if your estimating is good you might get within 20% of the actual time, but hitting it spot on is almost impossible. That’s because with software you never build the same thing twice, and software always has hidden complexity that is not discovered until deep into the implementation.

Once you have the capabilities on a timeline, decompose the first few into key features. Not all the features – just the really important ones: the ones that are needed to wow people as well as the ones that simply must be there to make the thing work.

In the course of planning, additional ideas will come up for features or capabilities that are non-essential right now. Don’t put them on the roadmap: instead, add them to a parking lot for when you revise the roadmap in the future. You should frequently be revisiting the roadmap and adjusting it as things evolve. Over time, you will find that most parking lot items become obsolete or unimportant, as the product vision evolves.

Capabilities decomposed into key features.

We already mentioned metrics: start defining and using them, about capability performance.

That’s kind of it. It’s that simple.

Of course, if there are multiple teams (there usually are), then you have coordination and dependency management, but those are tangential topics here. I’ll have written about those topics before, but I’ll write about them again, so stay tuned.

Conclusion

If you are creating cutting-edge things, don’t take away from the tech people responsibility for outcomes. Let them figure out how to task things. Focus on milestones and system metrics that indicate capability level.

Work with the tech people to plan the pathways to success – the workstreams. Be ready to frequently adjust those plans. But don’t measure progress based on tasks or “stories”. Measure based on milestones – milestones backed by capability metrics.

To find out if progress is being made, don’t look at a burndown (a chart of how many stories have been completed). Instead, look at metrics for capabilities. Get away from an accounting approach: talk to people. Find out what issues they are having. Have discussions about approaches. Lean toward letting the technical people choose their approach, but take an interest. Participate. Ask questions. Decide on tradeoffs. Be supportive. Be goal-oriented, not control-oriented.

If you are interested in this approach, you should talk to us about Constructive Agility.Ⓡ That’s our approach to all this. It is a question-based approach to helping organizations to solve their most wicked problems.

Sign Up to Receive Blog Posts!