Scrum Gone Wrong (part 1)
How the agile process can backfire
The Scrum Agile development process has become the de-facto standard for managing software developer teams. It can be a very effective tool for managing work, and is usually better than no process at all, but there are some pitfalls to be aware of.
No matter if your sprint length is 1 week or 4 weeks, the big, epic, important work often doesn’t fit into a single sprint, which can be a point of frustration for developers, especially the more senior developers that want to take up that kind of work. Imagine a requirement comes up that involves spinning up a new service to support a new feature. Senior developer Joe writes a design doc, does some high level estimation, and comes up with an estimate: 3 months.
Scenario 1: Joe builds the service for 3 months, periodically giving his status, which is difficult to decipher and track since the work was never broken down into well defined chunks, and giving status updates is not one of Joe’s favorite activities. The team read the design doc, but isn’t tracking Joe’s project that closely beyond the code reviews that keep getting thrown their way.
This first scenario can be considered our base case: the antithesis of the modern agile process, but perhaps the dream job of many developers.
Scenario 2: Joe is told to break the epic into a half dozen smaller stories, all of which are tracked in some loathed tool like Jira. Joe works on the project, being prodded to update his story burn down daily and groom the future stories in the epic during sprint planning. Joe feels stressed when his stories slip and annoyed when they finish too early, since he has to pull in the next story ahead of sprint planning. Joe perhaps finishes the project a few days later than he would have if left to his own devices, due to the time wasted documenting work to be done in Jira, going to meetings, and dealing with sprint cycles.
This second situation describes Scrum being applied to a team with minimal collaboration between members. Without a collaborative environment where multiple developers are working closely together, Scrum provides some benefits to managers in the form of better project tracking, but feels like it increases friction and overheard to getting real work done from a developer standpoint.
Scenario 3: Joe breaks the epic into smaller stories, but during sprint planning something more urgent comes up and is assigned to Joe. 2 weeks later, another story is on the critical path for a feature launch, and is given to Joe to ensure it gets done as fast as possible in the new sprint. Every now and Joe gets to work on his new service project, but most of the work gets done by other team members (often randomly slotted in with no context every sprint).
In this scenario, Joe has a manager who’s decided that Scrum is a great process to throw the most senior developers at the critical path/on fire work every sprint, while treating the others as exchangeable workers for the lower priority work. The sprint’s critical path/on fire work gets done quickly, but everything else falls behind due to the amount of context switching. This is a dangerous trap to fall into. Just because an epic is broken up into 2 week stories doesn’t mean you should randomize which developer works on it every 2 weeks. This can lead to frustration due to the amount of context switching, as well as burn out of the developers that you constantly put into the line of the critical path.
Scenario 4: Joe breaks the epic into smaller stories, but occasionally during sprint planning is given another developer to work with. Joe fills out the stories in even greater detail than he otherwise would have now that someone else could be doing the implementation, answers questions during sprint planning, and works on the project in parallel with other team members throughout the time. When Joe needs to take a week off with the flu, other developers have context and can help continue the project in his absence. The project gets done faster and Scrum helps coordinate the work among multiple team members.
In this ideal situation, Scrum lets developers (and managers) communicate and collaborate closer, leading to overall productivity gains, even with the overhead of the additional process.
Lesson 1: don’t expect Scrum to offer much, if any, benefit if the team is too small and developers are working mostly independently on features without collaboration. Scrum adds overhead and process to improve collaboration, but the gains only exceed the losses if there’s enough potential for collaboration.
Lesson 2: don’t throw senior developers into the critical path every sprint. Even if it speeds up your timelines in the short term, in the long term it prevents other developers from growing and burns out the senior people.
Lesson 3: don’t randomize which developer works on an epic every sprint. Context switching is expensive, even if it only happens every 2–4 weeks.