Before I jump into the topic, I will start with some context.
We were working on a very complex product - Complexity in multiple dimensions. As a team, We needed a simple way for us to understand how we manage complexity as team scales and use it as a simple communication tool.
To generalise:
Context:
- A complex project
- A fairly large team
- High Volatility
- Product Engineering team
Challenges
- A way to manage complexity as a team
- Tool for communication on progress
- A mechanism to calibrate progress with the bigger roadmap
Crystal Ball
Crystal Ball is a simple tool for visualising progress on a granular scale. It helps in tracking progress and for teams to look at what they can achieve going forward.
It helps in internalising the progress that the team made in the past few weeks and then relate to it as they plan forward.
How we used it
Our team was fairly big - a 7 pair dev team with 3 Was , 1 BA and a PM. We also had an XD and a UI developer.
With a fairly large team, it was important that all of us knew what we were going to do. We had to do it in 2 steps. Crystal Ball was the second step and not the first one.
The first step was to have clarity on the product roadmap. We started that journey by depicting our product roadmap in multiple tranches - with each tranche having a specific business objective.
All our design and architecture decisions were primarily for achieving the objective of that tranche.
Notice - I call that a tranche and not a milestone or a release. There is a reason to it.I will get to that after I cover how we used Crystal Ball.
Once we had focus on a tranche, we were able to come up with a fairly reasonable set of stories for each sprint. Our sprints were one week sprints - pretty brutal but helped us stay focussed and on our toes.
We met for each sprint planning. I had a list of stories and tasks that had to be done for the particular tranche. It was not a complete list. I picked up a subset based on my context and prior conversations with my dev and testing team.
We would go through the list and rearrange the list to understand what can be picked up. The exact set of things that happened when we did the sprint planning with our Crystal Ball is as follows:
#1 - We start with the leave calendar - Each one has to call out their personal holidays . The team called out public holidays and any other disruptions. For example, if people had to take time off for working with other teams like recruitment or had to go for a training or conference, they would call that out.
#2 - We would discuss the roadmap for a specific tranche. We would discuss in detail on what is the business objective, the progress so far, any changes to the overall design or architectural direction.
#3 - We would discuss the crystal ball we had put in for last week. This would give us a view into what we got right and what we did not. We would discuss on why things did not go as per plan ( In essence this was our retrospective)
#4 - We would then attempt to take a stab at the crystal ball for the next sprint. This would involve detailed discussions on each user story and the approach for these stories. At times, we might park stories if they are blocked - either for functional or technical reasons.
How did it help us
With Crystal Ball, it helped us look at details a lot more objectively. We had a week to achieve things. So we had to split them into fine-grained stories and tasks.
We also knew who was not available when. This let to a sense of collective responsibility.
Since the tasks and stories were fine grained, the debates were at a detailed level that all our members were able to contribute - irrespective of their tenure in the project or their overall experience level.
It also helped us list other tasks that we always miss in a typical sprint planning meeting. We talked about fixing tests, performance tasks, analysis tasks, infrastructure tasks, production tasks and anything that would need to be done by this team. There were sprints where we called out tasks like documentation, transition efforts to other team like marketing, user documentation etc.
Answers to some frequently asked questions:
What about team productivity?
Team productivity - measuring and calibrating it - is a myth. You can manage it.
We used Crystal ball as a radiator to let the team know when we as a team had collectively failed to achieve what we had forecasted. This way, we were able to freely ask questions to ourselves on what we could be better at.
The first few sprints were a lot uncomfortable but we quickly got into the spirit of it.
Did you estimate?
Yes we did estimate in story points. However, The story point estimate was only used for getting to our product plan. We did not use our estimate for our crystal ball. In fact, we were estimating for a story or a task twice.
This is a redundant exercise. We did find value in doing this and it helped us a lot.
How long did you do this?
We did it for 69 weeks. That is a pretty long time. We initially had a different structure for the first 2 sprints and then experimented with crystal ball and said with it for 69 more sprints.
What is a Tranche?
Tranche is a point in your product roadmap that you would use to showcase your product. It does not lead to any user touch points or feedback. It does not have any specific monetary value as well. It is to used in terms of securing more funding for the product - that is what we use milestones for .
We use releases - when we want feedback from users.
We used tranches since we had several stakeholders that had different touch points. These were soft touch points that we had to co-ordinate to measure and monitor progress. However, the scale used for progress is ambiguous - it was not features or user journey.
So why did you let your design and architecture be divided into tranches if you had no feedback or user interaction?
We did not start that way. Initially we thought it would be a release. Hence our initial tranche had design decisions local to that tranche.
However, we realised very soon that these tranches had different business purpose. It was for layering functional complexity for the product management team to structure their thoughts.
Hence, as a product engineering team, we learnt to push back on complex product concepts and layer it.
Does it not mean there was rework?
Sure , there was rework. however, we had the benefit of building layers - each one of them tested and hence helped us layering the next level of complexity far more easier to design , develop and test as well.
How does Crystal Ball look?
 |
| A Typical Crystal Ball |
Comments
Post a Comment