In traditional IT project management, we have one-year roadmaps, that mostly form the milestones for delivering the plan for the project. Even in agile ways of delivering IT projects, we have product backlogs and sprint backlogs which are meant to serve as outputs to the roadmap.
The issue here, is that like in any IT project, ongoing hiccoughs happen in the process or technology or resource, making it difficult to predict and deliver an IT solution. In most of the IT projects I have worked on for the last six years, these few concepts are used frequently:
- Using agile scrum methodologies
- Running two to four-week sprints.
- Sprint review after each sprint.
- Sprint retro after each sprint to discuss team spirit (in some projects this step is omitted).
- Daily stand-ups in which our developers present their findings.
- Customer demo at the end of each sprint. Our customers in most of these projects have no involvement in the Agile product delivery lifecycle. However, they do give feedback which is taken forward to the next sprint.
- Key members of this team include: developer/engineer, project manager, user interface team, business analyst and scrum master.
What are the issues of traditional delivery?
- Lack of transparency of the deliverables, during the sprint, across all members of the team.
- Explanations and conversations about what has been delivered can stray into very technical areas, which our customers have a hard time understanding.
- Lack of involvement and productivity of the whole team in the delivery.
- The overall product contains gaps and is not what was initially requested by the customer.
Alternative IT product delivery
In this delivery model, we move away from treating the IT solution as a project and instead explore delivering IT as a product.
Product
The solution is delivered by a specific team. If a team is responsible for more than one solution, then each solution is a product and so the team supports multiple products. In this model, we expect the team to be small enough to be able to support only one product. So, we would need to split larger IT teams into smaller teams so that each team only supports one product.
The product could be customer-facing, internal facing, or could be supporting other products or systems. The key here, is to keep one team responsible for one product. The size of the team is dependent on the tasks required to fulfil the delivery of the product.
Our team’s focus is to move away from job titles and closer to skills that can be used across the team. Each product team has a diverse skillset that can be applied to fulfil their respective product. Each team is made up of all the key stakeholders required to deliver that product, including its customers or consumers. A customer representative would be part of the daily functioning of the team and should be fully immersed into a team formation.
This approach is different to the traditional project approach of project team vs customers. By having the customer as part of the team, we are able to get closer to the product needs and avoid handover problems during the final stages of the product delivery process.
Product vision
The product vision is a replacement of the traditional roadmap and milestone approach. The product vision focuses on the overall vision statement that the product is to deliver and typically spans two to five years. In IT projects, the solutions are constantly evolving and so having a timescale of up to five years as a vision helps the product team focus on the end goal of the product they are supporting.
With our product vision in mind, we then break our deliverable timeline into shorter quarterly milestones. The way we do this is by using objective key results (OKR). This is a short statement that highlights what the expected product deliverable is for the next four months. The key results (aim for not more than three results) are measurable outputs that support that objective for that quarter.
The whole team is responsible for coming up with the objectives and the key results through a workshop. The way we do this, is to first identify what would be delivered in the next quarter of the year as a team (the customer is included within this team).
During the workshop there is a series of voting sessions. Our first voting session consists of team members writing down what they believe to be the objectives of the project on sticky notes and pinning them to a project planning wall. Then the team look at all the objectives and group them in terms of commonalities.
Very soon we identify the common objective that everyone in the team agrees on. The workshop is also a time to discuss individual objectives, barriers and solutions, until everyone agrees a consensus. This same approach would be applied for the key results during this workshop. A rule of thumb when coming up with the key results is the 50/50 rule: shooting for the stars is the aim here, so there is a 50% chance of succeeding in each of the key areas for the respective quarter.
Once the OKR is ready, it is expected that in the first quarter after it is applied, it is make or break. This is the point where, if it is going to, the OKR is most likely to fail. This is because the team is still learning how to manage this new approach and as each quarter goes by, the team gets better at it which makes the product of higher value each quarter.
Agile methodologies
Alongside the product team formation process, the team can continue to use sprints or other agile iteration methods that suit them. If scrum is followed, then in addition to the daily stand-ups, sprint review and retro sessions, we have a weekly status and demo session (we could combine the sprint review and weekly status but that is up to each team as long as it is not more than 15 minutes long).
The weekly status purpose is to check what was achieved during the week and explore any early prototypes or work packages produced by the team during this time. This status should be no longer than 15 minutes, which offers enough time to explain, but is also short enough to keep the interest of all parties high.
The status meeting should also show how the project was completed by the product team, or, if the status is still ‘in progress’, how these key results fit with the quarterly objective. During the weekly status meeting, in terms of format, we could use the ‘four square model’ where the product team highlights tasks completed that week and the high level tasks for the next four weeks; including high level tasks, an objectives / key results recap and health metrics of the product team on a weekly basis.
In the weekly status, we put the four square model on the board and do a confidence vote as a team on the key results (KR) to see how the team feels about achieving their KR (out of 10 with an expected 5/10 score). In addition to the weekly demo sessions, there are quarterly demo sessions where the output of that quarter is presented to the stakeholders of that product.
If we have multiple product teams, then all the product teams present their quarterly demos together, ideally in an in-depth workshop. Time must be allocated to set these OKR workshop sessions at least two weeks before the next quarter. The key aspect of this approach is transparency and keeping track of the delivery of the product(s) against the quarterly milestones.
Wider adoption
In terms of team setup and collaboration, we could use the Spotify model of squads, tribes, guilds and chapters. If using this method, then the squads are the core product teams and the tribes are a combination of squads (possibly a department or higher in the org chart). Chapters could be key people from across the squads to represent how to standardise the product deliverables, development and design.
In terms of agile product backlogs, we could use agile story mapping sessions to prioritise the stories in the product and sprint backlog. In a story mapping session, the series of user stories are grouped into categories, using steps and actions. So, the steps here represent the epics which should tell the audience about the workflow that needs to happen to complete stories, which should, in turn, tie into the OKRs.
Under each step, we have actions which represent the smaller user stories that are part of the steps. In terms of sizing the user stories, there are various methods, but I find the Fibonacci scale really helps in defining the complexity of a story. The story mapping approach works for many types of product backlogs.
Overcoming objections
- Tech teams sometimes complain about being in too many meetings, leaving them with a lack of time to deliver the product. My advice is it to look at the big picture, which in this case are the OKR deliverables, because only through discussion are we able to meet the needs of the product.
- There will be resistance from those who have been working in the team for a long time and are not used to this approach. My advice is to try it and let the results speak for themselves. Be supportive of your team structure and give it at least two quarters to reflect back. There will be lots of sessions around reflections at each quarter in terms of what was produced and team empowerment.
Overall, these are just some of many methods in IT product management and, from experience, the product delivery approach has proven to be a huge success so far.
