Mini Waterfall in your Agile sprint – Consider your testing role…

How many of you are running Scrum but struggle to get the burndown to be anywhere near the target – more often than not it sits flat and then drops down (to hopefully zero) in the last couple of days. I have even seen teams whose “target” burndown is a similar shape, they’d given up ever trying to get close to that constant gradient.

This is because the teams run mini waterfall inside their sprint. Each team member has their own role and the work is passed person to person (with a note saying, “done my bit, your problem now”) just like a whole project would be in a waterfall SDLC.

The most critical of these handovers is from a Developer to a Tester. This seems perfectly sensible, we know developers, we know testers, there is a natural flow of work. However this approach is fundamentally rooted in the past, reflecting practices and technologies which should now be dim and distant memories.

Firstly the tester role used to be more of an operations role, an experienced user trying every permutation they could think of to check it works. Now we are asking them to be more technically capable so they can test pieces of a flow, stubbing out inputs or outputs.

With an incremental delivery everyone has appreciated the importance of an automated regression test suite and as that has the word “test” in it –well give it to the tester. So there are teams out there with developers writing code and the super technically capable testers writing automated test scripts around it.

Stop everyone! This is taking the traditional siloed waterfall practices and hammering them into SCRUM until they almost fit. It is inefficient and enables individuals in teams to avoid ownership of delivery.

SCRUM is a reasonable approach for work management in iterative development but it has little to say on the technological approach other than the team members should be cross functional, to really get an Agile delivery to work you need to support it with XP – and inside that is the answer to the burndown gradient issue.

Within all the other good stuff in XP is the concept of TDD, Test DRIVEN development, where we write tests inside the code before writing the actual code. The important consequence of this for this piece, is that it is the developer that writes it. So the developer writes the code AND the tests. Horror screams the testers, for two reasons:

  • “What about me, am I just redundant now?”
  • And then secondly – after calming down for a moment – “we don’t trust the developers to check their own work, developers think differently to us, we consider all the options etc”

The first is an issue, the second a valid point and the solution to the first. If we change the focus of the tester to assure the work of the developer rather than the code (with focus on the coverage and approach of the automated tests) then the role brings genuine value to the team without necessitating an awkward handover.

I’d support renaming this role to be Quality Assurance, giving assurance to the team about the quality of the work done, this frees up the term tester for where it belongs and originated from. Genuine users in operations that can use the system to ensure that it does what is needed, ensuring there is no gap between what was designed and what was needed.

Operating with this approach will ensure that all team members are equally busy over the duration of the sprint and stories are pushed to “Done” consistently over the sprint rather than being pushed to a separate Test function who then close stories out at the sprint end.

As always happy for comments edits suggestions etc. @philagiledesign

Ever had a huge team and split it down to see if things would get better – I did

Seven to nine, as many as it takes to eat two pizzas, there are many analogies as to how big your Scrum team should be, and most people target this and run with it. But what is the consequence of teams that are larger, are there any benefits?

I was in a situation with what looked like a group of normal sized teams until after a closer look it was apparent that the teams were not cross-functional and that half the skills sets had their own separate independent teams, so we had siloed teams by function – just like a waterfall delivery. As a first step towards an agile transition, people from each “skill” team were added to the original, developer-centric, team. That created what looks like a cross functional team, although inside each we still had a set of defined responsibilities; but that is an issue for another day. What it did create was the rather unusual situation of Scrum teams with headcount in the 18-22 range, something I had never come across before.

Now according to research, pulled on by Mike Cohn in “Succeeding with Agile”, teams of 4-5 deliver the same output as teams of 15-20 in two thirds of the time and obviously at a third of the cost, but this was comparing different teams, with all the other variables between them unknown.

First a quick summary of the issues with large teams:

  • Cost of relationships – just too many people to try to understand, and without good relationships we introduce process, and process is waste
  • Time for collective understanding, to get everyone to the same level of understanding on a time is exponentially time-consuming because statistically there is more likely to be an individual with a lower level of understanding of the situation the greater the group size
  • Overheads on process ceremonies – just takes longer to run a standup
  • Social Loafing, the subconscious behaviour to lower individual effort when in a group, proportional to the group size

It wouldn’t be fair to say that there aren’t well documented advantages to larger teams, the most obvious is that larger teams have fewer team to team contacts that the same number of people would have in smaller teams, so there are fewer dependencies to manage.

With these monster teams, the bureaucratic overheads were soon too much to bear, we knew they would have to split down and therefore gave us the wonderful opportunity to directly compare effectiveness by team size. I had a cursory look on blogs, articles etc for examples of this to give me some guidelines or predicted outcomes, but could find nothing, I suspect because it is so unusual to form teams of this size.

So I worked with a team to discuss the issues surrounding team size. I then asked them to each consider their current team productivity as 20 units. Not velocity, more a personal nebulous concept covering all professional activities – I am sure each person had a different understanding but that is no matter as we were only going to consider relative references.

I requested the team then self organise into 5 units – this was very hard because they are role based individuals with fewer than 5 for some roles, leaving some teams with no test capability for example. Each team was asked what their average productivity was now, and predictability it was lower, Critically, summing up the productivity across all the teams came out as less than 20, suggesting that they would be better all together than as five teams.

The exercise was repeated for 2 then 4 and then 3 teams each time understanding what was good and what was less than ideal with the structure.

Finally I asked everyone to stand along a line representing 1 team to 5 teams – like a linear constellation. Majority were for 3 a few 2s and 4s. We had a small debate between the 2s and the 4s and then asked them if they would each consider a 3 sprint trial to 3 teams, after which, if not happy then we’d repeat this exercise but of course with a lot more knowledge.

The “experiment” would be measured through a collectively agreed a set of personal, abstract values such as collaboration, communication and happiness and set them all to 10 at the start; then each retrospective people would compare now to then to give a sense as to whether things were better or not.

So what happened…..

Well those values were a little scatter gun after the first sprint, some up, some down and some teams much more positive than others. From Sprint 2 onwards you could see a general rise, with a poor sprint temporarily bursting the bubble. We are now three months on. There is no question of reverting back to a single team, the values are no longer recorded but would all be approximately double the starting point. I think a key contributor to the improvement was the fact the teams self organised – it was their decision to be in three teams and their decision as to who would be in each of them, people fight harder to make something work if they come up with the idea – gives a sense of ownership.

Regarding velocity – which we all know is a poor indicator of productivity – the original single team had a velocity of 20, each of the three new teams now has a velocity of 20 which supports what Mike Cohn’s text had implied that a small team could deliver as much output as a team three times the size.

Contact me if you want further details on how the split was facilitated or the metrics used to track benefits.