I’m pleased to announce the Agile Chuck Wagon podcast! Each episode will be a short talk about an agile or lean software delivery topic, including techniques like design patterns that help teams stay agile. Please join me!

Topics ready for release include an introduction to the principles of Kanban, the decorator pattern, and offshore teams.

Here’s a link to the first episode: (Editor’s note: defunct)

If you have comments or suggestions for topics, please leave a comment on the Durfweb post (Editor’s note: no longer available). Future announcements about the podcast will appear there.

This weekend, I got a chance to run the Feng Shui 2 roleplaying game for my two youngest kids, ages 17 and 16. Even though I backed the Kickstarter almost a month ago, I hadn’t had time to read the rules fully, so I went off my memory of the One Shot podcast (http://peachesandhotsauce.com/podcasts/feng-shui-2-part-1).

I got many of the details of the system wrong, but the spirit was right and we all left eager for more! The Feng Shui system means to evoke the feel of an action movie, and it succeeds admirably.We had a blast describing our moves, punctuated with cheesy one liners.

This new edition also streamlines the first edition, which I’d played about five years ago. It’s hard to believe it’s only been five years – the storytelling aspect of roleplaying games has bloomed in just a few short years.

Players in Feng Shui play “chi warriors”, and their characters vie for control of sites of mystical power called feng shui sites.

My daughter Hannah chose the Spy archetype, but she ended up investigating the situation to learn more about her foes, so Hannah switched her character Scarlet to be a Private Investigator at the end of the session. Scarlet comes from the post-apocalyptic Juncture – another change from the previous edition of the game – but that didn’t factor into play much.

My son Riley was a Thief named Colm, born in medieval times. In the Feng Shui setting, characters can access a handful of stable time periods called Junctions to choose from, but his wasn’t one of them. Rather than redirect him, I ruled that Colm accidentally got sucked into the Netherworld (a nebulous location that connects Junctures) and can’t get back to his home time. Riley was really attached to the idea of Colm’s immortality, so I said that he’s been taking longevity potions for a while now and really is too old to live without them.

This initial session consisted entirely of a fight that started in an upscale department store at the mall. The pair noticed they were surrounded by creepy mannequins that were advancing on them. Both Colm and Scarlet paused in the action to upgrade their wardrobe with items off the rack, so I dubbed them the .

Colm took a few of the mooks out with some nicely choreographed strikes, and I got to describe the emotionless faces of the mannequins as their limbs were severed and they kept advancing, Toy Story style. Scarlet ran for the household appliances, and used kitchen knives and ceramic plate shards to make mincemeat of her mannequins.

When the mannequins couldn’t stop the heroes, one mook ran off and brought a featured foe named Qi-shi, a mysterious fire sorcerer in a green, fireproof Mandarin tunic. “At last, the chi warriors have arrived!”, he said. Hannah realized that her Guns skill was her primary attack, so she tried to shoot Qi-shi, but her errant shot set off the store’s security system and brought down the gates, trapping the duo in the store!

Even with his commanding entrance, his fire whip and softballs of fire, Qi-shi barely managed to set Colm’s duster ablaze in the perfume department, so Qi-shi spent most of the fight retreating. (I had the combat rules wrong, thinking that initiative reset when the location changed.)

When it was clear Qi-shi could not best the team, the sorcerer burned a hole through the store’s security fence to duck into a tea shop, just a step in front of the heroes. The front was teapots and teas for sale, the back was a suburban replica of a Japanese tea house. Not being one for subtlety, Colm bashed through some rice paper walls into what seemed like a serious Japanese business meeting with guns on the table. [Thanks to my other son Diego for the suggestion – I’m sure those suits will become important later.]

Scarlet, being sensible, pressed her advantage and drove him into the back of the store. In fact, Qi-shi kept retreating so far that he led the duo through a portal into the Neverworld that led to Qi-shi’s home Juncture, China’s Ancient past….

Colm leapt through the rice paper wall next to the portal, so I ruled that he tumbled uncontrollably through the Netherworld. However, he did so well on his recovery role – yay for getting exploding sixes twice – that we decided he burst through the ceiling of an apothecary shop in a three-point landing with the sun shining through the roof like a spotlight, just as Qi-shi came through the portal with Scarlet at his heels.

Even in this city where magic is strong, Qi-shi has proven no match for our pair of chi warriors. His billowing dust attack was made useless when Colm leapt to the rooftops and Scarlet pulled out clear-vision goggles and a breather mask and charged right on through.

We left with Qi-shi at the Fashion Police’s mercy. When we next play, it will be interesting to see what Qi-shi will say when pressed to explain why he attacked them, and why he was on the lookout for chi warriors in the first place….

Can’t wait!

An article in Business Week made me think about sports movies as a metaphor for agile methodologies.

To me, Scrum is like the 1986 film Hoosiers. Norman Dale, played by Gene Hackman, takes over a small-town basketball team. The group is undisciplined; Dale dismissed two of the original seven players because they weren’t paying attention. Dale spends a lot of time drilling basketball basics into the team, without scrimmages. Dale’s methods are unpopular and his is almost ousted as coach. Results are slow in coming, but as Dale’s team adjusts to this new style of play, they begin to show signs of success, win games, and – well, it’s a sports movie.

I like this movie because while the plot is about a basketball team, the heart of the movie is about Dale and the transformation the characters undergo together. Hackman is outstanding as Coach Dale, and manages to make a complex character come to life. Historical inaccuracies aside, Hoosiers is worth watching.

I think scrum masters would empathize with some of the challenges Dale faced. The townspeople were unsupported of Dale’s harshness with the town’s star players, who was kicked off the team in the beginning of the film for not paying attention. As a scrum master, I’ve encountered departments and managers who exhibited a similar lack of support for agile methods.

Dale’s conservative, defensive style of play was not exciting to watch, and the team struggled with it in the beginning. I think teams struggle with Scrum at first, especially with some of the technical practices that facilitate Scrum like pair programming, test-first development (TDD) and behavior-driven development (BDD). A successful Scrum team is careful to commit to workloads they know they can accomplish, knowing that as they develop a cadence, they will gather speed.

By contrast, I think Kanban is more like Moneyball. Last week’s Business Week article called Extreme Moneyball: The Houston Astros Go All In on Data Analysis is a sequel of sorts. It talks about how the Astros, like the Oakland A’s in the film, have started aggressively analyzing baseball data and exploiting new strategies to win. The article goes into good detail about how Moneyball might apply to modern business, so I won’t repeat that here.

Looking over the metrics of a Kanban team feels a lot like being Jonah Hill’s character Peter Brand, who uses that in-game statistical analysis, that Sabermetrics approach to selecting undervalued talent and signing them. I’m not alone in that thought: the book that the movie is based on, Moneyball: The Art of Winning an Unfair Game by Michael Lewis, is popular in business circles. Despite the reservations of most everyone, that A’s team of seemingly average players goes on to be wildly successful.

I’m pouring over my Kanban team’s metrics to see if I can find some commonality with features and stories that are causing my team trouble. There are some features that move through the system like clockwork. There are others that slow during development and gum up the works. For example, if I can determine that one component features prominently in those stories, I’ll know that those stories need special handling.

I think a good Kanban team lead needs a little of Coach Dale as well as a little Peter Brand in them. Heart plus smarts for the win.

In the intervening months since my last post, the project has accelerated significantly. We released the first version of the platform, and now are adding features to meet an aggressive migration schedule. I even traveled to Minsk, Belarus to meet our contractor team, to do some process training, and to discuss strategies for improving our communication and throughput.

There have been some process improvements too. I got tired of manually inputting the output of my Bash script, so I converted the script into a Ruby program. I wanted to share some of the implementation details, specifically the libraries I used. I am a Ruby novice, so I consciously chose not to use the Rally gem that’s available as a learning experience.

The application now supports two output modes: screen (the original output) and a pipe-delimited export file. My needs are very simple, so I use slop for command-line option parsing. The Ruby script also accepts an input file, instead of getting data one work item at a time.

I chose mustache as a template engine, and implemented the Strategy design pattern to switch between them based on a command-line parameter. While mustache is frequently used for HTML output, I found that it handles plain-text output just as well.

I’m using rspec for testing. I could not have gotten this application working without vcr. This application makes a lot of REST calls via rest-client and json, and I didn’t want to spam Rally every time I ran my test suite. With the vcr module in place, I captured the result of those calls once, and they are replayed when the code under test requests data. Pure gold.

While I can use the pipe-delimited export file as a data feed for Excel, the script will need some features to emulate some “processing” I was doing by hand. For example, there are still times when work items are moved backward on the Kanban board. In those cases, the Ruby script reports a negative duration in a process state.

However, the script has had to wait. I’ve been tasked with getting a Vagrant image and Docker environment for our platform created. The immediate need is so that we can on-ramp temporary developers quickly. There are other use cases, though. We could use Docker as a way to deploy our platform to a cloud provider. We could use the image for our sales folks, who could use a standalone configuration of the platform to demonstrate products to customers. I partnered with our build engineer, and I’m testing the first version now.

This is the fourth in a series of blog posts about implementing Kanban on my current project. The first installment was about establishing the flow. The second described the Rally data extract scripts I wrote. The third about my Excel spreadsheet that consumes the data. This post is about Kanban flow process violations.

I enter the number of state change violations that occurred, either by a story skipping a step or going backward across the board. I wish Rally had stronger means to discourage people from these kinds of violations! For me, simply marking a nonconforming column red is not strong enough.

During the first milestones, I took an approach of education. Now that we’ve been using the board consistently for a few months, I am stricter about process violations. I’ve pointed out there’s a strong correlation between stories that skip steps in the process and the amount of time stories stay blocked.

I want to share with you the contents of an email I wrote about these process violations. I think it gives you an example of my style, as well as being a useful analogy. Without further ado:

There are a couple of things to mention about this. I think this email was effective, because I overheard people using this analogy to explain problems. I really like to connect abstract flows like software delivery to everyday experiences.

Also, there are exceptions to the advice given above. For example, some stories of certain classes of service like defects may not follow the same workflow as a standard story. Also, in certain edge cases, it might make sense to move a story backward across the Kanban board. But, for this audience, I didn’t want to go that deep. I’ll introduce those subtle nuances later.

This is the last post in this initial run of posts. I do intend to delve deeper into certain metrics and charts I’m producing as the project progresses.