Thanks again to those of you who watched my Mile High Agile 2013 presentation, Design Patterns in Non-Software Contexts. This post describes the presentation and provides some materials.

Here’s a PDF print-out of the Design Patterns in Non-Software Contexts slide deck.
This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License.

I made it primarily with Haiku Deck, an iPad tool for making quite, visually appealing presentations. I finished it in Microsoft PowerPoint 2011 for Mac. The presentation primarily uses the Quicksand font, a free font by Andrew Paglinawan.

The first eight minutes or so of the presentation is going through the quote slides. While I think it was an effective way to introduce the topic, even I found the quotes to be tedious by the end. They were not present in the previous version of the deck, which was closer to 140 slides long which I’d planned to push through at a rapid pace. I’m glad I sat down and re-conceived the deck. There wasn’t enough interaction in that version, and the presentation was much better for it.

The next fifty minutes consisted of participants collectively brainstorming real-world examples of these patterns. We spend about six minutes on each pattern, enough to fill a flipchart paper:

.

Here are the examples the group came up with. I hope over the coming weeks to unpack these in separate posts. But, for the benefit of the attendees, here they are:

You’ll notice that some of the examples are stronger than others, and in fact, some may be better examples of other patterns or false examples of the pattern in question. To me, this is a weakness of the format. I did not spend a lot of time debating the examples given, in part because I wanted to encourage further participation – no one wants to feel graded – and I wanted to make sure we had enough time to cover the original five patterns I’d planned to talk about.

Overall, I think the talk went really well. I know that the comments have been generally very positive from attendees, though I don’t have full feedback yet.

Welcome to those of you who saw me present at Mile High Agile 2013 on Design Patterns in Non-Software Contexts. I made a mad dash back to the room and got the flipcharts before they were disposed of by the hotel. Over the next few days, I plan to post the slide deck and type up the examples we as a group came up with.

Thanks again to the volunteers who make that conference possible. I did registration again this year, but that’s just a small part of the work that needs to happen to make a conference of that size work. Thanks also to the attendees and other speakers, who were very encouraging.

In preparation for my talk at Mile High Agile 2013 on Friday, I asked this question on a few social networks:

“I’ve been interested in the answers I’ve gotten on other social networks, so I’ll ask this here: If you were giving a talk on design patterns to non-technical people, what one or two nuggets of wisdom would you impart?”

I wanted to accumulate some of the answers and discuss them a bit.

The first response was from Pedro:

I would say that is a framework to solving recurring problems for software engineers that allows them to define implementation solutions. Similar to self-assemble kits for custom furniture. Kits that are not a complete product, but provides enough guidance to having a custom finished and unique piece of furniture.

I like the analogy to furniture assembly kits. There are a good example of creational design patterns. The kit itself was created by an Abstract Factory, which is a pattern for creating a set of related things. The consumer, when they get the box home, acts like a Factory and assembles the piece of furniture.

Neal likened it to a toolbelt:

[A] non-technical way of looking at design patterns is a carpenter’s tool belt. It’s filled with objects that allow him to quickly accomplish common and repetitive tasks. If he needs to pound nails, he grabs the hammer, he doesn’t build one from scratch every time he needs it. From the 50,000 foot level that’s really what they’re about.

I agree with Neal in that design patterns are tools of the trade for programmers. The analogy of a tool belt breaks down in the physical world, which is why I think Mark E took exception to the hammer analogy:

Isn’t it more along the lines of using a pattern to design something that you are building? For instance, if you are framing a wall you don’t just start hammering 2x4s together. You design the wall. You space the studs, you run the wiring… You have a plan. It’s been done before millions of times. Find out the pattern for building the wall and repeat the pattern. Don’t just ignore the fact that someone has solved this problem before.

In another thread, James H cautions about finding patterns everywhere:

Doing something once does not make it a pattern. Patterns emerge over time from similar solutions being effective at solving a problem. Related: Solving a problem by using a pattern is less likely to be effective than solving your problem in a way that makes sense and then moving toward one or more patterns once you recognize the applicability.

My favorite response was from Brad M, who isn’t a programmer by trade:

“You already do this reflexively in your daily life, but by formalizing it you will be able to use it deliberately and more extensively.”

I decided to generate a cloud from the posts on this site. I like what it said about me.

Source: http://www.wordle.net/show/wrdl/6401504/neontapir.com

Team, tests, kanban, agile, game: these are all words that describe what I’m about.

I did my second demonstration of Kanban yesterday, this time with my own team. As before, I used the getKanban game to give teams hands-on experience with a sample Kanban-driven workflow.

Unlike the first time with our sister team, this time I had remote team members to consider. Having forgotten my tripod at home, I ended up making a makeshift webcam stand out of common office equipment. It generated some interest from passers-by as I experimented with it at my desk. Satisfied with the picture quality, we used meeting software so the remote team members could follow along.

Gameplay

The team took to the exercise well. In the game, players portray a software delivery team creating features that attract service subscribers.

I don’t want to give away the events in the game, so I’ll speak generally. During the first few simulated days, the team decided to take turns with the various game roles. This did lead to good cross-training, but it also led to longer turn times and some mistakes in the cumulative flow diagram.

I was keenly interested to hear my team discuss the challenges that arise during the game and to watch them learn the concepts the game is designed to promote: how Kanban helps identify bottlenecks, swarming resources to relieve bottlenecks, classes of service, WIP limits and their effects, and the like.

For example, there’s a situation where players are exposed to a fixed-date deliverable. There was a spirited debate about the return on investment of completing the feature. Some players thought the penalty for not completing the feature would be offset by concentrating on revenue-producing work. Having played this game a half-dozen times or so, I hadn’t seen any team take that option.

The game also introduces intangible class work items, ones that do not lead to direct subscriber gain. The team saw some intrinsic value in them (upgrade database, refactor problem area of code), but they agonized over when – or even whether – to start them. They kept lamenting, “if only we knew what the benefit of working these is.” I smiled as I told them, those indirect benefits are why they are intangible.

The team turned to our real product owner, one of the remote team members watching by webcam. He helped them intersperse the intangibles with standard work items. In the end, though, the team discovered the benefit of working those intangibles too late for them to make a financial impact. Nevertheless, the team did very well at generating revenue for the simulated company.

Conclusion

I recommend the game to any trainers who are introducing a Kanban flow. The company has a copy of version 2 of the game, which is what I used. I’ve played version 3, and while it does have some interesting options, version 2 is quite effective. Better yet, if you are interested, the makers of the game have made the print files available on their web site, so you can make your setup.

If you have an option, I’d recommend gathering enough people to do two teams. The competition would have accelerated game play and made it seem more like a game than an exercise. That having been said, it was effective with a single team.

My boss attended the demo. He has some experience with Kanban already, and he remarked how effective the game is at making the Kanban approach concrete. Many times, when describing Kanban, he’s found people get the idea that it’s intellectual and theoretical, whereas Kanban is the opposite. It’s a very practical tool, forming a window into whatever process you currently use. To my delight, he also became more dubious of a purely digital Kanban board as he saw the team connect with the physical game pieces. With remote team members, though, it may not be avoidable.

I consider the exercise a great success. The team went from tepid to excited to implement a Kanban board alongside the scrum tracking we already do. My boss has asked me to facilitate a session with his development management peers, and the PMO group is interested in one as well.