How To Fix Your Scrum
Intro
Every team i’ve ever been on has done scrum. And every time I felt like things could have been improved by doing things differently. But as the old saying goes: Nobody ever got fired for choosing scrum.
A Scrum Primer
Scrum is one implementation of agile.
There’s the Product Owner, responsible for prioritising requirements.
There’s the team that develops the product.
And there’s the Scrum Master who manages the process (and purchases Scrum certificates).
Noone is above anyone else.
The requirements are sorted in the Product Backlog. Work is done in (usually two week) sprints.
At the beginning of the sprint there’s a Planning Meeting (can take a whole day) where the tasks are chosen the team commits itself to finishing in the sprint.
At the end of the sprint there are two more meetings: The Review Meeting is a showcase for the stakeholders of what got finished in the sprint. Everyone from the company that is interested can join. The Retrospective Meeting is for discussing what went well and what can be improved in the future.
In the middle of the sprint there can also be a Refinement Meeting to massage the backlog.
That’s quite a few meetings. Oh, I forgot one: There’s also the Daily Standup Meeting where the team syncronises for the day.
Ah and by the way, the Planning Meeting will usually be split in two parts: the Planning Meeting 1 and the, wait for it, Planning Meeting 2. Feel free to google that if you like to learn more.
By default, everyone joins every meeting. So if you like meetings you will feel right at home. If you think it’s dangerous and expensive to pull off your expensive employees from their work so often, things might need to be changed.
Disclaimer: There will be people saying “You’re just doing it wrong”. But if everyone is doing it wrong, maybe there is more to it.
What Problems Pop Up?
There’s a rush at the end of sprint to put things to “done”. This can introduce buggy, untested and technical debt-inducing code into the codebase.
Devs can be out of work if there is nothing left in the sprint for them, even though the backlog is full. “You should just pick more next time”? Why would a developer commit herself to getting more work done and possibly failing? “Pull from the backlog” - Sure, if PO is reachable and backlog is sorted and prioritized and estimated.
QA has no work early in the sprint (everything was built, tested and shipped at the end of last sprint) and too much at the end (“Heyy, so I know the review is tomorrow morning but I just commited a little fix. Could you take a look?”)
Devs love to develop but not to review or test. Lots of tickets are a work in progress but in the end nothing gets shipped.
Releasing everything at the same time may result in juicy merge conflicts if everyone commits his feature on the last chance.
Technical Debt falls under the table as it doesn’t get prioritised by the PO (who has the customer breathing down her neck).
Let’s look at some things more in depth.
Planning
Planning gets done by playing poker (I kid you not). That’s because the team has to estimate the features (or stories) that will be worked on. Estimation will not be done in time, though, but rather by story points. As managers take an estimation as a binding contract (this feature will be done in x weeks) story points were invented to obfuscate this duration so that managers would not pressure the team to much. So every team member gets a set of Planning Poker Cards (just $12.99 on Amazon) with which he can vote. The more effort for the story, the higher his vote. (Effort is not measured in time, though. Don’t ask me how it works).
At the end of the sprint the team has a specific velocity, or how many story points were finished.
From this Velocity tricky managers could actually just reverse the points back into time estimates (’the team does on average 60 story points per sprint? Nice, that’s 6 per day or 0.75 per hour, divided by team size that would be…’).
Actually, Estimates are a waste and always wrong). Here Allen Holub argues that we shouldn’t think about estimation but about projections. What does management need to know? When something is done. So what would happen if every story had a story point value of 1? Answer: not a lot. The finish time of features were still almost correctly projected. Fibonacci numbers don’t add value. So how much will get done in a sprint and what’s the velocity? X number of stories (size should average out).
If you still want to estimate, a better scale than numbers would be a scale that’s more difficult to reverse. Like trivial, easy, normal, hard, herculean, don’t know.
Backlog
A big backlog is stupid. The first 10 stories are still correct and could be implemented and would add value. The rest will change depending on what we learn. More than 20 stories are wild fantasy. 100 is way too much. Re-estimating of lower backlog items is insane.
The Daily Standup
Most teams I know do their daily standups like this: What did you do yesterday, what are you planning for today and what are your blockers. What is this meeting about? Proving that you actually did some work.
I can see in Git what you worked on. I can see on the board what you’re working on. And if there’s a blocker you shouldn’t wait til a meeting to bring it up.
I’m not a fan of managers joining the daily as well (official Scrum dictates they shouldn’t, anyway). This just puts more pressure on everyone to show off and most are thinking about what they are going to say, not what is being said, anyway.
A better daily would be Walking the Board. Start at right-most column of the Scrum Board (release column first, then test, dev, backlog). What is being done/can we do to get this ticket done? If discussion gets too deep, people can raise their hand to signal that the discussion should be move to after the daily so people are not wasting their time.
Moving cards during standup instead of directly when the work was done can be more satisfying. Blocked cards should get their own space clearly separated from working tickets. Anyone looking for work? Pick something from the backlog during the meeting so everyone is informed/can object.
Time of the standup is also important. Directly before or after lunch works best in my opinion so people get long, uninterrupted maker time.
The Board
The typical scrum board looks like this:
Team members push their cards along the board. Development done? Move it to the Testing column and pick the next development task. What’s the problem here? You don’t see which tickets are actively being worked on and which were just moved there.
Also, who is responsible for getting the ticket done? Probably no one. That’s how you get a lot of tasks that end up in progress but never finished.
A better way is to move to a pull-based approach:
If tickets are done with their current phase they are moved to the column-internal Done column. If lots of tickets end up there and no one pulls them to the next phase it’s easy to see what the problem is.
Technical debt
What is technical debt and why should we care? Technical debt gets accumulated when you ship features but the underlying infrastructure suffers.
Maybe you didn’t write enough (or any) tests and the next change in requirements will force a rewrite and breaks things.
Maybe the code is more complex and harder to understand than it could be (also called accidental complexity). This makes the coming features more difficult and error-prone to write.
Maybe components are more tightly coupled than they should be which makes testing and refactoring harder.
Dependencies need to be upgraded because of e.g. security patches.
Changes break stuff and take longer and longer. (First Law of Programming). Handling technical debt is not optional if the project is supposed to live longer than a couple weeks.
We can’t be agile if our code sucks
How to fix it?
Account for slack time.
option: 20% time invested in sustainability work
option: 10 story tickets, 5 tech debt tickets
The Scrum Review
I like it and I would encourage every person to join if they are interested (sales, marketing, customer success). It helps with understanding why some features take so long.
The Scrum Retro
This might be the most important meeting, especially when things are not going well. One caveat: Make sure to document what popped up and that you have a way of making sure that it’s not the same things every week. For example, create action items for fixing issues and review them at the beginning of the next retro.
Misc
everyone in every meeting
incentives of players: developers want enough work, might work slower if not enough there. No work sounds great but is torture
scrum doesn’t make you cooperate. everyone takes a task and is gone
How involved are devs/designers in product choices?
How to scale
Safe framework
Alternative
Kanban. Short primer.
pull based. https://brodzinski.com/2011/09/pull-push-kanban.html
disclaimer that many things can be implemented in scrum as well.
Unblocking things by talking face to face
release a feature when it’s really ready. once or twice per week?
WIP limits. Helps team focus on bottlenecks. Stop developing new features and ship the current ones. Limit context switching
If it hurts, do it more often. (releases)
Dailies?
Planning?
Incentives?
Cooperation
Scrumban
jason fried 6 weeks
Notes Lean from the Trenches
- Capture all important information in one place and decide together what should be done next
- Slicing the Elephant: find a way to cut project in smaller chunks/releases that each bring value to the client. Here: along two axes; type of crime and geopgrahic location
- Acceptance tests regularly
Team
- 3 feature teams
- Requrirements Analysts and Sytem Test teams working with all 3 feature teams
Multiple Standups:
- each feature team
- Sync for speciality (devs, requirements, test)
- Project sync (cross team): one from each speciality, one from each feature team and PM, others
Kanban board
- 1 project board, three feature team boards Lanes of feature team board:
- Ideas
- Features
- Next Ten Features
- Development
- System Test
- User Acceptance Tests
- Production