There was once a Project Manager, working in his happy way in one big company. One day the management gave him a Big project to deliver. They could do it the normal way, the uncool waterfall way. But the top management had a better idea. In pursuit on blindly copying the cool kids in the digital arena, they hit upon the Aha Moment of doing Agile Projects! Moreover, they heard that – Agile makes everything faster and cheaper. Let’s be honest – who wants slow and expensive waterfall projects? And thus started the vicious circle of Agile Project Delivery! Where everything needed to be delivered very fast and very cheap !
There are a number of problems going on behind this delivering fast and delivering cheap mentality. Let’s address them one by one.
No Big Projects Please!
The first problem lies with the very premise – “We will take a big project and do it in an agile way”. You simply can not do Agile. You are agile or you are not.
It is as complex and as simple as that. The core of Agile Practice lies in moving from a Project to Product way of thinking and executing – across all hierarchical levels of the company. If we are simply breaking down big projects that have pre-defined scope into a handful steps, then we are just adding more steps, not practicing Agile methods. Agile means starting small. One step first and then defining the next step based on learning from the previous step. The scope keeps changing as we keep accumulating more knowledge about what the customer really wants.
Trying to apply Agile in cases where there are business stakeholders with a laundry list of requirements to be fulfilled will only create unnecessary friction and hamper results.
Pushing the team to deliver the requirements faster in such a setting is the same as jamming more papers into the printer so that is prints faster.
Customers First, Stakeholders Never!
The myth of agile being faster and cheaper actually stems from how companies adopt Agile Practices to begin with. Often, companies become agile overnight, without any due diligence and proper transitioning of its resources and mindset. As a result – people get stuck in an agile outfit with a traditional project manager mindset.
The end means for a project manager is to deliver what the stakeholders want. And to be honest – that sounds reasonable and is the key metric on which project managers are judged. But there is something fundamentally flawed with this way of thinking.
Agile methods are based around the customer’s viewpoint. What features do customers want? What updates would customers find valuable? How can we quickly learn from the app releases that we ship? How can we create more value for customers?
The overarching theme here is the customers. There is definitely a focus on speed but that’s in a completely different context. In fact, the bible of Agile, The Agile Manifesto never uses the word Fast or Quick. Instead, it talks about early and frequently. Rather than delivering big projects in smaller amount of time, it focuses on getting something in front of the customers early and frequently. This makes the process of getting validated customer learning faster.
Optimize For Outcomes, not Outputs!
The component of speed in Agile methods is not focused on getting output, rather on achieving outcomes. One of the key takeaways I got from reading the excellent book Lean Enterprise is the idea that you should focus on outcomes not outputs.
Traditional management theories stem from manufacturing and solely focused on maximizing outputs and minimizing inputs (costs) and thus driving efficiency. But the modern craft of creating digital products is not manufacturing work, rather a knowledge work. It is not spitting out identical outputs in batch sizes for inputs. It involves a bunch of people coming together, brainstorming, coming up with something, changing it. Think of people making a movie, putting on a play, organizing a festival. Making digital products are much more like that than it is like manufacturing boxes in a factory.
And like any other knowledge workers, Agile Teams should focus on outcomes, not outputs. Management should focus on outcomes, not outputs. Product owners and their stakeholders should focus on outcomes, not outputs. Why?
Because outcomes are what counts, outputs mean nothing.
We are here to deliver outcomes. For a business, that will probably be: more sales, or more customers, or more sales per customer, longer customer retention, and so on. Or they could be more general like customer satisfaction or market penetration. Chasing after vanity output metrics like Total User, MAU, DAU, etc. without any awareness of the ultimate desired outcome is counterproductive. It only shows lack of understanding with regards to the philosophy and advantages of Agile.
The Ending Note
If done properly, agile may actually be slow at times for delivering features. And that’s ok. But it will surely start delivering value earlier. It will also start learning earlier, discovering customer value propositions earlier, and reducing risks earlier. And that is why proper implementation of Agile Practices ensures faster delivery of value for customers. Not faster delivery of project requirements
I think the phrases small and early capture the philosophy and advantages of Agile properly. It also helps to manage expectations of a traditional thinking top management. What do you think? Let me know in the comments below!
I enjoy solving meaningful customer problems by utilizing the best practices of customer discovery, design thinking, and agile development methods.
- Why Agile Does NOT Necessarily Mean Fast & Cheap - February 1, 2020
- 5 Secret Hacks To Ace The Product Management Game with A Non Tech Background! - February 1, 2020
- Digital Products Are More Than Just Feature Development - February 1, 2020
