Speaking at Lean Software and Systems Conference

I am more than honored to have been selected to speak at the Lean Software and Systems Conference in Atlanta in April. I’ll be presenting an experience report on my projects using Kanban over the last year and a half.

The presentation will obviously focus on my experiences, so very little theory or how-to about Kanban here. Given the subject of the conference in general, there probably isn’t a big need for a how-to on Lean software, anyway. So I’ll share successes and failures, and the collaboration with other members of the team to improve the process for different projects.

If you’re in the greater Atlanta area April 21-23, try to get to this conference. Many of the innovators in Lean Software will be speaking and there will be a significant number of people applying this in the real world. I’m almost as excited to be attending it as I am to be speaking at it!

Beware Your Buffering

In a twitter discussion that was centering around some Kanban joy, the point of buffering came up. I offered a bit of twitter-esque advice, meaning it was short, could be interpreted as terse, and lacked the detail it needed. As any good friend would do, Jim called me out for my 140 character bit of guidance.

So, in more than 140 characters…

Be careful with your queues on your Kanban board. (I say queue here, because a buffer is just the queue for the next step.) By definition, any queue is waste. It’s a step in the process where something is waiting, therefore value isn’t being provided to your customer.

Can queues be used effectively? Yes. Quite effectively, but you have to stay on top of them. In reality, there has to be some queuing going on to give a pull system something to pull. In practice, those queues need to be as small as you can keep them to keep things flowing.

My tweet that started this mess was that I’d been burned by buffers on more than one occasion. Here’s one nasty one where the queue wasn’t a help, it was hiding the real problem.

We had a project where our developers far outnumbered our testers. This isn’t an unheard of scenario in the world of software development, but we handled it badly on our Kanban board. We ended up with not one, but two buffers between the dev team and the QA folks. The true, root cause problem was we had a resource problem because we needed more testers. Instead, we masked it with some queuing.

The biggest problem was that we lost our short feedback loop from development to demo. Early in the process, we’d complete a feature and it would demo within a day or two. As the project progressed and the developers’ momentum took off, the testing team was backed up and the feedback loop grew. Bugs were sitting open longer, code complete features waited to be tested, and the churn began.

Our solution was to swarm the test queue to get it lowered. Having a dev or two help get some testing done got our backed up test queue fixed, but it put devs in a testing role which I’m not a big fan of doing. (Devs are notorious for making sure something works rather than looking for ways something could break.) Also, this solution was very temporary as the queue naturally filled back up once the dev team was back in high gear. The actual solution: add a testing resource. Our full queues told us that, but we didn’t listen too closely for a while.

In the end, some buffers and queues are inevitable in many situations. However, make sure to do the following:

1. Make them as small as you can, maybe half the size of the queue limit of the step that the buffer is feeding. Adjust as necessary, but don’t keep increasing it as it fills up.
2. If you need to increase its size, ask why a couple times to clear it up. If the answer is, “Because we need more room!” then look at the next step and see why it’s backing up your process.

So, back to what started all this…buffers can bite you in the butt as they tend to mask the issue rather than solving it. Make sure your buffers aren’t hiding a bigger problem.

Kanban At XPUserGroup – July 29

This is a bit short notice, but I just found out about it last week. (Thanks to Kevin tweeting about it. :) ) But, I’ll be presenting my “A Little Bit of Lean with Kanban” this coming Wednesday for the XPUserGroup here in Columbus. The meeting will be at OCLC at 11:30, I’ll begin my presentation at noon. (Directions and room info at OCLC.)

I didn’t plan on doing much speaking before leaving for vacation on August 1, but here’s one more session on Kanban. We really can’t spread the word enough about Kanban, so why not give one more a few days before I head south?

I’m also giving a short presentation on the 7 principles of Lean Software development next week…but you have to be an employee of Quick Solutions to see that one. (Get hired by Tuesday to see it! :) )

CodeStock Recap and Kanban Talk Slides

I had a great time at Codestock this past weekend. I didn’t get to many sessions, but I did go to a number of open space sessions (have some work to do on my blog) and the normal “hallway” sessions that never disappoint.

My talk on Lean and Kanban went really well. There were only a couple seats left in the smallish room we had, but that lead to a much more interactive discussion. The slides are available to download, with some notes in the deck.

To answer a couple more questions from the group, here are a couple of the resources I mentioned in the talk:

• Core Ladas blog: http://leansoftwareengineering.com/
• Implementing Lean Software Development by Mary and Tom Poppendieck

Coming soon will be Agile Zen. I’ve taken a peek at the beta, and it’ll be quite a tool in helping people and teams do lean development. Sign up for their mailing list to get notified when it comes out.

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.

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!

Speaking at COALMG

I have been selected to present on Kanban to the Central Ohio ALM Group on March 5th. This will kick off my 2009 speaking tour, and I get to open it with a new talk on Kanban. I'm really looking forward to this talk because I've seen the advantages of Kanban first hand.

So, if you want to learn a little about Kanban, what it is, and how to get started with it...or if you just want to heckle me...drop by the Microsoft offices on Polaris Pkwy March 5th.

Kanban-o-rama - Part 2

In part one I laid out the why and the how of our Kanban set up. In this part, a nice cell phone picture and some what it's done for us.

The Board

