Friday, 18 December 2015

Now that's what I call a plan.

Creating a bunch of stickies never felt like a satisfactory result from planning. This is a reflection on the progress made by one team to create a real plan of how to convert story into software.

Stage 1 - Creating tasks without conversation

The team's planning session creates stickies for various tasks that we need to develop the feature. This is led by only a few of the developers and it is almost entirely directed by them. The stickies represent pretty big elements of work and the estimates are pretty high - most are over a day in length. There are very few testing tasks, which are created by the QA guy only.

  • The team aren't thinking how to do this work - someone else has decided and are dictating the tasks as they see them
  • The tasks are not very granular so detail is being missed and the resulting estimate is not very accurate
  • The team is not owning the QA - they are creating 2 teams which might not join up to deliver the work
Stage 2 - Experimenting with Diverge and Merge

A recommendation from our Agile Coach gets the team using Diverge and Merge to create tasks. The whole team creates tasks in parallel and then they merge their stickies. This breaks the dependency on individuals leading and makes everyone think about what needs to be done. Merging creates conversation as some people think of things that others haven't and we all reach agreement where we have the same tasks. To make this work, it is need to follow the work through sequentially. You can optionally play a game to see who keeps the most stickies on the board, which keeps the session flowing.

  • The team don't really buy into Diverge and Merge but the sequential story of what needs to be done makes sense to them
  • Involving more of the team means we have less direction from individuals - there is more ownership from the team rather than following individuals
  • QA still a secondary process within the team
  • Tasks are still quite large
Stage 3 - Creating tasks sequentially

SM encourages the team to explore how to do the work sequentially, encouraging quieter members of the team to contribute. Larger tasks are broken down and things we often forget also take time are included like documentation, deployment packages, merges. The QA guy is still doing the same thing but SM asks them to explain the approach to the team, which does not result in a lot of feedback.

  • Following a linear path through the tasks makes it easier for the SM to pull developers into the conversation
  • The larger tasks were hiding detail that we need to discuss in order to estimate - breaking them down helps reveal these
  • Asking the QA guy to explain the testing approach helps to breakdown the 'us' and 'them' - it introduces the notion that the whole team should understand testing, led by QA
Stage 4 - Team ownership of Quality

We start the planning by talking about testing not development, which was an action raised in a retro. The team create a basic test plan and everyone estimates the test tasks. There are clear gaps in knowledge as estimates are wildly different - team estimates and indicates which tasks need pairing for knowledge transfer.

  • Talking about testing first influences the order they develop in, so the tasks are a little different.
  • The testing plan being known by the team means they can shift between development and testing tasks - this gives the team more options as to how they deliver the work during the sprint
  • The knowledge sharing is clear and improvements are found easily as a part of the process - no retro needed for this one
Stage 5 - Team collaborates on an approach

The team realise some stories need more thought. If left to the sprint, these decisions need to be made by a single developer rather then by using the wholes teams skills. A retro action is to use a whiteboard session to discuss the approach before a story is started. The sessions visually describe the areas of the system making it easier to spot difficulties or additional tasks that might be missed with conversation alone.

  • Pictures work better and getting people to explain using the diagram helps too
  • This is very Just-in-Time - is there an earlier opportunity for this?
  • Some areas of discussion maybe go too deep - the team sometimes dive a little too deep into implementation.
  • A retro action from the team empowers them to huddle if they need team ideas/consensus - this helps counter only one or two developers deciding things without anyone else knowing
Stage 6 - Planning using a whiteboard

The team move the whiteboard session to planning and then decorate the system areas using tasks as they follow the development sequentially. The team discuss testing as a part of the conversation, making testing more integrated into the development. By grouping the stickies to areas of the system, they are able to see how many of them could work on the story at the same time.

  • The combination of a picture and sequentially discussing the development works nicely - it helps expose tasks the team has frequently missed
  • The team is starting to think more about how the tasks could be done in parallel by picturing areas they can work on without tripping over each other
  • Testing tasks are easier to spot - impacts on existing tests are highlighted quickly
This journey took quite a few sprints. There were regressions as well as advances but when I look back I saw these stages of development. The retrospectives drove many of the changes but we also saw spontaneous creativity - using the whiteboard sessions to plan against, is a good example.

The key thing I saw from the team was a shift in focus. Instead of planning how to do the development, they are now thinking about how to deliver the story. This goes further than a list things to do - it should aim to answer the questions:
  • What order is best to do these tasks in?
  • Who has specialist knowledge that we need to leverage?
  • What does testing look like for this story?
  • How can everybody assist with testing?
  • How can we get everybody working on the same story?
  • What do we need to knowledge share on for the future?
  • What does the final solution to this look like?
  • What are the 'risky' tasks?
  • Who else might we need help from?
What does your 'plan' look like?