Sunday, 10 November 2013

Textual description of firstImageUrl

The Implicit Waterfall

http://commons.wikimedia.org/wiki/File:Smoo_Cave_Waterfall,_Scotland_.jpg

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.

http://commons.wikimedia.org/wiki/File:Kanban_board_example.jpg

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.

Empty Board

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

Board Symbols

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

Kanban Area

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!):-

Example In Progress Board

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)

Real Example Board

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.

6 comments:

  1. Thanks Adam for sharing it across! I totally agree with the benefits of structuring the board in this format. This clearly tells what each team (dev, test, doc) is doing for the story as against the Kanban board where In Progress is kind of saying only Dev is working on it. In my previous role we found the mini-waterfall model was working resulting in late drop to test and structuring tasks in this manner can clearly avoid it.

    ReplyDelete
    Replies
    1. Thanks Shilpa,

      It is good to know that the problem is a genuine one and I sincerely hope that my post here will encourage you to try this type of board, or maybe even come up with your own.

      Adam

      Delete
  2. Great post Adam & thanks for sharing your modifications to the scrumboard. It's all too easy for teams to pick up the standard board & consider the details as the default.


    There's some great ideas in there, but I have a couple of questions, the answers to which might help me out my current pickle:

    1. How has the Symbols board stopped you applying the staged / waterfall approach? Do you manage the work differently (other than changing symbols instead of moving cards)

    2. How do you know the progress of a story after it has been completed in Dev & Test?

    3. Is it important for you guys to be able to tell the state of a story at any particular time in its lifecycle?



    I think I'm missing something in your problem statement though.

    I thought I understood your problem as typical scrum boards exacerbate the practice of "throwing code over the wall" by separating Dev & test into seperate columns.

    Your solution to this problem (as I understood it) is the Symbol Based board, but from the phyiscal appearance of the board it appears as if you still have the "wall" between Dev & Test.


    So even though you're not moving a physical card through different positions on the board to identify workflow, for me, having any kind of division between Dev & Test on a board is likely to promote the over the wall anti-pattern in working practices.

    We had similar problems (with the staged-within-agile approach) at my previous shop, so we stripped away the extra divisions on the board & were left with: To Do, Doing & Done.

    This resulted in a massive cultural shift & approach to development.

    Applying Trinity / 3 Amigos methodology, we would have a Dev, Tester & Business stakeholder at a story kick off in order to identify what was required.

    At this point the story card was in "Doing". From here on in, the story had to remain in "Doing" until the feature was released into Production where it was moved to the "Done" column.

    The ad-hoc work was treated like any other story & prioritised as such. If the work needed to be expedited, then the Dev pair & Tester who were on "house keeping" at that time picked up the work to push it through.

    These new working practices & WIP limits really helped to drive out blockers - no longer could work be dropped because of a dependency - the team working on the story had to overcome the blocker (admittedly with some great support)

    This processes wasn't all rosey either though - it brought about it's own set of challenges :-)

    Duncs

    ReplyDelete
    Replies
    1. Duncan,

      Thanks for taking the time to comment and for the thought provoking feedback.

      To address your main point

      "but from the phyiscal appearance of the board it appears as if you still have the 'wall' between Dev & Test."

      The problem statement that I gave is not that some boards present development and test efforts separately, it is that they present them as mutually exclusive, a card cannot be in both columns at the same time and therefore the waterfall mentality is built in. With the board that I present here we can endeavour to detect and prevent the mini-waterfall scenario by aiming for concurrent dev and testing activity on any row of the board. I agree that this does still imply that development and testing are separate activities, in my organisation it is the case that we do distinguish between 'developers' and 'testers' - I know that some teams don't, this post is probably less relevant for those teams. The key difference here is that - by representing the dev and test by symbols, both activities can take place concurrently and we can target this as something to aim for.

      In answer to your question "Do you manage the work differently" - yes. What we do is to use the board to make sure that we are doing the right activities at the right time, and identify anti-patterns such as an 'over the fence' type development through the relative statuses of each activity. If the dev column shows as in progress yet there is no activity in the testing column then we can identify this as an anti-pattern in our stand-up meetings and address it. The board in itself does not prevent mini-waterfall, however it allows teams who want to avoid that problem to identify when it occurs.

      I think that your idea of having simply 'in progress' as a status is a great one. For many successful teams, particularly in agile, the removal of delineation between development and test entirely has been key to their success. As with any approach, I can see how teams could still fall into bad habits - in the extreme case a team could be throwing code over the fence at the tester within the single 'In progress' status. As with any tool whatever approach we choose needs to be backed up with the appropriate cultural discipline, which it sounds like you definitely had. It sounds like the changes that you implemented were driven by a genuine team desire to achieve that 'cultural shift', as well as changing the tools. In terms of our culture we also have many other practices in place, very much in line with your '3 amigos' at the story kick-off, to encourage collaboration. We still depend on our culture to use the information that our tools present us with to make the right decisions. The board that I describe simply helps to present certain information more clearly, if that information is important to us and allows us to make relevant decisions, then the board is doing its job.

      In terms of your other questions

      2. How do you know the progress of a story after it has been completed in Dev & Test?

      Once it has been completed in Dev and Test (and documentation) it is done - our trunk code will get built as the next product release, we don't have to do anything else such as a push to live.

      3. Is it important for you guys to be able to tell the state of a story at any particular time in its lifecycle?

      Not really, other than discussing on a daily basis in the standups how it is progressing. We do have the confidence levels in the testing Criteria, Risks and Assumptions which we can look at to give us an interim status update, however we generally rely on verbal communication to identify where it is at. I'm not sure that I'm answering what your are aiming at here, please let me know if I've missed the point.

      Many thanks for the interesting and challenging comments, I hope that I've given a good explanation but I'm happy to discuss further on any point.

      Adam.

      Delete
    2. The pleasure was all mine :-)

      My questions came from me leaping to assumptions about how you guys use the board & where the format of the board came from whilst I was writing the response to your post. I realised this, so I turned the statements in to questions in order to get a better understanding of how the board came to be & how you use it. I'm so glad I asked the questions now!

      Ah - mutual exclusivity! I'd completely missed that, thanks for clearing it up. One anti-pattern we had was that people would place the card on the line between Dev & Test to show some back-n-forth activity...

      I really like the idea of being able to show the different people working on the story - I can see how that breaks down the anti-pattern.

      What is great is that your board is growing organically from you & the team, as opposed to being mandated upon the team. That must really be a great help for breaking down the cultural barriers. As you mention, the board is just another tool & its important to use it wisely.

      Question 3 was more about some teams needing the distinct columns in order measure time in each state to help identify bottlenecks. Other teams are happy with just a story being In Progress. Do your processes &/or your board help you identify bottlenecks? It does sound like you have a great collaborative team, so perhaps this information isnt required from the board.

      Duncs

      Delete
  3. Really interesting ideas. One of the teams I work with is having some issues with how writing the automation tests fits in their process, so I might have to adapt what you've got here. I'm also seeing how it could work well with Kanban. I'll let you know what we go with.

    Finally, Dan was right - it was worth telling us about it.

    ReplyDelete

Thanks for taking the time to read this post, I appreciate any comments that you may have:-

ShareThis

Recommended