Don’t try going fast with agile without slowing down first

Many people start their agile journey with the goal to speed up their development process. And while, of course, they can be faster using agile methods, it can lead to a huge and common trap in implementing agile: Expecting that an agile team finishes the same amount of work in just half the time required. Would you believe that 9 mothers could give birth to a child within just one month? Of course not. And while everybody agrees on this obvious fact, some people don’t realize, that expecting an agile team to accomplish a pile of work in less time is pretty much the same.

Unfortunately, this misconception is supported by the language used in Scrum. Because in Scrum each Iteration is referred to as a “Sprint”. And a “Sprint” raises associations of high-speed runners, exhausting themselves to be the first one on the finish line of a short track. Therefore, people expect lightning speed and exhaustion during a Sprint. But in reality, building a product is more like a marathon, than a sprint. Your team does not prepare years to work off tasks the fastest way possible. Instead, you are trying to walk the distance. You try to build products that delight your customers. You do not stop and recover after one Sprint, but actually, keep moving.

So there is really no similarity to a short term track sprint. Hence, pushing your team to work faster will only lead to a downward spiral of results such as: working over hours, sickness, burnout, unhappiness, low employee retention and finally to a huge failure of your agile endeavor.

What “speed” really means in agile

So, what is really the benefit of agile in regards to speed? Well, first of all, you can expect to have an increment of your product at a very early stage of your development process. This gives you the opportunity to receive feedback and improves your ability to generate value at an early stage. And going well, instead of fast, will also lead to an upward spiral of events that increases your sense of purpose, intrinsic motivation, employee happiness, customer happiness and finally to your product success.

Stable Velocity. Sustainable Pace

Mike Cottmeyer, Agile author and coach

Consequently what you are really looking for is a team, that can work at a sustainable pace in order to win the marathon. That means aiming for a stable velocity, instead of pushing the team too hard. Also, you should leave room for “slack time” during your sprints. Watch how the team will use that time to improve their code or pay back technical debt. Remember, technical debt is only “debt” when you plan to pay it back. Otherwise, it is technical theft! Leave the team with some air to breathe and be surprised how slowing down will increase your speed in a paradox way. Furthermore, keep in mind, that the best way to get a project done faster is to start sooner. Also, check out my previous article to read more about starting before you are ready.

Key Takeaways

• Product Development is NOT a Sprint (sorry Scrum), but a marathon
• Agile teams are not working faster, but smarter
• Expect faster Time-to-market for faster feedback and faster Business Impacts instead of working off tasks faster
• Slow down the pace to gain speed