How is agile product development different to waterfall project management?
Defining the difference between agile product development and waterfall project management is actually a very difficult task because most agile teams that I encounter are agile but under a waterfall project management environment.
Defining waterfall project management.
To understand waterfall project management as a symptom, rather than a stand-alone element of product development, you have to go back in time to understand Taylorism and the origins of the industrial era management systems.
The central premise of how we should work, how we should manage people, and how an organization needs to structure itself was designed and developed in the industrial era.
It was created to manage a largely uneducated workforce.
So, all of the practices designed and espoused by Frederick Winslow Taylor , way back at the turn of the 20th century, tend to govern how organizations are run to this day.
In many cases, as teams adopt agile for product development, they still operate under the umbrella of an organization that still operates as if their workforce are uneducated and that managers need to micromanage what teams do, how they do the work, and when they perform that work.
Command and control.
Traditional waterfall project management assumes that managers know how best to do the work, make decisions, and an uneducated work force simply carries out the instructions provided.
Agile works from the premise that the team of experts are best positioned to make decisions around the work, and that managers and leaders serve to support the team and create an environment where they can excel.
So, in theory, agile is the antithesis of traditional management and project management.
In traditional waterfall project management, a management team attempts to define the entire scope of the project upfront, and then set time and cost constraints for the delivery of that project. They will also decide, upfront, who is best positioned to do the work, and along what schedule of deadlines that work needs to conform to.
This is the plan, this is what must be delivered, this is how it must be delivered, and this is when it needs to be delivered. The project management team don’t know whether the product or solution is going to work or solve the problem until the project is complete.
That could be months, or it could be years. It could be hundreds of thousands of dollars invested or it could be millions of dollars. In essence, it is a big bet that management have made the right decision or that a customer has chosen the right solution upfront.
Agile allows us to frequently inspect and adapt.
We work in short, iterative cycles where we tackle the most valuable work items first, perform the work, and then adapt what we are doing based on data and evidence. That could be customer feedback or it may be conclusive evidence that the product works based on testing.
In short, we are building something and ensuring that it works correctly and is fit for purpose every four weeks or less.
Many small bets that allow us to course correct or adjust, based on evidence, rather than blindly following a plan for years on end simply because that is what our contract stipulates.
This is why the Agile Manifesto values customer collaboration over contract negotiation.
We are looking to develop a hypothesis, in collaboration with customers, and running experiments to validate where that hypothesis is true or invalid. We work closely with customers to ensure that we are always solving the most compelling problem or building the most valuable solution.
We are cocreating in a way that allows us to put a working product or feature into the hands of our customers and stakeholders, every 4 weeks at most.
In both waterfall project management and agile product development, a customer may have a wish list of 1000 items of work.
In traditional project management, that customer receives everything in the contract at the end of the project. The final part of that process is testing and that’s where we find out whether the solution or product works as intended, and if so, the customer signs off and that’s the end of the project.
In agile, we deliver items every sprint. That could be two weeks or it could be four week cycles, but at the end of that sprint, the customer receives a working feature or product that they can use right away.
Because we inspect and adapt at the end of each sprint, we may find that 80% of the value our customers wanted is delivered through the first 20% of items that we have delivered. Our customers may decide that the remaining 80% of items are no longer a priority and may want us to pivot by creating a new list of items (backlog) that would add more value than the items which they no longer want, need, or value.
In this way, agile fosters a cocreation of value between customers and our organization.
A way of ensuring that we are always producing the most valuable items or solving the most compelling problems.
True business agility comes from the decentralization of decision-making and prioritization.
It means that the organization no longer relies on the most senior manager to make every decision about a product or service, regardless of whether they are best qualified to do so or not, and instead shifts decision making down to the team of experts who are actively doing the work.
Rather than an autocratic approach, we form teams of experts who work closely with our customers to make sure that we agree on what is most valuable, most important, and has the highest impact on solving a customer’s need or problem.
In this style of working, everyone in our organization is working closely with customers, engaging with the market, and being responsive to shifts in the market to ensure that we are creating or capturing value.
In a traditional project management environment, the team are simply following orders and delivering according to a predetermined schedule.
The focus isn’t on value creation, it lies in contract fulfilment.
Even if what we are building doesn’t actually solve a customer’s problem, because everything in that customer’s market has shifted, we simply build what we were contracted to build and demand payment for the work that has been performed.
Maybe a customer provided their best guess of what a solution would look like, but wasn’t actually skilled enough to determine what that solution should be, a project management team simply deliver what the customer asked for in order to get paid.
In an agile environment, we might discover within the first month that the solution needs to evolve in alignment with important shifts in our customer’s markets. We might discover that the solution they had in mind isn’t fit for purpose.
In each of these scenarios, customer collaboration with the skilled, experienced team of experts allows us to focus on the most valuable work. It allows us to prioritize the capture and creation of value for our customers over blindly following a plan of delivery.
In a traditional management or project management environment, that includes pockets of agility in product development, the agile teams reduce the risk of building the wrong product or delivering the wrong solution.
In simple or complicated environments, project management works just fine because we know how to build the product or solve the problem already, and we know who is best capable of doing that within the time and cost constraints we have.
In complex environments where we don’t know the answers upfront because we have never built the product or solved the problem, agile is a better approach than traditional project management.
So, we often find that we have a need for agile and project management within the same organization. One approach (project management) excels at execution of known products, whilst the other approach (agile) is great for innovation and invention.
Sometimes we need both in the same organization, but there is an increasing need for leadership and management teams to shift from command and control to business agility driven practices and processes.
We are also seeing an increasing number of customers choosing to work with agile organizations because it allows for greater flexibility and adaptability in the process of creating new products and services.
It allows them to focus on cocreation rather than scoping upfront. It allows them to ensure that they are paying for the most valuable work and receiving the most valuable products and solutions.
Naked Agility is an #agile consultancy that specializes in #scrumtraining, #agilecoaching and #agileconsulting to help teams evolve, integrate, and continuously improve.
We recognize the positive impact that a happy AND inspired workforce can have on customer experience, and we actively help organizations to tap into the power of creative, collaborative, and high-performing teams that is unique to #agile and #scrum environments.
If you are interested in #agiletraining, visit https://nkdagility.com/training/
If you have identified the need for #agilecoaching and #agileconsulting, visit https://nkdagility.com/agile-consulting-coaching/
We would love to work with you.
#scrum #agile #scrumteam #agileprojectmanagement #agileproductdevelopment #projectmanagement #productdevelopment #agilecoach #agileconsultant #agiletraining #scrumtraining #scrumorg
If you've made it this far, it's worth connecting with our principal consultant and coach, Martin Hinshelwood, for a 30-minute 'ask me anything' call.
We partner with businesses across diverse industries, including finance, insurance, healthcare, pharmaceuticals, technology, engineering, transportation, hospitality, entertainment, legal, government, and military sectors.
NIT A/S
