3 Ways to Do Product Development
Waterfall, Agile and Pitching
Working in product teams, I was lucky enough to go through a series of changes and experience different ways of working.
I would split the way I experienced product development into three main eras: waterfall, agile and pitching.
Well, it is called waterfall for a reason. Within the first era, you have strict department structures in place such as product, design, software engineering, quality assurance etc.
The ideas are coming from upper management and/or product and move across the departments accordingly in the form of a request. The top-down approach is quite visible here.
What characterizes this approach is the in-depth planning you have to do upfront. Moving from conception to deployment, you focus on each stage one by one and one has to usually finish before the next one begins. This is where you bump into statements like: “big design upfront,” “testing everything at the very end” and so on.
Within the second era, we now enter the agile world and scrum is mainly applicable. The agile approach overall comes with the iterative mindset, working in increments. Deliverables are reviewed more often and the “learning and adapting” concept is lived. Therefore, the approach is more flexible, incorporating feedback loops as you move along, welcoming change.
In scrum, mixed teams are focusing on different parts/areas of the website/product. Here, the boundaries of the previously well-defined departments are blurred out a little bit.
You have a product person, a designer, developers and quality assurance sitting together in respective islands. The topline goals and direction are still defined from product but the team is continuously working together to make the overall experience of that area/product better.
Typically stories are visible in the team’s backlog and development takes place in 2 weeks cycle. At the end of the sprint, the team aims to deliver a potentially shippable increment.
Due to the teams being somewhat static, you usually observe the people becoming specialized in that particular product or area of the website which can sometimes make it difficult to rotate them in order to “cover” someone who is ill or on vacation.
Kanban is an interesting approach that you can easily switch to when you are working on a really specific project and you do not need to follow the scrum ceremonies or the sprint cycles. Examples can be certain UI optimizations that are scattered across the entire website or requirements that need to be met for you to be GDPR compliant.
Those projects usually have a certain timeframe/deadline and should get done asap. Room for prioritization is limited. People carrying a specific expertise (e.g frontend developers) join forces and are sometimes even pulled out from the scrum teams in order to help finalize this.
2.3 Waterfall or Agile?
And here comes the typical heated debate. Deciding between agile and waterfall. The good thing is you don’t have to decide between the two. You need to understand the differences and limitations in order to be able to decide which works best for you at the specific point in time.
I really like the illustration below summarizing the differences really well, in a simple and digestible manner.
Even though the two previous eras are present or have been tried out in the majority of companies, the last era, pitching, was something I have experienced only at Trivago so far.
The way leadership was defined here changed, going into an even more extreme concept of agility. We basically got rid of all team structures and we had a pool of talents that include all designers, developers etc. In this setup, we had certain product leads that give a common direction of where we are heading and inspire people around a purpose.
The main difference is that everyone else is free to decide on what particular project they want to work on to generate the highest value for our users within 2 weeks time and they can be fluid across the different areas. So the stricter goals we previously had and the static scrum teams are no longer present. With this approach, you also have room for innovation.
With pitching, we aimed to uncover intrinsic motivation.
The most obvious limitation was achieving continuity in the product experience since people are free to constantly move around which can feel like you are starting from scratch with every “pitch”, explaining the context, what has been done already etc. The concept of “planning” was rather left aside. There were also cases of really important features waiting for quite some time simply because you were not a good Sales person that could convince others. The last and most important constraint for me was that it was difficult to achieve the sense of belonging in a team since you could establish trust and get to know each others “buttons” in such short timeframe.
What is the recipe of success then?
Looking back and having tried out all 3 approaches, I would recommend a good mix and blend from all.
Each and every one of them has its advantages and drawbacks, and once you get to know them all, you can make your own cocktail of methodologies that are tailored to the nature of your project.