Changing thought patterns and approaches is one of the harder aspects of a Agile way of working. This is especially true of Scrum which on the surface looks very simple. Indeed you can read the guide in half an hour or so and if good at retaining information probably pass the online multi-choice PSM exam. I’m not knocking the Scrum.org certifications (indeed I’m planning on picking up a few) but I do feel that the CSM offers more as you training from someone who has been in the trenches. Ever noticed the tone of warfare creeping into conversations about a collaborative process! Anyway the point is what the guide doesn’t tell you is all of things that can and do go wrong. One of the main contenders for teams used to traditional ways of working is to waterfall their iteration. Effectively doing iterative waterfall rather than Scrum. So here are six signs that this is, or is about, to happen.
- QA resources have nothing to do at the start of the sprint because the rest of the team are performing analysis and design.
- The board remains fairly static apart from a few mass updates.
- Things remain in the same state for days on end.
- You can’t test one work item because it depends on all of the other ones in that feature.
- The entire end of the sprint is taken up with hectic test activity.
- Most of your items get developed but not tested.
So as an Agile leader what tools and insights can we lend to these situations?
Things to think about:
“Damn it, man, I’m a doctor, not a torpedo technician!”
Is the crew thinking about the success of the mission or just their role? Or to get away from the Star Trek analogies are the Scrum team invested in achieving the goal they committed too or are they interested in achieving the part of that they feel best at? Ideally we want cross-functional teams, everyone is good at everything and people excel in certain areas. This doesn’t tend to always be the picture in reality however there is no reasons that developers can’t run test scripts and that talented QA’s can’t get involved in the development world. The usual reason is people thinking that it’s not their responsibility hence a bit of a team cohesion issue.
Does the team have any capability to automate testing? Teams where the QA works with the developer to automate feature tests or acceptance tests tend to view the work on a sprint backlog item as one continuous stream of effort rather than an analysis, development, test breakdown. I’ll avoid the few thousand words on why test automation or rather automation of development processes is such a great enabler.
Is your scrum board is a little like a graffiti wall? It looks the same for ages and then suddenly seemingly over night it’s all changed. This can be a sign of a few things. Firstly that everything is being progressed at once. This can be addressed by WIP (work in progress) limits on your story board or asking the team to swarm features. Drive home the story of things not being done until they reach the DoD (Definition of Done) and that no value has been gained until items reach this state. Celebrate each feature that reaches done. The daily scrum should also identify if everything is being worked on at once or if things are sitting in the same state for days on end.
If you can’t develop or tests a story because it’s dependent on another then something has gone wrong with your refinement or planning. It’s worth reviewing the INVEST principle especially the “I” part. Lots of dependent work items will force a test heavy end to that features work. Lots of dependent features will force a test heavy end of sprint.
It’s very easy for a team to fall into an iterative waterfall way of working. It’s also easy for these teams to think that Scrum doesn’t work as they face the same problems they always faced. Be aware and beware.