Betty Pierce speaks at the start of Women Who Code Tampa’s “All About Agile” meetup.
Click the photo to see it on full size.
Tuesday’s Women Who Code/Tampa Bay Agile meetup at AgileThought’s offices featured Julee Bellomo and Wendy Vigre introducing the concepts of agile software development to the audience of Tampa Bay’s most signed-up-for event of the evening.
Betty Pierce speaks at the start of Women Who Code Tampa’s “All About Agile” meetup.
Click the photo to see it on full size.
In the spirit of the Agile Manifesto’s “individuals and interactions over processes and tools” and “working software over comprehensive documentation” philosophies, Julee and Wendy wisely chose to demonstrate agile concepts by having attendees partake in activities rather than sit through a lecture.
Julee Bellomo presents at Women Who Code Tampa’s ‘All About Agile’ meetup.
Photo by Anitra Pavka.
We went through a number of exercises, one of which had everyone in the group stand in a place in the room that signified where they stood on the four spectrums shown below:
| On one side of the spectrum… |
…and of the other side: |
| Individuals and interactions |
Processes and tools |
| Working software |
Comprehensive documentation |
| Customer collaboration |
Contract negotiation |
| Responding to change |
Following a plan |
Julee Bellomo presents at Women Who Code Tampa’s ‘All About Agile’ meetup.
Photo by Anitra Pavka.
Those of you who are already familiar with the Agile Manifesto know that its creators favor the items on the left side over those on the right. It should be noted that they do believe that the items on the right side have value; it’s just that given each pair and the requirement to choose just one, they’d prefer the left one.
I was getting pizza during the point when we were asked to situate ourselves on the working software / comprehensive documentation spectrum, and the Hawaiian pizza was near the comprehensive documentation extreme. When asked why I favored comprehensive documentation over working software, I replied “Because documentation doesn’t have to actually compile, or even work. You can often get away with simply submitting it.”
(I will always gladly play devil’s advocate for pizza with pineapples on it.)
The big exercise of the evening is one that agile coaches love: the agile coin exercise. They love it because it demonstrates something that seems counterintuitive to a lot of people: you can get things done more quickly, efficiently, and well by:
- Doing work in smaller units and delivering that work more often (instead of doing it in larger units, delivered less often), and
- Letting the team work together to come up with their own ways to improve how the work is done.
We divided ourselves into groups of 9, and in each group, there were three roles:
- 4 workers, whose job was to do the “work”.
- 4 managers, one for each worker. Their job was to use a stopwatch to time how long it took their worker to do the “work”.
- 1 HiPPO (HiPPO is short for “Highest Paid Person in the Organization”). Their job is to use a stopwatch to time how long it took for all the workers to do all the “work”.
In the game, the “work” was to flip 20 pennies to the opposite side. Each worker would do the “work”, then pass the pennies to the next worker, who would then do the same “work”, then pass the pennies to the next worker, and so on. The “work” would be completely done once all the workers in the group had done “work” on the pennies.
We had a number of iterations of the game:
- In the first iteration, each worker had to flip all 20 pennies before passing them to the next worker. This took most groups around 70 to 90 seconds.
- In the second iteration, each worker could flip 5 pennies, pass those flipped pennies to the next worker, flip the next 5, pass them to the next worker, and so on. This took most groups around 40 to 60 seconds, even though individual times grew slightly.
- In the final iteration, the groups were free to decide how the work would be distributed. Many adopted the approach of flipping 2 pennies at a time, then passing them to the next worker. Individual times grew slightly more, but most groups’ aggregate times dropped to about 30 to 40 seconds.
By the end of the exercise, you can see how breaking tasks into smaller units and allowing the team to devise their own optimizations boosts throughput. That’s the general idea behind agile processes, no matter what they are.
If you’d like to try the agile coin exercise, there are a number of descriptions online, including this one, which was followed up with an article about some variations on the exercise.
You may also be interested in Remotely Flipped, an online version of the exercise that you can play with remote friends (it runs on Heroku, so give it a little time to start up). For those of you who’d like to know more about its implementation, check out this article on the blog of Agility Feat, the people who made it; it was developed using PubNub, Clojure, and ClojureScript.
You use lots of these in many agile methodologies.
The meetup closed with a quick overview of Scrum and Kanban, as well as Julee’s assertion that there’s no such thing as “Scrumban” (a term people use for hybrids of the two). She says that’s just “Kanban done right”.
I’m going to leave the differences between Scrum and Kanban as an exercise for the reader, but I’ll post this graphic as a way to help you get started:
