Nov. 30, 2015

Dear project manager... you’ve been framed!

The project triangle is a tradeoff that limits our thinking, step out of the frame!

"Fast, cheap or good? Pick any two!" We've all heard this before. The project triangle (also known as the "triple constraint") is one of the basic project management axioms. It presents us with a tradeoff between three dimensions, a zero sum game where improving in one dimension degrades the other two. This frame of thinking teaches us that we can reach an optimal solution only by carefully maintaining balance between scope, schedule and cost.

Project triangle

If we look at this setup objectively, it actually seems somewhat counterproductive. By accepting the perspective of the project triangle, we agree to work within its paradigm. Is it possible that the project triangle limits our thinking? Have we, in fact, been framed? Are there other paradigms that offer us a different perspective, and better chances of winning?

The three Scrum roles offer one such paradigm. For the purposes of this blog post, we are not going to dig into the actual details of the roles. Suffice it to say that one role is in charge of customer value, another handles quality, and a third looks after efficiency.

Scrum responsibilities

This setup provides us with a much more constructive paradigm. Improving one dimension will not destroy the other dimensions, but will instead strengthen them! Rather than causing friction and tension, people in different roles now have incentives to collaborate and help each other! How is that possible? Let's investigate the linkages and dependencies between the three dimensions.

First of all, efficiency and quality are pretty much symmetric. A high-quality product is easier to work on, and you can work faster and more efficiently. Similarly, efficient teams won’t accept inferior quality in their product — they just can't afford to work with shoddy tools on buggy software. Investing in one or the other will slow you down momentarily, but the improved velocity will quickly start to give more customer value per time unit. There is no conflict or tradeoff between these efficiency and quality: they simply reinforce each other.

As an aside, we can note that small, step-by-step improvements are extremely useful here. Being small and quick to complete, you get rapid returns on the investment. They compound on each other, resulting in exponential improvements over time. And the risk is low: you lose only a small amount of effort if you have to revert to whatever you had before.

Customer value requires some explanation. In essence, by creating customer value in the right way, teams take delivery pressure off the table. This gives the developers time to to improve their tools and work methods, and create high-quality products. Let’s explore this idea for a moment.

Many organizations believe that increasing customer value is somehow equal to "implementing more requirements faster". This leads managers and Product Owners to remove all slack time and pressure the team to work harder. The team, trapped in the same belief, finds it difficult to defend themselves. Work queues pile up, shortcuts are taken, quality suffers and people work overtime just as they have always done. The key to solving the problem lies in understanding that customer needs are not equal. Two pieces of work of equal size can easily differ in value by several orders of magnitude. By working smarter — focusing on key customers and implementing the most useful features first — a team can deliver more value faster. This is not exactly rocket science.

What seems to be rocket science, however, is constructing a backlog that lets you be agile. Product Owners with little experience of creating agile backlogs often fall back on methods they have used before. The resulting “backlogs” are thinly disguised technical specifications or work breakdown structures, often containing long and obscure dependency chains. Even worse, multiple such chains may be needed to complete a shippable feature. This not only increases the amount of up-front work, but makes it difficult to rearrange the backlog items, increases the likelihood of bottlenecks, and slows down the release cycle.

A good PO will instead construct backlogs so that each item is as independent as possible. There are many good techniques for this, including impact mapping, feature injection, story mapping, patterns for story splitting, the hamburger method, the INVEST criteria and countless others. Focusing on customer value this way and working smarter has the side-effect of allowing the team to set high quality standards and spend time on improving their efficiency.

This wraps up our discussion on the agile paradigm. The tradeoff problem of the self-limiting project triangle cannot be solved from within. We must question the triangle itself, and replace it with a new, constructive and self-sufficient model that is restricted only by the laws of physics — the value-efficiency-quality model. This model has been tried by thousands of Scrum teams over the last two decades, and found effective and workable. Try it out — you might even like it!

 

Image of mvonweis

Martin von Weissenberg

Martin helps people understand agile and lean thinking and coaches teams and organizations in the use of agile methods and practices. He is a Scrum Alliance Certified Enterprise Coach (CEC) and is working on a PhD on how to manage and organize for agility.
blog comments powered by Disqus
Image of mvonweis

Martin von Weissenberg

Martin helps people understand agile and lean thinking and coaches teams and organizations in the use of agile methods and practices. He is a Scrum Alliance Certified Enterprise Coach (CEC) and is working on a PhD on how to manage and organize for agility.

Latest Posts

Niels Verdonk, new Certified Scrum Trainer in the Netherlands

Niels Verdonk has qualified as a Scrum Alliance Certified Scrum Trainer

Image of andreat

Andrea Tomasini

I am an Agile Coach and Trainer and I am helping customers all around the world to become more Agile. I am more and more keen on adopting adaptive emergent approaches to improve people's quality of life. Through an holistic and pragmatic approach - I consider Lean and Agile very powerful frameworks - it is possible to improve results, performance and also personal satisfaction.

Sponsoring Manage Agile 2017

agile42 is a sponsor of Manage Agile 2017 conference in Berlin for managers in agile companies

Image of marion

Marion Eickmann

I am one of the founders of agile42. Even though I am not an engineer I consider myself almost a "Techi" as I have been working in the field of software development for 10 years now.

Joanne Perold keynote at Regional Scrum Gathering 2017

Coach Joanne Perold presenting at SGZA17, the Regional Scrum Gathering South Africa 2017

Image of peterhundermark

Peter Hundermark

Peter has worked with iterative and incremental software development processes since 1999, focusing on Scrum and Agile practices since 2006. In 2007 he started Scrum Sense in South Africa. He has introduced Scrum into scores of development teams locally and in Brazil. He leads certified Scrum training classes in South Africa and elsewhere. He is a Certified Scrum Coach and Certified Scrum Trainer.

Scrumtisch January 2018

The Berlin Scrum User Group meets on January 24th at SAP in Rosenthaler Str.

Image of aballer

Alexandra Baller

agile42 Team Assistant

Coaching structures in Tampere

Martin von Weissenberg delivered a presentation about Coaching Cards and the agile42 Coaching Structure at Tampere Goes Agile 2017

Image of mvonweis

Martin von Weissenberg

Martin helps people understand agile and lean thinking and coaches teams and organizations in the use of agile methods and practices. He is a Scrum Alliance Certified Enterprise Coach (CEC) and is working on a PhD on how to manage and organize for agility.