When teams adopt Scrum for the first time something I’m frequently asked is what various team members should be doing while X is going on. For example:
- What should testers be doing while code is being written?
- What should developers be doing while the code is being tested?
You can also see this when developers “move on to the next feature” while the existing work is being tested. This is a bad sign.
As engineers we want to feel busy. It’s very counterintuitive to us that us doing less work will help the team overall (read The Goal and The Phoenix Project if you don’t believe me). But, even accepting that what should developers do while testing is going on. Surely they can’t sit around doing nothing?
The answer of course is a resounding “No!”
Scrum refers to “Developers” however it makes it very clear that a Developer in it’s context is anyone who actually builds the product. To quote the Scrum Guide “Developers are the people in the Scrum Team that are committed to creating any aspect of a usable Increment each Sprint.” This means that Developers, Testers, Data Engineers, UX Engineers, cloud engineers, and any other specialism or job titles you can think of are all Developers. In Scrum Developers are accountable for:
- Creating a plan for the Sprint, the Sprint Backlog;
- Instilling quality by adhering to a Definition of Done;
- Adapting their plan each day toward the Sprint Goal; and,
- Holding each other accountable as professionals
We don’t have Design -> Build -> Test phases within a Sprint, this is what I refer to as The Lock Complex. We don’t have specific people for particular tasks. Developers collaborate when designing features, they work together to build them, and they test them as a team. A tester can provide just as much insight when designing how a particular backlog item will be created as a software engineer and likewise someone who has a lot of programming knowledge will think of ways of testing functionality that a tester won’t. They may even be able to support the automation of these tests.
When you see Scrum Team members sitting back and explaining why it’s not their job to do a particular task on a Product Backlog Item it’s a warning sign.
However, there will always be time when someone getting involved with a specific task will slow down key people. When this happens we should look again at The Phoenix Project and The Goal to understand how to best utilise these people. We know from these two great books that if we have key people who are on the critical path to delivering the Sprint Goal then we must not do any PBIs which will create additional work for these bottlenecks. What we should aim to do instead is any work which improves our ability to do work. In a rough order of preference I advise:
- Something which will contribute to the Sprint Goal but will not place extra stress on people on the critical path
- Something which will take work off those key people (for example investing in test automation to limit our reliance on manual testers)
- Anything which has been identified in retros to improve effectiveness/quality of the team which will not impact the Sprint Goal
- Anything which will improve your personal effectiveness (such as L&D) without negatively impacting the Sprint Goal.
When Developers “start on the next piece” what they are doing is running ahead and preventing the key bottlenecked resource from engaging in the design process. This creates a vicious cycle because the most pressed skill areas even less consulted in the refinement stages. This leads to poorer estimates, less well scoped requirements, and even more pressure for those people during the upcoming Sprints. Instead, by taking some of the suggestions above the Developers who are not delivering the Sprint Goal can make life easier for the entire team resulting in higher quality and effectiveness for everyone.
What do you do when you’re not on the critical path? How do you support your colleagues or do you tend to move onto the next piece of work?
dotdotdev.com 