Two Talks at Indy Code Camp

I am honored to have been selected to give not one, but two talks at the upcoming Indy Code Camp on May 16th.

I'll be presenting Care About Your Craft: Adventures in the Art of Software Development, and A Little Bit of Lean With Kanban. Both these talks are a lot of fun and get good audience participation, so it should be fun.

The Indy Code Camp is typically as much code as you can crank out, and they have a max of 3 slides request for most talks. But, I'm in Track Five: Beyond Lines of Code...which is a good thing, as both talks have way more than 3 slides, and 0 lines of code.

What I'd Do Different

In my last post I mentioned a few things I'd like to do differently in my next new dev project where we utilize Kanban. I sat down with our PM, Elizabeth, and we did kind of a mini-project retrospective, and what we could do differently from the Kanban side of things to help things flow along better.

The first thing we thought would help would be to get better info on the cards, and to treat the cards as Minimal Marketable Features. Across the top of the card we'll put the feature number, name, and its time estimate. In the middle of the card, the description and any task breakout that's needed. Across the bottom we'll stick with the WIP start and end dates, and the cycle time will go between them once it's complete. The back of the card we'll put actual developer and tester times, and then once complete total that and put it on the front of the card under the estimated time.

This will accomplish a few things for us. First, on the dev side of things, it gets that task card breakout thing out of the way and allows us to track the features across the board as a single entity. Secondly, it gets more project management info clearly on the dev card, which makes it much easier for people not knee deep in the project daily to keep tabs on what's going on.

The second thing we thought should be implemented the next time around is an extension of the board, to the left. Our board for this one had a bullpen column where features were in holding waiting for the tasks to breakout. From there, they moved into the backlog, and into work in progress.

Our idea here is to break that bullpen column out into another Kanban section where discovery, design, and estimation takes place. Once that is complete the feature can wait in a "Ready for Dev" status and be pulled into the backlog column on the development Kanban board when the set trigger point is hit.

Elizabeth and I went back on forth a bit on where the bullpen board would reside. Initially I wanted to see it isolated from the dev team so they could concentrate solely on the dev tasks at hand. However, Elizabeth's persuasive abilities (strawberry cake with white icing may or may not have played a role here) led us to the conclusion that it should all be one board. This allows the developers to be aware of what's in the pipeline coming at them, lest they relax a bit too much at a critical point in the timeline. And, it allows the dev side of the board to pull from the bullpen as features are estimated and ready to go.

Finally one last thing we thought we'd employ would be different sized cards for different sized features. If we can't get all features to breakout into a similar estimate range, which is a very real possibility, then maybe get two or three ranges and denote them with different sized cards on the board. This would allow for different cycles to be tracked based on feature size, and a quick look at the board would tell you what type of features are moving through the system at any given time.

I think these changes to our approach will help the next new dev project where we employ Kanban. We used it successfully before, but I think this will help get more features into done with less friction for the whole team. Which means cards will get put in the envelope above this lovely lady's picture in a shorter cycle. (Whiteboard drawing courtesy of Dan Shultz.)

Kanban Lessons Learned

After seeing success with Kanban in a production support environment (part 1, part 2), we decided to give it a try in a new development situation. This project was a mix of new development and working with an inherited code base to implement some existing features differently.

Because of this situation, we ended up with a mixed bag of features. At the onset, we decided to break these features out into tasks, and we would track both across our Kanban board, as shown here with a snapshot of our Work In Progress section.

Features were broken into tasks and grouped together in the backlog. Once a feature went into WIP, it's tasks moved below into the Task Breakout section and were worked there. Once all tasks were completed, they were once again compiled back into a feature and went into test as a whole.

What we tried to accomplish here was to keep the concept of a MMF while still breaking the work into smaller, more manageable units. What ended up happening was that features themselves became secondary to almost full task development, however we were tracking features through the system for our cycle time. Early, heavy task features that focused more on the business model skewed the cycle time higher, and later UI tweaking features sent it lower. As such, our cycle time diminished quickly as the deadline drew near...a good thing, but I don't think it was totally attributable to the team's momentum.

I think we failed here in poor estimation of what lie in front of us when we started. A good bit of this is the situation we were in at the onset where we were under pressure to start getting things moving right away, and we didn't give much credence to estimating later features very well. That wasn't really a Kanban issue, and we should have known better. The excuse is we had very little time to ramp up on the discovery side of things when we got the project, but it would just be an excuse...we should have known better.

