Catching up on being lean (again) —Part 2
This is part II of a series meant to capture my experience as I implement the Five Focusing Steps from The Goal to resolve some of my team’s worst issues. I recommend reading the first article here for background and context. But if you don’t want to, the TL;DR of part I is that after reading The Goal and The Phoenix Project, I realized that two of my teams were exhibiting all the signs of being a bottleneck. In this article, I will share the outcome of implementing Step Two of the Five Focussing Steps and provide an overview of how we implemented Steps Three, Four and Five.
Focusing Step #2: EXPLOIT the constraint
As mentioned in part 1, we added two new pieces of information to incoming tickets
a. “is reproducible” by PM\QA\Dev in their sandbox
b. “Confidence” that we have in the reach of issue
- “is reproducible”, it turned out that ~55%(!!) of our tickets are flat out “no”, and another 15% require specific configurations — holy smokes!
So simple, yet so effective. This information allowed the constrained teams to successfully advocate for:
1. Prioritize quick (reproducible) wins.
2. Receive further assistance for reproducing the non reproducible.
3. Time box the amount of effort to reproduce by the dev team.
4. Prioritize “operational tickets (Observability, Tests & Improving negative path messaging) that should reduce those percentages.
5. Explain to stakeholders the unique difficulty the team is facing— a real impact for all involved. - “Confidence”, unfortunately, this additional information did not drive immediate change. That said, it highlights the areas our product has insufficient observability for customer support. Simply put, these are areas of the product with negative paths that are not being instrumented properly. The data will hopefully explain the required effort to (a) improve and (b) measure those benefits.
Focusing Step #3: SUBORDINATE everything else to the constraint
By definition, any non-constraint has more capacity to produce than the constraint itself.
The challenge: How do you convince the business to plan for some teams to do less than what they can?
The solution: Achieve releasing less, not doing less, by enforcing quality work.
In the triangle of Quality-Time-Cost, you only get 2 out of the 3, and surprisingly we tend to cut corners on the former. Time is rigid due to higher education seasonality (see below), and 9 devs can’t have a baby in 1 month. And yet when a professor is standing in front of 500 students — the first impression can make or break their entire semester. If things don’t work, we all feel their pain.
With that in mind, we decided to put a policy in place to require every project for Fall Semester, to complete development ahead of a predefined date. After that date they can either:
- Switch gears to improve the quality of the project.
- Start new projects aimed to be released for Winter semester.
- Help with lagging projects.
The last one is probably the most important. It’s expected that some projects will not meet this target date but are contractually bound to be available for Fall Semester. Knowing which ones they are and having folks available to help will allow us to implement strategies to mitigate their risk as Fall nears — potential game changer!
Focusing Step #4: ELEVATE the constraint
“hiring people, or the like”… As if it was that simple — right?
Luckily for us, after the quality issues we had in production and a recent fundraise, we were able to align on increasing in headcount.
It also took an agreement on which projects would be accepted into the roadmap, but after all was said and done, it turned out that one of the constraining teams would actually need a headcount of more than 10 (Win!). As the pizza rule goes, this finally allowed us to split the domain into 2 teams. It was also fairly aligned with how Product was approaching the domain anyway (early signal?). So all that was left was agreeing on the correct split of the ownership with clear boundaries (classic Architecture vs JTD), size each team accordingly and mission accomplished. Each team has a vision, an impactful mission, a trifecta to help achieve its goals and with a bit of luck, we will see and feel an increase of 60% in capacity.
Very promising!
Focusing Step #5: PREVENT INERTIA from becoming the constraint!
We started a public counter of the weeks leading to Fall Semester. And as we near that time we should get some initial signals on our changes above.
- Is the constraint being exploited?
- Did we elevate the constraint enough?
- Did we subordinate everything else properly?
And once Fall semester finishes, and we enter 2022, the data will tell us if and where to repeat this cycle next.
Final thoughts
This problem space is a long journey, full of trial and error. There are no silver bullets nor bullet proof solutions. It’s a marathon, not a sprint. And so i am reminded of two oxymoron quotes:
“Without data you’re just another person with an opinion” W. Edwards Deming
“Essentially all models are wrong, but some are useful.” George Box,
Accept both and keep at it! 😃
