SCRUM Gone Wrong
The SCRUM team isn't quite Agile. The sprint goals keep repeating, and the rollover is out of control. Frustrated team members get stuck in endless meetings. The stakeholders throw around arbitrary dates and try to push the team onto waterfall schedules. This is SCRUM gone wrong. This week's lesson in the art of Producer Voodoo is all about avoiding the traps and poisons that can ruin SCRUM by offering some healthy tips, tricks and tonics in SCRUM Mastery.
TRAP: Time Estimating
Developers may give overly optimistic estimates and fall short. Artists may give overly padded estimates and stretch out their work. An apathetic engineer may literally roll dice to determine estimates (true story!). It's not that they shouldn't be required to provide some sort of guidance on how long something will take, but it is just not something they may be particularly good at or willing to do. It also over-emphasizes time, considering the product cannot ship without completing the work regardless of how long it actually takes.
Now hold on! No estimates? No dates? Is this a free-for-all? How does anything get done? Well, SCRUM has a solution for that if you do estimating right.
Unfortunately the SCRUM tools often cater to the traditional PMs and waterfall schedulers by allowing time estimates on stories. Alternatively, PMs will translate story points into days. Don't do it! While numbers are still needed to project an end date, the point values in SCRUM use a Fibonacci sequence (1,2,3,5,8,13 etc.) for a reason, so you don't mentally convert them into days. They are supposed to be an expression of work complexity.
When using time estimates or days as scrum points, developers will adjust their pace to fit. You don't want a developer to stretch 3 days of work into a week just because they estimated a 5. Even if they don't stretch the work, they still cause some havoc as they'll run out of work too soon. Likewise, you don't want an overly ambitious and vague estimate of 10 days (the ubiquitous 2-week estimate engineers give when they have no idea), because it could actually snowball into a month of effort.
TRICK: Relative Estimating with a Story Pole
It's better to just see how many relative complexity points they can get done in a sprint (i.e. velocity) and set expectations and pace that way. SCRUM takes the incredibly inaccurate and frustrating time estimating out of the equation. After a few sprints of data to calculate velocity, a project burndown chart can give you a project finish date.
The trick is getting a team to stop thinking in terms of time and instead in terms of relative complexity. This is where a story pole can help (see below). Have your team fill this out at the beginning of the project with common known tasks and stack-rank them based on T-shirt sizes. This will map to SCRUM points. Then you can bring up this story pole every time a new estimate is needed.
Recommended by LinkedIn
POISON: Broken Sprints
The sprint is planned on Monday then pivots Tuesday with revised ideas from product management. A support issue or production fire takes someone offline for half the sprint. Engineers working on a bug uncover some tech debt and disappear down a rabbit hole. These are all ways that a sprint can be broken. Here are some helpful tonics and tips to make it manageable.
TONIC: Backlog Meetings
Like it or not, the requirements are not always fleshed out by the start of a sprint. This is the major reason for marathon sprint planning meetings or Pivot Tuesdays where the stories get rewritten. This is all symptomatic of bad planning and product management being out of control. To solve this establish some sprint rules and a new meeting.
- All story requirements have to be complete and reviewed before the start of a sprint or they don't get on the sprint.
- On the Wednesday before the next Monday's sprint planning, schedule a backlog meeting. This is where product managers and designers pitch their requirements and get some feedback in time to make corrections.
This keeps the sprint planning meeting from becoming a design meeting and makes it easier for developers to provide story point estimates. The developers will already be familiar with and had time to think about the requirements.
TONIC: Tech Debt Tasks
Engineers working on a new feature or fixing a bug will often stumble into some old code that requires some reworking. They don't often get allowed to work on technical debt, so they just try to work it into the task or bug at hand. The healthy thing to do is to eliminate that technical debt when you see it, but that's not always the right choice. There may be an important milestone or a dependency where a kludge fix is a wiser move for the project as a whole. Tackle this with a new task type and enforce a new sprint rule.
- Create a new task type or category called Tech Debt where technical debt can be captured, not forgotten, and stack-ranked against other work.
- A developer who encounters technical debt should create a new tech debt ticket and then approach their manager and the scrum master to find out if it's okay to work on it then or have it wait for another sprint. This gives the team leads some options and say while still ensuring some semblance of certainty that the technical debt will get dealt with eventually.
- Put a story point estimate on the ticket, and if it's to be part of the current sprint, work with the scrum master to remove something equivalent from the sprint.
TIP: Triaging Fires with Support People
Shit happens. Field issues arise. Support tickets come in. Heinous bugs are found by a customer, and maybe they can't wait until next sprint. So here's what you need to do:
- Triage the issue and assign it.
- If it has to be worked on right away, then put it on the sprint.
- Remove other work already on the sprint. This keeps it fair to the developer.
- Assign story points to the effort to ensure the velocity isn't messed up.
- If this is a constant problem, consider having a designated support person who is not assigned any regular stories for the sprint or is given a lighter load each sprint to accommodate.
TRAP: Estimating the Unknowable
Bugs and polish are all forms of unplanned work. Developers works off a bug or polish list that could be added to over the course of that sprint. Polish also tends to be iterative. You work on it until it's approved. Bug fixing is 90% figuring out what you did wrong and 10% fixing it, so how do you estimate what you did wrong unless it's exactly the kind of bug you fixed before? This can cause a lot of rollover work as the estimates are so unreliable.
TRICK: Bug and Polish Stories
For these reasons, it's usually best to just dedicate a whole sprint to bug fixing or polish and put in a placeholder story representing the developer's usual sprint velocity. If they have a velocity of 9.5, just make it an 8 point bug fix or polish story. If they complete the bugs or polish before the sprint is over, they can grab something off the next sprint.
If the number of bugs or polish items are small or you're expecting a light load, you can dedicate a portion of a sprint with a smaller bug or polish story, say 3 or 5 points. Just be prepared to stack-rank the bugs along with the new work tasks. This way if the bugs take a lot longer, they'll know what is higher priority to complete for the sprint.
TRAP: The Swirling Whirlpool of Effort
Making games is hard. Sometimes the first approach doesn't work. Heck, sometimes the third doesn't and you end up going back to the first a little wiser. To a producer, this can look like stories getting rolled over or story estimates getting revised. It is frustrating for the developer, team and stakeholders as no progress is being made, and it is a sure sign that the developer is swirling.
Now, you can just reassign the work or dogpile on it with some pair-programming, but wouldn't it be better to avoid the slips in the first place?
TRICK: TDDs
Whether TDD means Technical Due Diligence or Technical Design Document the purpose and result is the same. Maybe it's a new scary feature and the developer put a 13 or 21 point estimate on it. Worse, maybe it didn't seem scary and the developer put their usual 5 or 8 point estimate on it, but it actually should be closer to 21. This is where a little investigation, planning and peer review can help.
Create a TDD story and assign it to the developer on the sprint before the work is to start. It should culminate with a technical document or wiki page with a plan of attack and a task breakdown.
Instead of dogpiling after the damage is done, put those extra eyes and ears on the effort sooner by having their peers and the technical director or leads review the TDD. They can offer suggestions about the approach and where the code should be added or be made more reusable. They may also see opportunities where some of their contribution might help and have a task added for themselves or a second developer.
The goal is to end up with something other than a 5 point story that swirls into a 13, or a vague 13 or 21 point story which makes it hard to gauge progress. The TDD generates a much more thoughtful task breakdown for sprint planning.
Next Week
We'll talk about Hiring: The Anti-Dick Move. Double entendre intended.
Licensed Instructional Designer | Learning Technology Pioneer | 10+ Years Experience in Multiple Industries and Federal/State Agencies
8moExcellent article, well thought out as in anything you write, Tim. Responses to the W/L balance question that turn my red light on: - We try but when deadlines are due we can work long hours. - Our developers are young and don’t mind long workdays. (You mention this.) - We have to be realistic about time. - It depends on the manager, some are tough. (Indicating lack of a real scrum structure.) Follow Tim’s tips in addressing each of these replies. He is the best game developer/producer Inhave worked with. -
Senior Creative Management Specialist of P3 (Products, Projects, & People) in Game Development (XR, Metaverse, Multiplatform)
8moExcellent description of the critical, almost breathless hustle still necessary for some of the best game development management processes. “[Estimating the Knowable] can cause a lot of rollover work as the estimates are so unreliable.” Indeed, but not without context, of course. Game development - even with ever-improving management approaches and perhaps even (GASP) rarely funded “discovery” opportunities - only continues to become more and more of a primordial soup (with, and without unwanted, internal and external forces, playing havoc). The development participants are reasonably (?) asked / required to be good communicators / estimators / detailers on their stories and of their tasks (one, some, or none of which originated with them) and where legacy components are practically guaranteed to present technical debt rabbit holes (even for some of the most diligent and focused developers). My comments are in no way a complaint. Simply an unflattering acknowledgment that the human condition / elements of game development - without which the very best game development would not exist - will continue to conspire against even the best of the best management approaches. Thanks, again, for sharing, Tim. Good stuff!
I’m a programmer. Code may do many things: some right and some wrong. But it does not lie. Always be kind. Always learn. Always teach. And always question.
8moI agree with much of what you say here — but there’s a LOT of waterfall in there, as well as a lot of opportunity to have a lot of things in progress. Your proposal that a developer can only start on something that can be definitively finished (it’s been totally analyzed, all questions are answered, etc.) sounds good, but who does that work? How are all the peculiarities that can happen during implementation to be revealed without starting the implementation? There always seems to be concern about “there being enough work” … but trying to run at full capacity is a recipe for disaster as any glitch makes everything break down quite severely. I think a lot of the issues that occur in development can be “solved” by putting one very specific obligation on the management side of things. They must always be able to answer the question “what is the single most important thing to do next?”