In a previous blog post, Improving processes with Lego, I discussed how the Lego Flow Game can be used to show how changes in rules/processes can affect the flow of development, leading onto discussion to identify process improvements.
In the discussions that followed the completion of the Lego Flow Game exercise, my Development Team mapped the delivery process of user stories to identify if/where they could make some improvements. During this discussion we also looked at some metrics that had been collated to help identify where we may want to focus our thoughts.
One area that the team identified where improvements could be made, was the analysis phases prior to development starting. The team’s process included Analysis In/Out (normally undertaken by the Business Analyst), Elaboration In/Out (normally undertaken by an Architect or Developer) and Test Analysis In/Out (normally undertaken by a Tester). During each stage of this part of the process, there was work that would need to be undertaken on an individual basis, however, there was also the need for collaboration between team members.
Analysis of the phased cycle time for this stage of the process showed that each stage only took a few hours to complete. However, the dwell time between each stage was just under a day. This correlated with the user story being picked up at the daily stand-up, being worked upon, moved to the subsequent out column and then waiting until the next day to be picked up by the next person. For example, the Business Analyst would pick up the next story to be developed and it would enter the Analysis In column. They would undertake the required analysis before moving it to Analysis Out. The story with them wait in that column, until the next Daily Scrum where the Architect/Developer would pick it up to undertake the elaboration. Again, on average, this would only take a few hours before the work was completed and moved to the Elaboration Out column. The next day the Tester would pick up the card for test analysis.
The control chart below, shows the average time that user stories spent in the Analysis, Elaboration and Test Analysis columns over the course of three months. During this period, the average time that a user story spent in these columns was 3 days and 10 hours – this includes both time spent working on the user story and dwell time where there was no activity.
It was suggested that we adopt the 3 Amigo’s process. As and when new user stories were moved into the ‘3 Amigo’s In’ column, the Business Analyst would arrange a meeting with a Developer/Architect and a Tester (as a minimum) in order to complete the analysis, elaboration and test analysis together with the aim of reducing the time of the time it took for user stories to be ready for development. It was suggested that these meeting take place following the Daily Scrum. The aim was to complete all the required analysis at the same time with the user story being updated in real time. If further investigation was required by any party this could be undertaken individually following the meeting with colour coded stickers added to the physical card on our Kanban board to show when each element was complete. Once all three stickers were added to the card then it could be moved to the ‘3 Amigo’s Out’ column.
It was agreed that we would experiment with the 3 Amigo’s process. Following the start of the experiment, I ensured that each day following the Daily Scrum a 3 Amigo’s session was held whenever a new user story was brought into the board. The team also got behind this process as there were often more people attending than the three people required, ensuring that there was a shared knowledge and understanding across the team. Over the course of the first month of using the this new process, we reduced the average time it took for a ticket to be ready for development to around day. Then, I went on holiday for three weeks.
As the control chart below shows, the average time it took for user stories to be ready for development started to increase, reaching a peak of around 5 days as I returned to the office in late August.
Although the team had agreed the process which we would follow, it had not been written down and in my absence no-one had taken ownership of the process to ensure that it was adhered to. At this point some people felt that the experiment was failing and that reverting to the previous process should be considered.
I discussed how things had gone with a few of the team and felt that it was worth persisting for another month to see if things could be improved. It appeared to me that the reason that things had gone off track was due to no-one holding the team to account against the process that they had agreed.
I quickly got the process back on track ensuring that 3 Amigo’s sessions took place and that user stories were being updated. The average time it took for a ticket to be ready for development started to fall. Within two weeks the team were back to having user stories ready for development in under a day.
In order to ensure that my absence would not be felt in the same way the next time I would be on annual leave, I wrote down the process. Following a Daily Scrum I showed the process to the team to get their input in order to ensure that I had not missed anything. Once the process was agreed it was shared so that every team member have a copy. We agreed the following:
- WIP (work in progress) limit of four cards in 3 Amigo’s In and 3 Amigo’s Out columns, i.e. a new card cannot be brought into the 3 Amigo’s In column if the total number of cards in those two columns equals the WIP limit
- The next card prioritised by the Business Analyst (BA) is moved from the Next column to the 3 Amigo’s In column as and when required as long as it does not exceed the imposed WIP limit (above)
- The BA facilitates a 3 Amigo’s meeting at 10:00 each day (if required), or, as soon as necessary with members of the Squad who will discuss the new card and undertake any required analysis/elaboration
- The card is updated on JIRA with the outcome of this meeting by the BA and if no further analysis/elaboration is required the card should be moved to 3 Amigo’s Out by the BA
- If any additional analysis/elaboration is required, those attending the meeting should each undertake this as soon as possible, updating the card in JIRA as appropriate
- Once each person undertaking further analysis/elaboration has updated JIRA, they should mark the physical card with the appropriate colour sticker to show that thier work is complete
- Once the final sticker is added, that person should move the card on both the physical board and JIRA to 3 Amigo’s Out
- It is anticipated that a card should, on average, spend no longer that 1 day in the 3 Amigo’s In column
The team were embracing the new process and over the next month the average time it took for user stories to be ready for development remained under a day (see control chart below). This resulted in the team being happy to accept the experiment as over, with the adoption of the 3 Amigo’s as the new standard practice.
Over the next few months the team continued to work to the new process. The new process was shown to be embedded when, due to suffering a double fracture of a finger playing cricket, I was signed off work for several weeks and the team continued to keep the average time user stories took to be ready for development to under a day.
Although the above bullet points were written down, they were a starting point for the 3 Amigo’s process as it continued to evolve over time. The initial 3 Amigo’s sessions were scheduled to happen following the daily stand-up, but became more ad hoc, and were not always led by the Business Analyst. When we adopted classes of service, we also created WIP limits for each class.
Implementing this process had the effect of having user stories ready for development within a day, compared to the 3-4 days it was taking. It also reduced the average cycle time of tickets from approximately 10 days to 7 day. One of the next things that the team needed to focus on is bringing tickets onto the board ‘just in time’in order to reduce the dwell time between 3 Amigo’s and development.