Agile & Scrum foundations (business edition)

(image by EPAM Bulgaria)

“It was very useful, and I had quite a lot of fun… please keep it this way”, I was told after we completed the Agile & Scrum foundations training for business and administration edition. And I felt happy… really happy for delivering the training in a way I believe every training or talk should be delivered. To tell the full story - it is one of the few things I remembered clearly from WEBIT ’11, until today. The mantra was constantly repeated by Marvin Liao (Yahoo) “useful + fun = valuable”, and it became something I truly believe in.

It was challenging, but also interesting to adapt the training for the business team so they, not only understand what Agile and Scrum in software development is, but also get something useful to implement in their work and even everyday life.

So, they got a game to create product backlog, and learn how to write user stories and acceptance criteria. Followed by prioritizing, estimating and committing to items from their backlogs for the week (sprint).

We taught them simple relative estimation (by sizes) techniques, but also the folks experienced the ‘entire joy’ of playing planning poker and how difficult it could be to agree on a simple ‘5’ :).

In the middle of the training we did (my personal favorite) sprint simulator game where the experience included some random / real-life events, which could happen during the sprint and the teams had to adjust and adapt to.

And we ended up with review on the last day of the training, where the teams had to present if they managed to complete their sprint goal and demo the results of the completed user stories, followed up by retrospective session to inspect and adapt. As a trade-off the topic of XP and some of Kanban was kicked-out, but all for good.

It was so much fun, and the vibe and energy were amazing. It’s really cool to train folks not involved in software development in Agile & Scrum.

--

Here is some of the feedback, as usual:

‘The idea of involving non-tech people in such a training was pretty cool in general. I liked a lot the way, the additional sessions were presented. It was very useful not only to learn the general information about Agile/Scrum but also to see it in practical exercises and examples’

‘I liked the most the part with creating our own backlog (product) where everyone should focus on defining epic, user stories and AC / tasks for them. It helped a lot to have better idea of additional tasks and how to prioritize in a good way’

‘The training gave me the opportunity to understand that flexibility is important, as well as change, during project management’

‘It should have been a little bit longer – there are many other useful practices, which we could learn. I am waiting eagerly for e second edition of the training’

--

And yeah, it was privilege and real joy to train such enthusiastic and energetic group of people.

Agile games 2 (scrum introduction, icebreaker, energizers)

I. The airplane game (introducing Agile principles and importance of team work)

It is meant to be fun and entertaining way to introduce teams to Agile. The game  point out how important is the team work, collaboration and spirit in any agile team.

Different types of the game could be played with one or multiple teams (in order to introduce, competition).

1. Preparation
* Print a number of copies of each / some of the airplane/s
(you may use the free plane designs at funpaperairplanes.com)
* Prepare materials - paper, scotch, color markers
* Prepare a chart / list to record each team's results
* Have some extra folks to fill the PO role (outside of the team) for each team and SM role (could be a part of the team) to facilitate

2. Rules
* A team gets one point for each PO's accepted basic plane and two points for each advanced plane. One point is deducted for each failed delivery plane
* Sprint length is 5 minutes. 1 minute for Sprint planning and 4 minutes action
* Demo to the PO/Stakeholders/the other teams is done after the sprint is gone
* Team must choose how many planes could be taken for one sprint, during the planning. The team may take one basic plane, but then it is mandatory to take one advanced before taking one basic again, and so on. (backlog and priorities)

3. Acceptance criteria. You may play with the acceptance criteria and add more (to differentiate) for each sprint.
Example:
S1: plane must fly over 1 meter of chairs; plane must be colored in the team color; each plane properly folded; test infrastructure
S2: plane must fly over 2 meters of chairs; plane must be colored in the team color; each plane properly folded; test infrastructure
S3: plane must fly over 3 meters of chairs; plane must be colored in the team color; each plane properly folded; test infrastructure; plane must have the team logo (simple logo)
S4: plane must fly over 4 meters of chairs; plane must be colored in the team color; each plane properly folded; test infrastructure; plane must have the team logo (simple logo)
etc...

4. Start by explaining the game to the team/s. Explain that the goal is to produce airplanes, the sprint length, the points system, etc...

