This is the second installment in a two-part series on using games to teach Agile principles. You can read Part 1 here.
The Drawing Game
"There is a very old game that I use as a coach," says Dusan, "which helps reinforce a number of important Agile principles. It's a drawing game that is really all about effective collaboration and communication."
The game starts with asking the group to self-organize into teams.
"I ask them to split up," Dusan explains. "There are no rules. It's up to them, but even this simple task immediately tells you a lot about team dynamics. Teams with good internal relationships have no problem. Some teams though will look to the boss to figure out how they should organize themselves. Seeing this kind of behavior in action provides important insights."
Next, you ask the teams to split into two functions: analysts and drawers.
"I then draw a fairly simple picture myself," Dusan says, "a triangle, a rectangle, and some text, let's say. I make it a little complicated by making some of the lines thick, some thin, and orienting the text in some strange way. Then I show my picture to the 'analysts' and they have to describe the drawing in words. The document they create will be the only thing the drawers get to see and there is no voice communication between them. Drawers have to draw the picture based on this specification, nothing else."
Learning by Doing
"Usually," Dusan says, "they will start with one analyst and there will be a time limit. 10 minutes, for example. The analyst will then create a very detailed specification that takes them 7 or 8 minutes. Unfortunately, once the drawers start working, they find out they don't have enough time to complete the picture.
"I'll stop them and show all pictures from all teams and I will show them my picture. Then we'll do a 'retrospective,' which is a Scrum ceremony, and we'll talk about what was good, what would we'd like to improve, and what we are going to change for the second round."
In Dusan's experience, teams generally decide then to send 2 or 3 analysts to describe the picture. This is common behavior, he says, but also a common mistake.
"More people describing the picture means communication problems," he says. "Who is going to draw what?"
In addition, he makes the second picture more complicated. And because the analysts will often try to divide the work between them by assigning one half of the paper to one analyst and the other to the other, Dusan makes sure that drawing crosses the middle of the page so it can't be easily split in half.
"Doing things in this way," Dusan says, "is still sort of waterfall. Analysts describe; drawers draw. Typically, this is better than the first attempt. But it still has problems so we do a retrospective again."
Iterative and Incremental
The transition to an Agile-like method comes when teams introduce an iterative and incremental approach.
"First," Dusan explains, "an analyst will go and just describe a small part of the drawing. He'll take that back to the drawers and wait a few seconds to see if they have gotten it right. Since they still can't communicate verbally, he will include a defect description the second time around. And so on."
This process ends up illustrating an important point: Doing work in an iterative manner means getting results much sooner. Dusan tracks how quickly the team gets anything on paper. At the start, as described above, this takes eight minutes. Using the incremental method, they have a result in two minutes.
At this point in the game, Dusan notes, the teams start asking for more verbal communication. "If we could talk to each other," they say, "it would go a lot better."
This illustrates another point critical to Agile and Scrum specifically: If we can talk to each other, it will go better than if we only read and write.
The Last Round
"In the last round," Dusan says, "I provide a very abstract picture: a Picasso or a picture of food that someone has already started to eat. Of course, it's impossible to draw something like that in 10 minutes.
"But then I ask the teams, 'Which picture is most like the things that your customers are going to want?' Naturally, it is this third, more complicated picture and you can only deliver it if you follow an approach that incorporates the lessons taught by the game."
People Remember Games
"When trying to teach people about Agile and Scrum," says Dusan, "playing these games make things much easier. And its fun."
"More importantly," he adds, "it makes the lessons memorable. It's something that people remember after training. If you talk to them half a year later, they won't remember what you had on your slides. But they will remember the game."
Here's some links that we found interesting this week. If you found something that you don't see here, leave a comment!
- Do You Need a Cloud Strategy? - Part II Kamesh Pemmaraju over at Sand Hill posted the second part of his series on developing a cloud strategy, the focus here falling on architectural planning. One challenge is that, as Kamesh points out, "If you ask any CIO how well understood his/her architectural and applications landscape is—including interactions and data flow between and among applications—most CIOs will say they have more work to do in that space." For this reason, the critical first step in creating a plan for the future is mapping the current "As Is" state of your information architecture. When was the last time you did that?
- Java Keeps Security Managers Up at Night According to this story over at DarkReading, by the beginning of the this year "attacks on vulnerabilities in Java had surpassed attacks on PDF flaws." Java's ubiquity and the frequent existence of multiple, older versions on desktops at home and in the enterprise make Java a particularly attractive target for the bad guys. One solution? Update internal applications to use the most current version of Java. As one expert points out, this can be costly but "the security advantages are well worth the expense." So, what's your strategy for dealing with Java-related security vulnerabilities?
- Accountability in Action with Self-Organizing Teams Dave Moran has written a series of thoughtful posts on managing accountability in a "Scrum development shop," as he calls it, and this is the most recent. Dave brings a lot of real world experience and real world examples to his discussion of the way accountability issues get addressed (or don't) in daily stand-ups and elsewhere. He concludes this post by pointing out the need for managers to reinforce the goals of Agile methodology with, well, management: "As a manager seeking to overcome the individualized focus that is programmed into so many of today’s workforce, you need to continually point out that the objective of teamwork (and Scrum) is to maximize the output of the team, and that there are advantages to shared work and collaboration. And you need to support the 'teamwork first, individual second' concept with performance expectations and reviews."
- The Future of BI in the Cloud - Chirag Mehta lays out the two main problems with running Business Intelligence and Analytics in the cloud: large databases are not designed to run natively in the cloud; and the cloud can't really support I/O intensive applications. The line that sums up the basic challenge when moving BI to the cloud is this: "[Cloud] is a horizontally elastic scale-out platform and not a vertically integrated, scale-up, system." While Chirag does point to the potential for distributed solid state drives to address the I/O issue, the bottom line was expressed by this comment: "Translation - there are no BI offerings in the cloud today unless companies want to build it themselves."
- Popping Off About Mobile App Development - Application Development Trends published this Q&A with game developer PopCap's Plamen Dragozov. It's a good overview of the challenges mobile app developers face when working with the three major mobile platforms: iOS, Android, and Windows Phone 7. While Dragozov appreciates some aspects of Android (particularly when it comes to lusing legacy code), he clearly favors iOS both for the maturity of the development tools available as well as the narrower device universe, especially when compared to Android. The question this Q&A raises is: How much will "device fragmentation" hold back mobile application development for Android?
That's just some of what we were reading this week. What did you read?