PM Process: Agile Framework
If you are associated with the software industry, you must have experienced a cult following the agile process framework. So much so, organizations ramped up product management hiring and started designating them as product owners for various product development groups. I will not delve into the process in detail but would rather talk about the rationale of the agile framework and what does it achieve. Two decades back, agile programming was not quite popular. There were experimental pair programming or extreme programming efforts by some pioneers yet, that was not mainstream and looked down upon by some naysayers. About a decade and a half back, it suddenly started to see the light and pretty much became mainstream a decade ago. Excellent tracking tools for scrum and extreme programming were available. These gave the larger organizations the confidence to adopt the methodologies.
Why Agile?
The classical processes of the waterfall or iterative models faced the challenge of course correction. Once you planned and derisked the project, you leave it to development for a couple of years straight. The reporting of the percentage of the project completed necessarily means nothing. With 90 percent completion, you still cannot release the product. There is no way to know what is going on. Experts in every field will keep on building their specializations; only while integrating they discover the project was even not designed to work together in the first place. The agile process framework is about early feedback and course correction ensuring the market gives the feedback ahead of time. Whatever gets built is built keeping the market in mind. The product owner acts as the proxy to the market pulse. Thus, he plays a crucial role in the agile process. The product owner typically is involved in the following ways:
- The person who defines the scope with user stories
- Clarifies the development process as part of planning and daily stand-ups meetings and ensures whatever gets built is for a final delivery
- Reviews the sprint demo and ensures the delivery is ready for a release
- Attends the retrospective to give and take feedback making the process better for all in the long run.
I think the readers already know the process model or will be able to find the relevant literature elsewhere to pick up the details. We will critique the process and try to understand why the process is the way it is.
User Stories
If you have developed an application in the pre-agile days, you are exposed to use cases. Use cases are detailed textual or graphical explanations of how an actor (human or a system) interacts with the system. Use cases are elaborate step-by-step interaction details, which can be translated to a program by a technical person. There is a lot of emphases given on how than what to build. The details are considered the most significant factor. A user story gets rid of some of the details. They are more goal-centric and hierarchical to meet a purpose. There is the intent to meet a goal. You provide detailed content when you engage with other stakeholders like a customer or the developers or marketing and salespersons. The intention is to fill in gaps as you learn more about the system; this was lacking in the use cases. Secondly, the user stories get completed as part of an iteration in one chunk. So a person interested in a feature can get something working. There is nothing like a technical story. All the user stories are for the user. They ensure there is user benefit that is measurable and delivered as story completion.
Estimation
Estimations in agile processes have two steps. During release planning, there are rough estimates with the ways of t-shirt sizing or story point estimates. They help guess a relative size across the stories. It is as good as saying, is this story similar in size to the other one we did or almost twice of that. The use of story points from the Fibonacci numbers (1, 2, 3, 5, 8, 13, 20, etc.) pretty much signifies that. The estimation exercise includes all the team members. The law of large numbers applies to the estimates, where they converge to something workable. However, the sprint planning expectations are different. The tasks are for every user story. Estimations up to each hour to be spent are computed. Iterations or sprints are planned for 7 to 21 days. It’s fairly reasonable to get control over the time to estimate accurately. Humans are known to estimate better in shorter horizons than over longer horizons. The agile process estimation is just a reflection of that. Work Breakdown Structure (WBS) was probably one of the oldest methods to estimate and used extensively in the waterfall model. The planning is carried out by a small set of knowledgeable architects who do not necessarily represent the team at large. Secondly, long-horizon planning is amenable to mistakes and prone to being outdated due to changes in the business.
Release Acceptance
This is an oft-debated topic in the agile framework. An accepted user story is something that is complete in all respects and can be consumed by the user. Some organizations even go to the extent of deploying the solution in production as soon as it is released after an iteration. It’s possible with good DevOps practices if you are a SaaS-based solution provider. However, one has to also understand the plight the user goes through in understanding the product features. The time needed for him or her to use the product effectively. Most enterprise customers show some kind of displeasure if there is a release in less than 6–9 months. By the time they get comfortable with the previous version, exposure to a new one is detrimental to their business. What is the solution for this? I will suggest running two versions in the cloud and redirect based on the customer to the older release or the newer. The lighthouse category of customers is generally, exposed to cutting-edge release while more conservative customers can be kept on a Long Term Support (LTS) release. Sounds familiar?
Conclusion
Product management is not agile process management nor writing great user stories. If that is the role expected of a product manager, it is a very narrowly defined product management role. However, the agile process framework is an important aspect of the product management process. Hence, every product manager should develop a good understanding of it. There are many certifications and training available today that can make one aware of the processes. Not all agile processes are alike. Some are useful for individual knowledge workers, some for teams, and some for groups. There are hierarchies of teams that can be set up to accommodate really large projects. More than learning the nitty-gritty details of the process, it is important for someone to understand the rationale behind the process. It reminds the article by Fred Brooks of the Mythical Man-Month fame, There is No Silver Bullet. It is often learning from previous mistakes; understanding and continually improve upon your process to do a better job. What is your experience with the agile software development process? When the agile processes became popular initially, co-location was given lots of importance. How are you managing it in the times of mass-scale remote working in the pandemic?