Here's our "borrowed" whiteboard. In stroke of genius from Mark, we drew the dividing lines with a Sharpie which makes them semi-permanent. One post-it note equals one work item, so for every post-it on the board there's a corresponding entry in our SharePoint work item list. Yellow post-its are regular priority items, purple tickets are high priority. (The stray colors are just strays...green == yellow, and fucia == purple.)

To the right of the names is where we start working with the tickets in the backlog column. It's sized to fit three tickets to help enforce our max three rule for that slot. Below that is the Blocked area, which isn't sized to scale of their respective max allowable tickets.

Moving to the right across the board is each developer's Work in Progress slot. Again, sized to enforce the max allowable items. This is where carried over our dotting strategy from the previous set-up: Yellow is domain understood, green is design understood and in dev, red is dev complete, blue is in production. (Though following this photo we have decided that blue will mean passed testing in staging, ready for production.)

At the bottom of the Work in Progress column is our Emergency slot. This is where our "drop everything" items end up. To our surprise, it hasn't been utilized as much as we thought it would.

To the right of the Work in Progress slot are our Ready for Test and Tested slots. These are the first real community slots on the board, and the honor system is in place for getting things tested. So far, so good on that.

The far right of the board is open space for notes, tracking what's gone into production, and blimp drawings.

What its done for us

So far the big win for us has been gaining focus on one item at a time. We still have some growing to do in this area, as the inevitable "How long would it take to do X?" questions come up daily, and you find yourself looking at code you weren't aware existed when you started the day. So, we're trying to push harder to keep the distractions down, and keep the focus switching lessened.

Another thing that moving to this system has allowed is that it's much eaiser to report up the chain of command what each person is working on. It's much easier to manage expectations on when something will be finished and when another item will be started. Also, when the, "Item Q has to be done right away," request comes in I can say which items are being worked and ask which one should be stopped to pick up Item Q. Now that I can better articulate what each guy is doing, these requests are more often becoming, "Oh, this can wait until one of those is finished."

We've been using this for about four weeks now, and have had a few discussions around it. The early returns from the dev team is that they like it quite a bit. The numbers reflect that it's working, too, as we've closed more tickets over the last four weeks than we had in any four week period since mid-July.

Kanban-o-rama - Part 1

Our current project is much more of the maintenance variety than of the new development type. Originally we tried to apply our standard scrum-ish approach to it - feature cards, load sheets, 2 week iterations, etc. However, it became clear that working maintenance tickets wasn't going to fit that model. Our load sheets meant nothing after a while because they were just getting overloaded with work items that were un-estimated, but needed assigned to get worked. It also became increasingly difficult to track the status of an item. Due to the lack of information about some tickets, any developer would show multiple tickets being "worked" at any given time. Keeping track of that on prod push day wasn't very easy, either.

Enter the Kanban idea.

The idea was brought up after a Friday retrospective by fellow QSI guy, Alexei. Comrade, myself, and our PM had about an hour discussion around the idea, and the following Monday put it into action. I did some information gathering over the weekend, hit up a couple other Quick guys for some more information, "borrowed" a white board from an office in the building, and away we went.

Our setup

Our setup is pretty simple. You can have 1 item as "Work in Progress" at any one time. You can't work more than one item at a time. Focus on that item until complete, then pull an item from your backlog.

We set up the backlog not as a community backlog, but each developer has his own backlog. I know this isn't ideal, but it gives us one extra layer of control on the flow of which tickets go to which guy to fix them. (The system we're working on is pretty broad, and though I'd love to practice collective ownership of the whole thing across the whole team, that's just not practical.) The backlog can max out at 3 items, and the item you choose is your choice, unless there's a high priority item in your backlog. (Denoted by a purple ticket rather than the normal yellow.)

If your item becomes blocked, we have two blocked areas available to move the ticket into. The first is "Blocked, need more information." Tickets moved here are assigned back to the PM who will follow up with the user to get the information needed to complete the ticket.

The second blocked area is "Blocked, Internal" which is a horrible name...the creative juices just weren't flowing that day. Typically tickets get moved here when they're dependant on another work item to be completed prior to them being worked.

Our max tickets allowable in the Need More Info slot is 8, and the internal is 2. If we go over those counts, we stop and figure out what we need to do to move those tickets along.

Once a ticket is no longer blocked, it goes back into the developer's backlog that originally had it. If there's not room in the backlog when it comes unblocked, it will wait in the "Ready for Dev" queue that is maintained in SharePoint. All the tickets are tracked through SharePoint as well as on the board, but prior to hitting the board they're managed only in SharePoint.

Once a work item is completed, it moves to "Ready to Test." The rules of testing are you test a ticket you didn't complete, as we don't have dedicated QA resources available. When you complete an item and there's one available for test, take the time to test it before starting your next item. So far, using the honor system has worked well, though we do still have some testing to catch up on before we do our weekly prod push. (We've picked Tuesday, so there's some testing going on Monday afternoon.)

Following testing, the ticket moves to "Tested." There it sits until it's rolled out to production.

That's the standard flow we've been using, but we did open up an "Emergency" option. So far, we've only had three emergency items drop into that slot. When that happens, the developer chosen to work it stops the item he's currently working and switches gears to the emergency until it's complete.

I'll end part 1 here. Up next I'll show off some photos of our board and add some more details as to how its been working out for us.