I was recently inspired by a blog I came across called Agile Product Ownership in a nutshell by Henrik Kniberg. He had a comprehensive 15-minute video explaining how product owners can work agile. Agile is so trendy and a ‘hip’ word that big and small companies are interested in using it. Many smaller companies are adopting agile methodology because bigger corporations have seen its benefits as well. I thought I try helping out fellow product managers and debunk some things about agile methodology.
Which methodology to choose?
Choosing an approach here is key. But this should be chosen with careful consideration too. Each methodology should be used based on the requirements of the product. To understand the difference between both the approaches, this might be very helpful:
In a true Waterfall development project, each of these represents a distinct stage of software development, and each stage generally finishes before the next one can begin. There is also typically a stage gate between each; for example, requirements must be reviewed and approved by the customer before design can begin.
Agile is an iterative, team-based approach to development. This approach emphasizes the rapid delivery of an application in complete functional components. Rather than creating tasks and schedules, all time is “time-boxed” into phases called “sprints.” Each sprint has a defined duration (usually in weeks) with a running list of deliverables, planned at the start of the sprint. Deliverables are prioritized by business value as determined by the customer. If all planned work for the sprint cannot be completed, work is re-prioritized and the information is used for future sprint planning.
Source: Segue Technologies
Based on Susanne Madsen’s blog, I have created a simple flowchart to understand and choose if your project should follow waterfall methodology or the agile methodology.
Below, it shows that in order to follow the waterfall criteria several things need to be predefined beforehand. It requires a clear objective, well defined solution, access to customers and stakeholders and openness from the team members. It is not impossible to have all these criteria fulfilled however, it is very rare. (Like you are replicating the process from another product. These are usually not innovative products.)
I have met several people who ‘use’ agile in their organization, but they are facing a problem properly incorporating it. These large organizations have been using the waterfall method since the start that although the upper management wants to move to Agile, the lower management do not see the reason to move towards it. Just because the project suits better with the Agile methodology, it is very important to judge the environment and situation before moving forward.
The job of a product manager was never easy, but with good communication with the team members and understanding, one can do the best for the project! If you want to go Agile, how about seeing how can Agile make the most for you!