5. Select a PO (outside of the team) for each team and SM (could be a part of the team) to facilitate. Communicate secretly with the PO/s and give them the acceptance criteria for each sprint. Instruct the PO/s to only share the AC if asked during planning.

6. Show a common backlog consisting of 1 basic, 1 advanced, 1 basic, 1 advanced plane, so on.

7. Start sprint 1 and let the team self-organise and perform in 5 mins.

8. The team/s to do a demo with the planes created; The PO/s have to approve or disapprove the planes after testing.

9. Continue with the next sprints.

10. In the end summarize the score and retrospect over the experience


II. Candy introductions (icebreaker)

It is a fun and relaxing get-to-know-your-team-mates game.

1. Preparation
Get a bag of candies with different colors. Put them in a large bowl.

2. Let everybody get different color candies.

3. Explain the rules to them, and what they have to share before eating each candy:
Red candy - favorite hobbies and activities
Green - favorite places
Blue - favorite memory
Yellow - dream job
Orange - anything the person would like to share


III. Energizers (warm-ups)

3.1. The shoe size
1. Let the team members form a line related to their shoes size as qfast as possible.

2. Let them one by one announce their shoe size to check if the order is correct.

3.2. Untangle
1. Let the team members come close.

2. Ask everybody to hold the left hand of somebody with their right hand. //no grabbing the hands of people next to you

3. Ask everybody to hold the right hand of somebody with their left hand. //no grabbing the hands of people next to you

4. Ask everybody to try to untangle and form a circle.

3.3. Human body star
Ask the people to pair up with a teammate and form a star with their arms/legs bound together.

The 'bouncing spaghetti' burndown

Haven’t seen such a bouncing (up/down) burndown chart for quite a while. And the last sprint for my German team was really ‘interesting’, meaning hectic. We are in the middle of some software qualification activities so the Sprint main goal was a couple of stories related to qualification of different modules.

The chronology of the time events will probably help in understanding what really happened:

The sprint planning (08.May) was well executed and the team committed to a number of stories and a total time of about 150h remaining with only 3 developers and 1 test consultant.

Over the next sprint day additional task was added.

On the 12th of May after the Daily standup we updated the time (most importantly the remaining time values), leading to almost ‘ideal progress’ according to our planning and the ‘average velocity’.

Over the next couple of days the progress was going almost close to the ‘ideal/average velocity’.

Then on 19th May, our test consultant, could not fully contribute to the remaining stories and tasks anymore. So he decided (in agreement with the Product Owner /PO/) to add a new story and a couple of tasks to it. He could not estimate precisely the tasks and put some very big numbers as ‘remaining hours’ pushing the chart up significantly. Some unplanned support requests were also added to the Sprint backlog at that time with high priority.

Over the next 2 days we still logged the proper story time and re-estimated the new tasks remaining time (as it was more obvious what is achievable at that point) but the reduction was not enough and it seemed some of the stories would fail.

On May 22nd our PO came in distress and announced the due date for all the qualification activities has been shifted significantly forward and we need to take more stories for the sprint. He also partially joined the team as a developer to help with the new items. Luckily for us a colleague from another team also fully joined, and another colleague was supposed to partially join to help with the increased work. So the team size happily increased by roughly 2 more developers.

Nevertheless our progress in the next couple of days was slow due to impediments, issues and slow progress for the unplanned work. On May 28th my team in Bulgaria had some extra space and the remaining of one of the stories in the middle of the sprint backlog (‘average priority’) was transferred to them for completion. At that day we calculated the progress and decided on items to kick-out and focus only on the top prio activities resulting in better planning for the next three days. Yes, three days – it was already expected and announced (over the Sprint planning) we are going to work on the last Saturday of the Sprint too.

Finally, in the evening of May 30, the code changes were released successfully and the top stories were completed and approved. The support requests were also successfully delivered. The trade-off was some lower prio items on the bottom of the backlog.

---

A lot of the Scrum-book prescriptions were not followed to allow the team to remain ultra-flexible (e.g. scope freeze in the beginning of the sprint, team size changes during the sprint, transferring stories to another team, re-prioritization during the sprint, adding extra /weekend/ day to the sprint, skipping retrospective /just this time, to allow more time for delivery on the last sprint day/)