52 Sprints Later – Win Some, Lose Some, Scrum-butt Done

🏃 Intro

It has been 2+ years of Scrum at Teamhood and almost 2 years since my previous post about our product lifecycle practices – moving from Kanban to Scrum. I’ve just read it, and boy, was I wrong back in the day.

📢 I must emphasize that this post is not about doing Scrum or Kanban, it’s just convenient to have references to methods for communication reasons, at least I hope so… After some time, I also expect to see how wrong I was today. At the end of the day, learning and improving is the thing that counts.

Now back to numbers. During those 2 years, we have endured:

• 52 sprints
• 1000+ product changes
• 3000+ issues
• 51 retrospectives

Each sprint 2-week long, which makes a total of 104 weeks. Well, actually, it summed up as 106 weeks, but I will tell you where the math does not add up a bit later. To present you our key learnings, I believe the most suitable template is the classic retrospective.

✅ What went well?

Sprinkling some praise on ourselves. Very important.

✅ Continuous improvement

Every two weeks, we have iterated our working methods by performing product team retrospectives. We have followed up during the next retrospective on our actions committed. The only gray spot here is that we have pushed forward our uncompleted commitments more often than we would have wanted.

✅ 52 releases where each of them included end-user value

Bi-weekly end-user value release became a non-functional quality of Teamhood as a product. Our users are excited about the product evolution pace. Every time I watch my old product presentation videos, even from 6 months ago, I get impressed by how much we have progressed since then. My key takeaway here is to focus on end-user value, avoid end-user frustration, think about post-release actions, and have enough pre-release quality built-in to minimize risks. We have plenty of potential improvements here, nonetheless.

✅ Fast and steady pace of change

Heavily related to the previous point. It’s more about getting in the rhythm as a team and knowing when to expect what. This also brings a positive side effect of expectation management between different teams apart from the product. The marketing team knows when to start planning release communication; the sales team knows when the most requested product changes will be shipped.

✅ Deliver commitments

Running time-boxed sprints enabled us to manage commitments and sort of plan ahead in batches. I mention this as a positive thing, but in the end, it also has a significant tradeoff which will be discussed among the improvement points.

✅ Ability to operate and fix stuff while doing new stuff

We employed our own experience here to enable the product change process alongside the product operations process. We have defined weekly roles of support, release management, and retrospective organization. Product engineers do a rotation on these roles to have redundancy, share some of the tedious work, and ensure that everyone gets a taste of the bigger picture. The biggest pain related to this positive outcome is that we have abused some of our support-related policies. We have used some of that time for product change work. Sometimes it made sense. Sometimes, it resulted in paying a higher price just later.

⚠️ What could be improved?

Lashing ourselves is also very important. While the points below are not all interconnected, at least the first ones I recognize as the root causes of the next ones are just negative side effects.

⚠️ Poor quality work items

Yep, everything starts here. Our work item refinement process looked something like this:

1. Get the prioritized queue
2. Take items one by one
3. Spec the idea, spec some of the nuances
4. Get UI/UX sorted out if it is required
5. Refine with engineers
   • Breakdown
   • Estimate
6. If not good enough – rethink, refine again
7. If good enough, move to sprint ready

Notable issues:

• We as a product team, tended to oversimplify how deep we drill into large items. Sometimes breaking them down up front by me as a product person did some good, but sometimes it did the opposite.
• I have not been following a strict work item description template. Tried it and got too lazy. Missing some key points /aspects of the product was a real issue that resulted in late scope creeps. For example, doing a new feature in one product part and forgetting to include it in a core part, such as notifications, action logs, etc.
• Poor UI/UX structure, time wasted finding, updating, and re-discussing the same things over and over again. However, we got this part somewhat better in more recent times.
• Some product logic decisions were made based on guesswork. Sometimes makes sense just to keep moving. Sometimes, it does not.

⚠️ Estimating and planning

We suffered quite often from:

• Underestimated work
• Shadow work
• Unplanned work
• Ambitious nature

In short, we have invited 5 thieves of time to our planning meetings more often than we should have 🏴‍☠️

Noticeable issues:

• We would get bogged down due to unsolved dependencies.
• We would occasionally forget about public and personal holiday calendars. Hence, no capacity adjustment.
• We would spend time estimating while it should have been spent refining.
• We would take velocity for granted

Sub-side-effects of that were:

• Scope creeping after commitment
• Sprint overspill

