Scrum Teams vs.Online Team Gaming Mechanics

In a great blog post from Coding Epiphany from 2015, cross functional Scrum Teams were compared to RPG parties, mainly focused team makeup, skill specialization versus crossing roles and forming a team as you go.  It’s awesome and nerdy.  I had a similar idea, but instead of that comparison, I wanted to compare a Scrum Team to Team Mechanics from online gaming, mainly MMORPG or maybe some team based shooters. Continue reading

Advertisements

Paint the Fence, Daniel-San: Thin Vertical Slices and the Economy of Movement

paint-fence

I’m not the first person to equate Mr. Miyagi’s method of teaching Karate in “The Karate Kid” to Agile. Jeff Gothelf equated Miyagi’s use of rote repetition and skill mastery to Agile and Lean UX. Ed Wong gave a talk to his Scrum User Group about how the learning from an expert is very similar, whether its Scrum or Karate. I’m sure there are many more out there. Continuing on that thread, I’d like to look at this in the context of story splitting, different methods of ‘painting the fence’ and how rote repetition can allow us to improve our skills and apply them in new and unfamiliar ways.

In this particular example, the fence is a section of our project. It’s clearly defined, relatively uniform, and can be painted with many different methods. Each board in the fence is a feature.

A poorly drawn blank fence.I’m not very good at art…

If we were painting via waterfall, we’d be painting horizontally, applying changes across multiple features. We would get a certain distance, and then need to come back, painting more parts of these features,

FenceHoriz1 FenceHoriz2 FenceHoriz3

Look at how much work has been done here, and nothing is even halfway complete. Some planks couldn’t be painted in the same way, since they weren’t uniform. What happens if we want to change colors? Or pull out some fence posts? We might have a vague idea of what a finished product will look like, but nothing concrete. All of these features are linked now, to finish, we really have to finish them all.  We might have saved a little energy by not having to switch levels as often (front end, back end, database, etc.), but we wasted a lot more going forward on features, then going back and touching all those features again.

On the other hand, lets take a look at the way Agile would have us do it, in thin, vertical pieces, or in our examples, plank by plank.

FenceVertical1FenceVertical2FenceVertical3

Here we see each plank completed on its own. Irregularities in size or composition no longer create issues. We can see what a completed post looks like, and extrapolate what the fence may look like once complete. If we decide to make changes, it is easier to adjust or remove completed work, while maintaining uniformity. We may move up and down more often, but we complete more often, and we reach more natural stopping points to review our work. As our muscles(skills) in this area improve, we become more efficient at this vertical movement, needing to expend less energy to do so. The smaller the slice, the less energy we have to expend to complete it.

Once we are efficient at doing so we can then apply these skills to other areas, even areas which are unknown to us. Just like when Mr. Miyagi had Daniel apply his fence painting skills to blocking, we can now look at a new project, find the features and apply all of those now-engrained skills, and flex our agile muscles. You can also begin to work on new skills, such as refactoring and communication or punching and crane kicks.

So get out there, and paint those fences!