Agile Training Day

This was my first Agile Day ever and had no idea what to expect.

We all made our way up to our snazzy offices at Fenchurch Street in the Walkie Talkie building. The hustle and bustle of the people, taxis and buses of London felt a world away from Horsham. A nice change for the day. Once we made it to the meeting room and all arrived…we started our Agile training with a much needed cup of coffee/tea and lovely cakes that had been left for us. Thanks RSA!

We had been given a ‘Backlog’ for our day, some of which included an Agile Clock, Lego flow game and a Kanban game?!!! This all sounded intriguing but I had no idea what the day had in store for us.

DCIM100GOPROGOPR0379.

Darren who was taking the day started with a nice ice breaker…we all had to stand up and he put an object in one corner of the room. He then shouted a statement to us i.e: ‘I think RSA is agile’. The more we agreed with the statement the closer we moved to the object. We joined in with various statements, agreeing or disagreeing with them which opened up interesting conversation about how agile we thought our teams were.

Darren then set about adding some of our ‘backlog’ tasks to the wall turning it into our ‘Scrum wall’ putting them in the ‘To do’ column. Rob was then given the job of moving these across into ‘In  progress’ and ‘Done’ during the day. This is how we track tasks across any normal project within a sprint.

Meghan was put in charge of time-keeping which made sense as we had time allocated to each task. The first being the…’Agile clock’.

The agile clock was all based around the ’12 Agile principles’ which are:

  1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
  2. Welcome changing requirements, even late in development. Agile processes harness change for
    the customer’s competitive advantage.
  3. Deliver working software frequently, from a couple of weeks to a couple of months, with a
    preference to the shorter timescale.
  4. Business people and developers must work together daily throughout the project.
  5. Build projects around motivated individuals. Give them the environment and support they need,
    and trust them to get the job done.
  6. The most efficient and effective method of conveying information to and within a development
    team is face-to-face conversation.
  7. Working software is the primary measure of progress.
  8. Agile processes promote sustainable development. The sponsors, developers, and users should be able
    to maintain a constant pace indefinitely.
  9. Continuous attention to technical excellence and good design enhances agility.
  10. Simplicity – the art of maximising the amount of work not done – is essential.
  11. The best architectures, requirements, and designs emerge from self-organising teams.
  12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts
    its behaviour accordingly.

We had to summarise each of these and visualise them (with stickman drawings). Each was written onto a post note and then displayed onto our hand drawn circles which would become our agile clocks.

thumb_IMG_6728_1024

Agile-clock-1

DCIM100GOPROGOPR0198.

Once this clock was completed we  moved it from ‘In progress’ to ‘Done’. The next task in our ‘Backlog’ was the ‘Lego flow game’!!! Now this sounded like fun!!!!

The Lego flow Game is a fun exercise to compare and contrast different approaches to processes, with respect to how work flows. The aim of the game is to build Lego Advent Calendar items, with a defined workflow: finding the next advent calendar number (analysis), finding the matching set of lego pieces (supply), creating the lego item (build) and checking that each has been built correctly and robustly (accept). There are specialist roles for each stage in the workflow – analysis, suppliers, builders and acceptors – as well as an overall manager, and some market representatives.

The game is run three times, each for a different type of process – batch and phase driven, time-boxed and flow based.

.thumb_IMG_6730_1024 thumb_IMG_6734_1024

We discussed what worked and what was challenging about the policies after each round. The goal is start thinking about pros and cons of different approaches rather than trying to prove one way is better than any other. At the very end, showing the Cumulative Flow Diagrams provides another way to compare and contrast the different rounds with respect to flow. If you have time, you can also ask teams what other policy changes they would make to try and improve their processes and performance, and maybe even try them out and capture the metrics to see.

We all agreed that working in batches was the least productive way of working but working on a flow based approach worked best.

Once we all finished with this game we decided it was well and truly time for a lunchbreak. We made our way to the RSA cafe which had views over the Tower of London and the Lloyds building to name but a few.

After lunch we then decided to tackle one of our other tasks in our backlog. The next was the Kanban game!!! “As an agile course participant  I want to play a board game so that I understand the mechanics of Kanban / flow / pull / WIP whilst playing a competitive board game!”

Kanban

The game is played in teams of four to six people, one game per team. Each team has a playing board representing a Kanban task board, and a collection of story cards representing work to be done. Teams compete to maximise profit by optimizing the flow of work.

Kanban game

During the game the teams construct charts based on data from the game including a Cumulative Flow Diagram, a Run Chart, and a Lead Time Distribution Chart. Simulated events occur throughout the game to challenge the teams and require them to make various system design, prioritisation, and resource allocation decisions.

The game certainly got competitive when extra money was up for grabs for the winning team after the first stage. It taught us all about the system of Kanban and making decisions that will influence the workstream.

After playing this board game for over an hour and half we decided it was time to admire the views from the top of the building in the Skygarden and grab a team drink or two!

Overall the day taught us a huge amount about the different ways of being agile within a scrum team and how we can bring some of these ideas into the workplace.

Thanks Darren for a great day!