At the Scrum Gathering in Seattle in May, I was quite taken by Adam Weisbart’s open space session on his simple “Build Your Own Scrum” exercise. I had not intended to join his session, until I wandered by near the beginning of it. It was completely different from what I expected, and quite interesting, so I joined one of the groups.
The point of the exercise was to work as a group to arrange a set of Scrum-related nouns and straight and curved arrows in what the group thought represented how Scrum should work. Adam had provided a piece of paper with the nouns and arrows on it, and the pair scissors to cut it into pieces.
During the exercise, lots of conversations emerged around the trade-offs involved in ordering the parts. Should this part come before that part? What is central in the diagram? Should there be one “center” to the diagram, or multiple? Which parts connect to other parts? Was one role more central than another role? Given the relatively few number of arrows, and that most things relate to most of the things in Scrum, what are the most important relationships to illustrate? Which relationships are linear, which are cyclical? How large are the cycles?
The people in my group had lots of experience with Scrum, and it was a rich and interesting set of conversations.
I also was surprised at how much more effective it was to have cutout pieces of paper that you could slide around. It made it very easy and lightweight for people to rearrange the structure. Multiple hands could easily work on different parts of the diagram. Quite people could simply rearrange part of the diagram without having to enter the ongoing discussion dominated by more vocal people. I’m a big fan of whiteboards, and found these pieces of paper to be even more effective since they reduced the cost of change even more.
After finishing our diagram, I looked at the other group’s diagram and was surprised at the differences.
Reflecting on the exercise, I realized that this type of “Build Your Own” exercise could be used in other ways.
Nouns or verbs? Adam’s system has a set of nouns that you arrange with arrows. Our society tends to put a lot of focus on the nouns, but systems thinking, biology, and other fields tell us that the relationships (the verbs) are much more important than the individual entities (the nouns). What would it look like to have a similar “Build Your Own” exercise where the identified entities were verbs, not nouns? For that matter, what are the verbs that are central to Scrum?
Other processes? How about creating a “Build Your Own ____” exercise for other processes? Given that it works well for Scrum, would it to work well for other processes? I would think so.
I got a chance to try out the latter idea in the last week of the Analysis and Design course that I was teaching at University Washington Bothell. Wednesday was the last day of the course, and I wanted an engaging way for the students to reflect upon the range of modeling tools they had been learning to the quarter. One of the textbooks for this course was Scott Ambler’s book Agile Modeling: Effective Practices for eXtreme Programming and the Unified Process.
Would a “Build Your Own Agile Modeling Process” sheet adapted to the content of my course help the students review their course material? It was worth a try. I quickly contacted Adam, asked to use his template as a starting point for mine, and then put together a “Build Your Own Agile Modeling Process” sheet containing the 25 different types of models covered in this course. Given that I had 25 nouns instead of the 15 nouns in Adams system, I included more arrows (turns out I didn’t need that many):
The next day, I walked into my class carrying a tub of scissors and a pile of paper for the students to cut up and rearrange. As one of the students remarked during class, it reminded him of a Montessori classroom. I took that comment as a complement.
First, I asked the students to do the “Build Your Own Agile Modeling Process” exercise. Each team used a pair of scissors to cut up the parts, and then arranged the parts in what they thought would be a good agile modeling process.
As in the exercise at the Scrum Gathering, each team had a different diagram (click on the diagram to see the details):
Two things stood out to me.
Every diagram was different. As in the Scrum Gathering exercise, the students also found a surprising. As one of the students wrote, “The most shocking drawing for our team was seeing our design team showing completely different steps that we expected from them.”
There were far fewer cycles than I had expected. While every team included some parallelism or cycles, 4 of 10 the teams had an almost linear progression through the artifacts. Only one diagram appeared to be highly cyclical, and even that diagram acknowledged some natural progression from initial concept through to the software design diagrams. Perhaps it is related to the linear sequence in which artifacts were introduced into the course. Perhaps it reflected the linear sequence in which the students started using the artifacts. Perhaps some teams were more iterative than other teams in the use of their artifacts.
Next, I asked the students to arrange the models in the order of how important and useful they were during this course.
As a side note, during the quarter each team had worked both as both a design team and the customer team during the quarter. For instance, team A had designed a product for team B, and team B had designed a product for team C. This arrangement solved several important problems. It helped make the design conversations authentic, since the models became a mechanism for the design team to ensure that they actually communicated well with their customers. It highlighted the role of models as a medium for creating understanding. And it forced each team to try to get into the head of their customer team, to understand what their customer team wanted, instead of making up whatever suited them. It also seemed to make the conversations more engaging for the students, though I do not have any hard data for this assertion.
So for the “rank the models in order of usefulness” exercise, teams A and B arranged the models to show how useful the models had been for their collaboration, and then teams B and C did the same. Here is what they produced:
One thing stood out: In general, the software design diagrams were the least useful to the teams. This surprised me and the students somewhat. Some students suggested that this occurred because they did not actually write any software. Without taking the step to code, these diagrams could not fulfill their intended role of helping to bridge the gap from conceptual models to code. That makes sense, and was one reason I wanted to be a will to get to code during this course, though I could not see a way to do that within the 10 weeks available. If you have ideas on how to overcome this, please let me know!
All in all, the students were very engaged during much of the exercise, and seemed to enjoy it. It highlighted some useful lessons about diversity and that there is no one correct modeling sequence or set of models to use. And some students commented that it was a good overview of how much they had learned during the quarter. Once again, I do not have good data about this part, unfortunately.
What do you think? Would you do something like this with a group for process other than Scrum?