image source: Digite
Most of the business owners in IT/RD are struggling with the fact that not all the time they can predict or offer a timeline of releasing one or another feature. Even if one or many RD teams' lead time and capacity are well known and calculated, not often a product manager can guarantee that Feature Nbr. 1 will be released on a specific date, 2 or 3 months prior. Also, in many start-ups, the owner or the Product Leader can decide to develop one feature, but at next day can choose to take another feature into development only because, for a start-up, the revenue and positive customer dynamics are significant. All this can create chaos and disruption in product development. Even if we are living mostly in an AGILE environment, planning is still possible and essential. I'm sure most of you agree with this. But how to plan something and continue to be AGILE at the same time? How to be predictable in a world of RD development, where writing software is like painting a new piece of art. Today exist different management framework that allows us, to build a predictable release train. Most of these frameworks include the option to organize planning sessions for iterations or sprints. One of them is the PI Planning sessions. Product Increment or PI Planning is a handy tool for small or big-sized teams to become predictable in an AGILE environment. There are different definitions for the PI planning around. Here are some of them:
Program Increment (PI) Planning is a cadence-based event that serves as the heartbeat of the Agile Release Train (ART), aligning all the teams on the ART to a shared mission and Vision.
PI Planning sessions are regularly scheduled events held throughout the year where multiple teams within the same Agile Release Train (ART) meet to align to a shared vision, discuss features, plan the roadmap, and identify cross-team dependencies.
"Program Increment (PI) Planning session is a time-boxed event where Teams of an Agile Release Train that are united by a shared vision, meet and plan new features, discuss dependencies and risks."
All these definitions say one thing: PI planning is for planning iterations for a specific time range. Most of the theoreticians and practitioners will say that PI planning can not be implemented without SAFe (Scaled Agile Framework). But I met teams that implemented the PI planning without a full applicable SAFe inside the company, and it worked, even if it worked in some Safe Mode.
The most efficient and effective method of conveying information to and within a development team is a face-to-face conversation. (Agile Manifesto)
The first issue that the PI planning solves is the absence or lack of communication between the teams. How often is the RD team communicating with Sales Team or Customer Success Team? How often Product, Marketing, Sales, Support, Desing, and RD teams can sit together and align the product strategy for some months? The PI planning helps to do it.
The second issue that the PI planning solves is increasing transparency in Product and technical decision making. Tech Lead has the opportunity to present the way how the Product will develop in the next months from a technical view. The product team will have a chance to disclose the futures plans for the entire Product. The marketing team will explain how the new functionality will be promoted or sold and so on. Everybody understands and knows the company/product strategies, no matter its technical strategy, business, or marketing.
Based on the strategy that was presented, a commitment for delivery appears. People evaluate how much work they can 100% commit to deliver in a specific time range. This commitment is based on the metrics a Delivery Manager provides. A promise is impossible to take if you didn't identify the cross-team dependencies. When you identify these dependencies, you transform them into action items or create a new one for solving them. Product Managers, based on the dependencies, commitment, and time plan, can allocate better the needed resources. It helps to assign and plan the resource distribution better. The product team has an understanding of when a specific feature stake will be delivered and how.
In my opinion, the best outcomes from the PI Planning sessions are:
The teams that are working in the same ART start to communicate and understand the dependencies between them;
Transparency. Everybody understands and knows the company/product strategies, no matter its technical strategy, business, or marketing.
Appear a commitment. PI planning is about RD or any other team's commitment to delivering functionality with very well defined deadlines.
Better risk management. Because during the PI sessions, you understand and name all the dependencies that can appear, you better evaluate the risks and better manage them.
The product team has an understanding of when a specific feature stake will be delivered and how. Product managers know what resources are needed and when they are required. It helps to assign and plan the resource distribution better.
In conclusion, it's possible to say that the goal of PI Planning is to get all the teams from a company or Product aligned strategically and enable cross-team collaboration in providing commitment and avoiding potential problems with risk minimization.
Commentaires