I will share a real problem and how we solved it despite all the opinions and facts that we will fail. You could learn something from the following few paragraphs.
What was the problem?
We were in a situation to deliver a product with an impossible timeline because of many business-related reasons.
For an easy calculation, let’s say our team capacity was around 100 SP, and we got four sprints to produce a stable product version.
At this point, we got around 500 SP worth in the backlog + a good amount of unestimated stories + a few new features that we knew would come to our team in a sprint or so.
Let’s remember the time allocation for fixing bugs, which in the past was not a part of our capacity for obvious reasons.
So we had at least two times more SP that we could deliver. How do we solve this?
Ideation
Optimize how we work.
The first change was to optimize how we work and see whether we could raise the velocity in artificial terms. We achieved that by:
- Having a strict focus on the stories that needed to be completed and what was stopping us from moving forward faster than usual. Is there something we need to know about the story that would require some research, which is the typical process in normal circumstances? Could we re-assign this to someone who has done this before?
- Focusing on the fastest PR review process. With the higher throughput comes the responsibility to review PR faster and better to ensure quality.
- Discussion during the standup about which person should take a specific story based on their experience and knowledge instead of letting the team members pick their own as we usually do.
With those changes and some more, we reduced the time from “In progress” to “Done.” by 70%. Of course, this comes with some form of debt we must pay later, so if you go this way, please note this somewhere.
Long hours
The second change was the most unpopular one that came to your mind. We needed to tackle long hours carefully as a team because it’s a hazardous mitigation option that could reflect your team and product negatively. I can’t measure the effects of this abrupt change yet, so if you have any ideas, apart from asking the group how they feel about that, I am all ears.
Sharp Focus on the Value
The third change we made was to refocus our sprints and have even smaller milestones that would help us brainstorm and discover all near-time challenges we might have.
If you have to deploy a ready solution in 3 weeks and if you have to deploy fewer features in, say, three days, that would change your way of thinking and focus on the more significant value first.
And we landed at the apple trees paradigm.
Even after we applied all of the changes above, we were still at risk of delivering the value for the deadline (which we cannot move for many reasons).
As a program manager, my next step was to ask for help from teams with similar knowledge. The next step for my engineering folks was to push back and say that we can’t have seven apple trees grow an apple for one month (or something similar to that and not so appropriate for my blog), and throwing more people would not solve the problem but will raise more issues.
In my vast experience, I’ve seen this failing, but I’ve seen this working. So I’ll focus on how we make it work, despite the initial and deserved skepticism from the engineering organization.
Step-by-step approach
Onboarding
The main problem with a new team member is the learning curve: How long would it take a person to understand our codebase and do their first proper commit?
This is a tricky question. I’ve seen teams that give freedom to developers to learn and take as much as they need time to do that, and I’ve seen teams that would pair you with a buddy, and you would do you commit a few days after you joined.
Of course, this requires you to 1) be senior enough to understand a certain level of complexity fast and 2) have a perfect task to help you get started.
The first enabler is:
Have senior enough people to tackle every complex challenge quicker and to have a work area that would not require a lot of learning to get started.
The Product Owner and the team leads created a whole new backlog of items that the new team members could pick up and start working on within a day or two.
Time of the original team.
You would need someone from the original team to help the new team members get started by explaining the architecture, technology stack, or something else.
This, for sure, will take from the team’s capacity. Consider it an investment; as with every investment, you must evaluate the return.
If you spend 10 SP of the original team, you must tailor the experience to ensure the new team members can do much more in the next sprint.
Plan carefully who from the crew could do that and how long this person will be busy with this activity.
We started with a few one-hour sessions and then agreed on communicating without disruption.
The second enabler is:
Focus on the individual skills of the new team members and find a way to optimize their experience.
Communication
If you were in a situation like that, you would have tons of questions about your task, and you need to know what to do in this case.
Encouraging new members always to ask the original team questions could be counterproductive.
We set up a new channel in our chat software to allow all the questions. Then the scrum master, PO, or one of the team leads would find a way to get this answered.
The third enabler is:
Lower the minimum time to unblock anyone so they can do their job faster and better.
How do we measure success?
The most important KPI is – did we deliver the value on time? Yes
The second KPI is – do both teams think this whole experiment worked for good? I’ll let the number talk for themselves.
Keep a flexible mindset.
This is a particular use case, and the success depends on many elements you might not have in your formulas if you want to apply a similar approach to your project.
The lesson here is to know that sometimes throwing more people to help the team helps, and all the time, we should challenge the status quo or the fixed “this wouldn’t work.”, because it might.
Cheers!
Photo by Priscilla Du Preez on Unsplash
Also published here.