Using Agile to Deliver Double the Value in Half the Time Series

As we work with software product teams, we see more struggling than success with Agile. After conducting many assessments, we’ve found almost all organizations have the potential to deliver double the value and cut their delivery time in half. In this series, I will explore 6 of the top problem areas holding most organizations back.

Let’s assume a starting point of V=T, i.e you are delivering on time and all the intended value over this period of time. By accelerating learning and focused swarming, we will show you how to achieve 2V=.5T, or Double the Value in Half the Time.

Too often in our industry, we are overly obsessed with optimizing for output. We make sure everyone is busy and fully utilized. We try to keep our developers out of meetings and coding at all times. I even had a CEO at one of our clients ask the VP of Development, “If we could send the developers to typing class, would we get more features out the door?” I agree with Henrik Kniberg,1 our goal instead should be maximizing outcome with the least amount of output.

“Outcome over Output”

The Standish Group has reported approximately 64% of features we build in the software industry are rarely or never used.

To illustrate, if I asked you to draw as many houses you can in 2 minutes and you just started drawing, you could get a bunch done. But, do you think you would deliver any that I actually wanted?

Should we continue to build more of the wrong things? Should we just keep everyone busy? Is 100% utilization the goal? Do you want 100% utilization of your CPU? What does 100% utilization of the nearest highway during rush hour look like? The answer is no, because slack allows for change.

Our goal is to not just keep everyone busy cranking out widgets—an idea left over from Industrial Era management. If we were running a repeatable process of manufacturing iPhones, slack for change isn’t needed because we are building the same thing over and over. In that world we have a Defined Process Control Model.

“A defined process is an amount of tightly coupled steps where the output from one step is the input to the next step and where no observation or evaluation of the output is done to feedback to the process. A defined process, when started, will run to the end without any checkpoint. The output from a defined process should always be the same or with little variance given the same input to the process.

For many years software development methodologies have been based on the defined process control model. But software development isn’t a process that generates the same output every time given a certain input.”

-Ken Schwaber in Agile Software Development with Scrum

After the first 100 items out of the assembly line, could you predict with a high degree of certainty how long to get the next 1,000 or next 10,000? Probably. Does that feel like software development? Isn’t it just building more pages, reports, screens? No, but a non-technical CEO sees it as a factory and wants the repeatable results typically associated with a factory. The difference is that every feature is different in software, so it’s not building the same thing over and over again. And that thing is always changing.

If I ask a developer to estimate the time to build the same exact feature they finished yesterday 100 more times, I bet she could estimate with a high degree of certainty. However, she would quit before getting to the 100th because developers are creators. Each task is more than the implementation it requires—elements of design, innovation, problem solving, and learning. This is why agile methods are centered around Empirical Process control instead of Defined Process Control.

Empirical Process Control provides and exercises control through frequent inspection and adaptation for processes that are imperfectly defined and generate unpredictable and unrepeatable outputs.

Scrum adopts an empirical approach accepting that the problem cannot be fully understood or defined, focusing instead on maximizing the team’s ability to deliver quickly and respond to emerging requirements.

-Ken Schwaber in Agile Software Development with Scrum

We need to constantly inspect and adapt in order to accelerate learning. Let’s explore the first problem we encounter in most organizations:

Problem #1 – We make tough decisions too early and lock them in

Problem #2 – It’s about Requirements Discovery, Not Delivery

Problem #3 – Long Feedback Loops

Problem #4 – Focus

Problem #5 – Getting to Done

Problem #6 – Prioritize

Note: If you are struggling with Predictability, we recommend focusing there first before trying to increase productivity.

 

¹Product Owner in a Nutshell Video