The Implicit Waterfall

There is more than one term for processes whereby teams embed a staged or "waterfall" process within agile and lean approaches. For example, 'ScrummerFall' and 'Mini-waterfall' are both expressions associated with Agile scrum anti-patterns which imply that teams are basically operating an 'over-the-wall' approach to handing work to testers during the sprint. The general concensus of community talks and testing discussions that I have been involved in is that testing should occur early, and throughout, the development of any new feature. Certainly in my organisation this is a critical aspect of our successful development process. From experience I know that it is a natural tendency to hold on to the trappings of processes that are familiar to us and the result can be that teams implementing the tools and rituals that support a methodology in a manner which preserves the trappings of their former processes. For example Whilst the visualisation boards that support agile and lean methodologies are very effective in supporting those approaches when used effectively, there are some fundamental structures implicit within common board layouts that I believe incline unwary teams towards these anti-patterns.

If we examine a common structure of scrum boards that is used for agile teams, for example the scrum boards presented by Agile guru Mike Cohn in his description of scrum boards, we see a series of columns representing statuses for each story/task:-

• Todo
• In Progress
• To Verify/To Test
• Done

The presence of separate columns for "In Progress" and "To Verify" seem to contradict the idea of concurrent testing activities. The reason that Mike Cohn gives for this column is where the task is sufficiently small that it does not merit a separate test card, and that for most stories a separate task card or cards would exist to cover testing activities. From conversations I've had with some testers, this distinction does not seem to have translated well to some teams. Another similar board format, the Kanban board, has the "In Progress" and "In Test" separation as a fundamental element of the board. The following example is from Wikimedia and most example boards I've found in a simple Google image search on "Kanban board" have a similar structure.

If we are suggesting that testing in agile/lean teams should be implicit throughout each user story then why is the verification of tasks both independent and mutually exclusive to their development?  I've had a couple of conversations recently with folks who were having trouble due to this separation. Their Kanban style boards incorporated this 'In progress' and 'In Test' distinction, which was introducing an implicit waterfall mentality in their approach. The developers were not handing over to testing until the coding was 'Done' and therefore missing some of the benefits of collaboration, putting pressure on the testing activities through delayed exposure. 

When introducing scrum boards to our team, I structured our boards slightly differently in a way that I thought would better complement our way of working than the examples I'd seen. I hadn't considered writing on this before as I felt it was very specific to us, however I was chatting with Dan Ashby ( a great enthusiastic tester) at Agile Testing days and showed him our approach and he suggested I wrote on it, so here we are.

The Symbol Based Board

When creating a scrum board for our team I felt that operating at the story level rather than the task level was going to be most appropriate for the team and the nature of work that we were tackling. One of the main things that I wanted to represent in the board was the concurrent test and programming status of the story. In most boards the status of any activity is represented by the position of a card representing that activity, I'll describe this as a "Position Based" layout. The approach that I tried was instead to use a "Symbol Based" approach to represent status. I created a column structure, with the first columns described the story and the people working on it. The next 4 columns could contain a status symbol for the 4 key activities around that story, these being Elaboration, Coding, Testing and Documentation.

I then created a colour and symbol coded set of status for each column. These being:-

Each story was then added to a row on the board and we could represent the status of each activity on the story using the symbols. In this way we have been able to ensure that testing activity is started concurrently to testing activity, and can easily identify issues if any of the columns or individuals have too much in progress at any one time. We can also identify anti-patterns such as developers starting to code before we've elaborated acceptance criteria (this has been known to happen on occasion) and apply the appropriate symbol ("Do Now" symbol in elab column plus target for elaboration immediately).

Rich Text

The final columns on the board are for free notes on any specific targets for that story.

• The first is a target, e.g. external targets such as if the story has to go on a specific branch or be demonstratable on a certain date, or internal targets on when we need specific activities done by in order to complete the others, such as elaboration or first exposure of working code to testing.
• The second is for writing up any blocks, status notes or actions that need addressing. The ability to add these notes provides an ability to add reminders on previous conversations and a richer basis for discussion in stand-up meetings.
• The final one is for any items that need to be raised to follow up with. This acts as a reminder to prioritise further stories we've added to the backlog arising from the work on that one or any bugs that may have been discovered late on in the sprint testing.

Ad-hoc tasks

Being a responsive organisation in a competetive market there are always ad-hoc activities that come in and need to be prioritised. To handle these we maintain a small Kanban style area at the bottom of the board for ad-hoc tasks with color coded cards for :

• Bugs discovered that aren't related to stories in progress
• Customer support investigations
• POC requests

If we have too many high priority ad-hoc tasks appearing on the board then we review the lower priority stories in the main grid and discuss removing some of these with the Product Owner to focus on the ad-hoc work that is coming in.

Examples

So a typical board in progress will look something like this (albeit with more stories - drawing these boards is surpisingly time consuming!):-

and here is a real example from a previous sprint (note the absence of the calendar - this has been added since the photo was taken, the board is constantly evolving)

Limitations

There are clearly limitations to this approach when compared to a position based task board

• Not working at the task level - this might affect the ability to work at a higher level of granularity, however we find that working at the story level gives us a good level at which to discuss our sprint activities in the scrums.
• Burndown - we don't generate a burndown from the board. To be honest we've not found that we need to - we operate at the story level and have a good inherent idea of our velocity as a team. The statuses allow us to identify any bottlenecks or items that are stalling. The Blocked and Paused statuses allow us to see the stories that are struggling and we can add an "AT RISK" comment in the notes area if we feel that a story may not be completed in that iteration. Additionally I have a good idea of testing activity required based on our charter estimates as I discuss in this post. If a burndown was necessary then a simple completed story count (or completed story points, if you are that way inclined) would be easy to implement.
• Moving stories - as we write the stories on a white board we can't move them as easily as cards, however as we work in sprints ideally story content would be reasonably stable, and we do have the ability to add and remove items if necessary. If working with a continuous flow based approach rather than sprint cycles, then the horizontal slots could be restricted, and used to limit work in progress at a story level, adding new items only when one is completed and accepted. Again this would maintain focus on testing and development concurrently rather than separate activities.

We love our Board

So there you have it, my take on the scrum board, the Symbol Based Board. I find that it works very well for my organisation. I have previously attempted to address some of the limitations mentioned with the introduction of a more task-card based board, however the overwhelming response from the team in the retrospective was that they preferred the approach above. When we split into multiple scrum teams the newly created team created their board based on the exact same structure and have kept it since, with a couple of minor modifications.

My sister recently had her first baby. In discussing with her what to expect from others I explained that folks will give you advice in one of two ways, some will tell you what you should be doing, others will offer suggestions that have worked for them in certain situations. Please accept this post as intended, a form of the latter. I'm not suggesting that everyone uses this approach - I'm aware of limitations as compared to other approaches when well used. I'm posting this to provide alternative ideas for those who are struggling with their current boards and the implied practices that come with those structures. If your team is facing problems with an 'implicit waterfall' built into your team boards then I'd recommend trying out a "Symbol Based Board" approach such as this, it is certainly working well for us.