One final area where we had some issues was in reporting where exactly we stood in features completed. We were fairly visible on this project, and had a lot of interest in our success by the due date. (OK, what project doesn't?) While you could look at the board and see what was being worked at any given point, due to the lack of good feature estimation up front, it was hard to see where we were in the big picture. In the latter half of the project we stole ourselves a project manager, and she did a bang up job of getting that information worked out, but she did struggle in figuring it out. Again, I think she had trouble due to the lack of good estimation up front.

It wasn't all pain and suffering as we moved our cards across the board.

One good thing we got out of the board was it was easily changed to fit our constantly changing team size and make up. We started out as three developers, and ended as four developers - two different than the original three, one PM, and one QA person. Being able to walk up to the board and change the queue limits on feature WIP, task development, and features in test made things flow quite smoothly as the project moved along. It did a good job of identifying a few roadblocks and getting them out of the way, as well.

As noted earlier, our cycle time did drop as we neared the due date. Part of that was due to the smaller features coming through later, but there was a good bit of momentum on the dev team, too. Morale stayed fairly good as we kept moving things into the done envelope at the right side of the board.

I still think we were successful with Kanban in this situation, but clearly I think we need some refinements around how we did it on this project. I'll save those ideas for my next post.

"Houston here. We're looking for somebody to blame for your problem, 13."

Fix the Problem, Not the Blame
It doesn't really matter whether the bug is your fault or someone else's—it is still your problem, and it still needs to be fixed.

--The Pragmatic Programmer

I highly doubt that was the response to Jim Lovell after the line, "Houston, we have a problem." However, in our world of software development it still seems to be the first reaction to any issue that comes up.

I know in projects past, I've been a huge offender of looking for, "It's not MY fault," rather than fixing the problem at hand. Todd even nicknamed me Blameosaurus on one project because I got so good at looking for the blame. So, I'm not exempt from my own post here.

I've been a consultant for one company or another for over ten years now, and we're constantly thrown into burning buildings to get something working. There are a plethora of issues on day 1, and all too often those of us on the team spend too much time bitching about the issues and not enough time rolling up our sleeves to get things squared away. So, day 2 rolls around and we're in the same boat, and the same problem still exists.

That said, sometimes there is a right time to track somebody down that created a problem. Don't do it as a way to shame them, but rather for more clarification. Who knows what the situation as like at the time they made the error, and maybe it's a good time to help somebody learn something new.

I feel I'm still an offender of whipping out the blame thrower a bit too often, but I'm making a conscious effort to quit and move on with the solution.

Some April Kanban Talks

I'm happy to have been selected to two conferences in the region to share an hour or so of Kanban, and my experiences with it.

The first will be at Central Ohio Day of .Net on April 18th in Wilmington. This is a great little conference that combines the forces of the dev communities of Dayton, Cincy, and Columbus for a day of geeking out. In addition to the great sessions they have lined up, there will also be Open Spaces. If you've got time on a Saturday in the spring, this is a great gathering at a great price...free!

The following Saturday, April 25th, I'm going to trek north and present at the Kalamazoo X conference. This is the first year for this conference, and it looks really interesting. It's focus is on the non-tech side of development, so there will be lots of dev process, design, and user interaction type talks. All the stuff we need to know without opening up our favorite IDE. As an added bonus, this place is in Kalamazoo for a required stop.

That will keep a couple Saturday afternoons busy in April for me. Now, if a certain local hockey team can keep the Saturday evenings busy...

COALMG Kanban Talk Follow-up

I would like to thank everybody that attended my Kanban talk at COALMG on March 5th. There were some great questions, a good discussion, and judging by the tweets on Twitter afterward, it got some wheels turning. I'm glad the talk got some of you thinking about things you can look into.

As promised to Jeff, here are my slides: A Little Lean With Kanban.

The disclaimer on the slides: They meant to support the presentation (I have totally bought into the Presentation Zen approach to presenting), so on their own they don't say much. However, my notes to each slide are there, and that should provide some value. Also, even though I used pptPlex for the presentation, if you don't have that they'll still work fine in Power Point.

Also, I love feedback. That was the first time I gave that presentation in that form, and welcome any suggestions you may have. I already got a few from Comrade, James, and Amanda over post-talk beers that will be folded in to the next iteration.

And all you guys named Jeff that bailed on the post-talk beers...for shame!

A Weekend With pptPlex

Some time last fall I believe, Jeff introduced me to pptPlex from Microsoft Office Labs. It does some pretty neat tricks with your slide deck. To me it appeared to be Deep Zoom for Power Point. (And let's be honest, anything to spice up Power Point is a good thing.)

So, I've got a new presentation to put together, and thought now would be a good time to give pptPlex a try. I wasn't disappointed, it does make moving through your presentation more fun. To get it to work there are a couple special slide types it uses, and a different way to launch the deck, and that's about it.

The first special slide is the section divider slide. It has a title and some grayed out text on it. You drag it into the deck at the point you want a section to start, add the title, and done. That section will exist until pptPlex finds another section divider slide. This groups your slides by however you'd like, and applies the title from the section divider slide to that group.

The second special slide type is a canvas slide. This slide ends up being the canvas for the whole presentation. There are a few pre-made ones you can use, and also two custom options. Basically, the layout you choose determines how your slide groups are arranged on the canvas. I ended up using the advanced custom option, which wasn't too hard to lay out. Lots of typical dragging and dropping to get the layout like you want it. Took maybe 10 minutes to get my six sections all set up like I want.

Both the section and canvas slides appear on the new pptPlex portion of the ribbon. Also on that menu are the new options for launch that will start your presentation up in pptPlex mode rather than in traditional Power Point mode. The first of "From Overview" is the one that will start your presentation from the canvas, and is the one I think most people are going to use.

Now for the downsides I ran into...

First issue I came up with was that it didn't work with my presenter mouse. I've got the Microsoft Wireless Notebook Presenter Mouse 8000, and no dice with it doing anything in presenter mode. A little searching on the web turns up that pptPlex doesn't yet support that mouse. HOWEVER! It will support use with a Wii remote and an xbox controller. +1 to each for cool factor, but I'm trying to be practical here and still give a presentation.

My solution to this ended up being mapping the two side buttons on my mouse to the left and right keys on the keyboard. It's not the ideal solution, but it will cover 90% of what I'll need to handle during a presentation. There will be a couple of gotchas with this, but it should get the job done.

The second issue I came across was that once you've published your slides to the pptPlex output, you lose all your animations. I don't use animations a lot, but a couple places they would have come in very handy for effect. However, the pptPlex FAQ lays out that they just didn't have time to get that in for this release. (Yo, MS, add one more guy to the team and task him with mouse integration and animation!)

Overall, I'm digging the product. I think it'll help with a lot of my presentations, and I'll probably refactor any of my old ones to use it. The cool factor it brings makes the above two hurdles tolerable.

Besides, a sensor bar and a bluetooth card form my laptop will have me running a Wii controller in no time!