Welcome to the second of two blogs showcasing how an IBM Social Program Management development team has adopted Product Kata when creating and managing their product backlog.Read part 1 here.
The Product Kata in action
Figure 1 The Product Kata pattern
Understanding where the team is in relation to the business direction
The first step is to “Understand the direction”. For us, in Social Program Management development, this means looking at the organisations’ mission and intent and ensuring that the entire team understand what that means and what the business goals are.
We ask ourselves where we are as a team in relation to that mission and intent. This phase is called “Analyse the Current State” which means that we look at where we are at that current time in relation to the organisational mission and intent.
Once we have established what our current state is, we “Set the next goal” which means doing research and analysis to help us develop our Product Initiatives. The Product Initiatives says how our team’s work will help achieve the overall product vision. Simply put, it states how we translate the business goals into the problems that we will solve with our Open APIs.
For the Open API team, examples of our Product Initiatives are “Provide a Business Service and Verification Service for managing documents, files and verifications”, “Create an Open API Ecosystem and Methodology including best practices for developing Open APIs” and “Support internal teams with their Open API needs”. From these Product Initiatives we are then able to write our Epics.
Once the product initiatives are established, we determine what we need to do to reach the product initiative. Achieving the product initiative may take months and many sprints, so we need to set team goals and milestones or options to explore that we can measure after every sprint or number of sprints. It is good practice to align the ‘Team Goals’ with the Sprint Goal. We set ‘Team Goals’ or identify ‘Options to explore’ with the same process as we did for the product initiative.
When we have identified the ‘Options to Explore’ and ‘Team Goals’, we walkthrough the Product Kata questions:
- What is the goal?
- Where are we now in relation to that goal?
- What is the biggest problem or obstacle standing in the way of reaching that goal?
- How do I try to solve that problem…what is the one step that we can take?
- What do I expect to happen (hypothesis)?
- What actually happened, and what did we learn
The answers to questions one through four, help us figure out how to plan our next move. They are simple questions to ask, but often teams don’t take the time to ask and answer them. We saw the benefit of this exercise the very first time we did it. We identified almost immediately that we needed to have a workshop to further explore the area that we are working in. This resulted in a week of activity, incorporating design sprint and design thinking activities and event storming. The outcome of the workshop was that we explored the problem and use cases resulting in an Event Model for the area that we needed to understand, the first draft of a number of API endpoints, draft User Stories, and a ‘To do’ list to bring into the next sprint. This gave us the basis of backlog, as well as team alignment as we now shared a common understanding of our goal and how we would get there.
At every iteration, we answer the Kata questions to help us add new tasks and activities to the backlog.
When we move into the development sprints, we work on the tasks we need to complete to achieve the team goal or analyse options/areas that need further exploration. In the sprint or execution phase, we naturally go through the steps of Problem Exploration, Solution Exploration and Solution Optimization.
At this stage, we enhance our understanding of the problem by collating and understanding all the material that we have already and identifying any gaps. We then validate the problem definition with our customer or sponsor user. For our team, this stage sees us talking to our internal customers, Event Storming and starting to write our User Stories. The User Stories are added to our Product Backlog. As we write the Stories, we identify more tasks and activities for the backlog.
This is where we deeply understand the requirements from a user perspective in order to figure out how to solve the problem in a scalable way. We spend a lot of time looking at the Open API prototypes for our chosen use case, while keeping in mind that the final version must be re-usable for other use cases also.
We do Event Storming and update the design and the swagger specifications with changes, and validate each update with the API consumer. It is advisable at this stage to experiment to come up with the best solution. Experimentation is about building to learn, so we endeavour to create prototypes and designs as soon as possible. They don’t have to be perfect. It is more important to put these quickly in front of sponsor users and API consumers to get feedback.
This stage is intended to scale as we iterate to a better offering. Our team is now deliver a successful solution and we can identify the next improvements for the solution. Had we tried to develop the full product vision for these services from the beginning, we would still be working on figuring out what to include in these services, instead we have developed a set of Open APIs that although don’t make a full service, they satisfy the requirements, solve a problem and are the start of the bigger service we envisage. The way we identified where to go next with our solution was to solve the immediate customer problem and identify what other problems that needed a solution that our Open API services could solve.
The Kata is designed to be used on an on-going basis. As we are an Agile team, the Kata also had to compliment our Agile way of working. Every sprint is one iteration, so at the start we go through the Kata questions during each refinement session. There was no extra process overhead for the team, as we don’t need a new meeting to do this, we incorporated Kata as part of the refinement session. The actions identified through the Kata are added to the action items of the refinement session.
Each quarter or after a product release, we take the opportunity to go through the Kata at a higher level, looking at the organisations goals to ensure that we are still aligned with them.