Using the agile principles in a scrum workshop or retrospective

Asking team members to rate themselves against the 12 agile principles it a very interesting and useful exercise during a scrum workshop or retrospective. With ICT Institute we are occasionally asked to lead a ‘scrum update’ workshop: a training for teams that already know wand do scrum, but like to do it better. Especially in these workshops, we would recommend this exercise to make the workshop interactive.

A refresher of the 12 agile principles

Not everyone knows that the agile manifesto consists of two parts. Most agile practitioners know the first part, the four comparisons. The second part are the 12 principles. This part is actually a lot more concrete and is thus usable as a checklist to see if you are agile as a team or company. For anyone who left out these principles out of their agile manifesto tattoo, or for those organisations that did not have enough wall space for the full agile poster set, we repeat the principles here (also in Dutch):

1. Customer satisfaction by early and continuous delivery of valuable software
2. Welcome changing requirements, even in late development
3. Working software is delivered frequently (weeks rather than months)
4. Close, daily cooperation between business people and developers
5. Projects are built around motivated individuals, who should be trusted
6. Face-to-face conversation is the best form of communication (co-location)
7. Working software is the principal measure of progress
8. Sustainable development, able to maintain a constant pace
9. Continuous attention to technical excellence and good design
10. Simplicity—the art of maximizing the amount of work not done—is essential
11. Best architectures, requirements, and designs emerge from self-organizing teams
12. Regularly, the team reflects on how to become more effective, and adjusts accordingly

There is a logical order but no priority in these principles. It starts with the customer view and ends with internal steps. The last principle, explaining continuous improvement, is in our view just as important as the first.

Why and when a scrum update workshop

A scrum update workshop is a workshop where agile and scrum knowledge is refreshed. It is a tricky workshop to lead: it is a workshop designed for a mixed audience, where some people are very familiar with scrum, while others are just starting. One cannot use the typical ‘scrum introduction’ material. This would make the workshop boring for the more experienced people who have seen this material already. On the other hand, you do not want to skip any principles that might be of importance to the other team members. In our last ‘scrum update’ workshop the team had just finished a major release. For the team, this was the right time to change their way of working. They had been using a mixture between scrum and waterfall for this major release, and from now onwards they wanted to have frequent minor release and use the best fitting agile approach. For some people in the team this was business as usual, as they were also using scrum in another team. For the product owner, this way of working was new.

Team retrospective approach

For this workshop, instead of presenting our prepared material, we started with an interactive exercise. We asked all participants to rate how the team was currently doing on the agile principles, on a scale of 1-5. We also asked them to pick one or two principles that they wanted to learn more about during the workshop. On the one hand, this was a way for us to get the participants to read all the agile principles. On the other hand, it was a way for us to understand what the team was hoping to get out of the workshop. After each participant had filled in their scores, all the score were shared and discussed. We focused on the principles with low scores and principles were the score diverged. In some of these cases, there was a difference in interpretation of what the principle meant. In other cases, the team indeed had questions on how to bring the principle in practice.

We used the outcomes of the discussion to make a backlog for the remainder of the workshop: we skipped parts that the team already knew and focused on the parts that the team wanted to discuss. It is also possible to do this exercise during the retrospective. As explained in a previous Dutch article, changing the retrospective approach can lead to new insights.

Outcomes

The outcome of the exercise was different from what we expected. We expected ad had prepared some ideas about continuous delivery. The team however had also prepared this well and had no immediate questions. The team did have questions about number 11, covering design and architecture. Luckily we found this out at the beginning of the workshop so we could include this in the schedule. For us this again showed the importance of making workshops interactive. Interactive workshops are more difficult to prepare, but ultimately more successful.

Image: Falcon by DickDaniels via Wikimedia Commons. We previously used a cheetah to illustrate agile articles, but someone recently pointed out that the peregrine falcon is actually much faster and arguably also more agile.