Overspill was the most painful since we tried to do the impossible, continue working on finishing the existing sprint, do a quick release, and already be in planning or even executing a new sprint. Overspill was also a solution. You do a triage toward the end of the sprint and take the P2 items into the next sprint. There were worthy mentions of items traveling more than 3 sprints across. Even writing this gave me shivers.

⚠️ Rushed releases

We had a very nice idea of what is a healthy release, on paper 😁

1. Code freeze on Thursday
2. PO accepts ready items in CI prior to the next step
3. Smoke test on Friday
4. Release the candidate to us on Monday
5. Canary release on Tuesday evening
6. Full release Tuesday evening or Wednesday evening

The most common result was that everything got delayed from one day as almost a standard to 3 days as the most extreme rare hiccup. And once, ONCE, we skipped the release with sprint ceremonies entirely, hence the 106 weeks 🤯

The improvement point here was clear: be more strict and follow policies. Still, some delays made sense and were a more mature choice when you see that we are just not ready enough. Reducing end-user risk is the top priority here.

⚠️ Multitasking

Rushed releases almost always ended in multitasking. You are trying your best to finish the sprint, but on the same note, you are already planning the next one. Multi-context cognitive load was killing our productivity every time this happened. Improvement here is also quite clear, start a thing, work on it, finish it, see how it works in reality, improve it if needed, and move to the next thing once you feel it is already meeting the initial expectations.

⚠️ Batching preparatory work

That’s a personal one, but since I am no professional product owner or manager, I ran things as a complete amateur while juggling my other responsibilities as a founder, marketer, and CEO. Quite an advantage but also quite a pain. I was always catching up to be prepared in time and organize all the necessary dependencies prior to refinement or planning meetings. I skipped lower-level details and focused only on the conceptual level. I have forgotten many of the good practices, and the rest of the team paid the price. Trying to focus and prepare more than a few things up front is generally a waste.

Once I spoke with a smart guy named Steve from Tameflow who explained to me his idea about work value grouping as “the moves”. Since then, I have started recognizing this pattern more and more. When you want to perform a valuable product change, it is usually not a single user story or work item but a group of somewhat related things. Now recognizing the most valuable moves and executing them efficiently is the real challenge.

🚀 What’s next?

We call it Teamhood change delivery process V3.

I have probably missed some non-important as well as important points/learnings here, so this post is subject to change. Having said that, I take upon the last part – how do we proceed? We have already defined and established our product change process version 3. It is based more on Kanban ideas and values than actual Scrum. Yet we still keep the most influential and positive practices from version 2.
This new approach might sound like a joke since our version 1 was closer to version 3 than version 2 to version 3. Should I name this post “Moving back from Scrum to Kanban”? Nah, there is too much drama. I am mostly happy because we will say no to at least couple of things meaning, simpler process. No sprints, no estimations.

🚀 With the new process version, we aim to:

1. Increase quality of input to maximize quality of output
2. Reduce waste, make process lean
3. Reduce up-front prep work demand
4. Make the process more adaptable to situational changes
5. Reduce multitasking and stress

🚀 Agreed policies:

1. Releases still bi-weekly, pull-in all ready items no matter what. Canary release to own T+48H
2. Smoke testing stays the same
3. Weekly or by-demand refinements
4. No planning, just ordering things in ready for dev
5. No estimations
6. Retros are still bi-weekly, post-release the same week
7. Longer standup – up to 30mins. Used as a vehichle for refinement
8. Double-tap refinement, at least. Prior UI/UX and after UI/UX

🚀 Things to explore:

1. Release goals / scope goals (smells sprint, but maybe doable with continuous flow)
2. Classes of service based on type of work instead of SLA
3. Flow metrics once we have enough data

It is still early days, and even though I am keen to share all the details, more time is required so that I do not share untested concepts. As a milestone, I plan to record a video explaining and showing everything. Stay tuned!

Vidas Vasiliauskas

Website

2019 - Present Co-founder and CEO @ Teamhood.
2015-2019 Head of software engineering department at Danske Bank.
2017-2018 Partner Associate Professor at Vilnius University. Lecturer of Software Architecture course
2011 - 2015 Managed numerous smaller IT teams at Prewise.
Co-founder of RaveIT, Eylean, No Brakes Games

Certified Agile product owner and practitioner. Managed large scale enterprise projects as well as launch of small startup products.
MSc of Software Engineering at Vilnius University.

Hobbies: Racing, MTB cycling, Windsurfing