Here's what I got...
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.
Another Codemash has come and gone, which means there are more than a few recap posts out there, so I'll add mine to the pile.
The biggest take away for me this year was the sheer number of people I got to talk to, shake hands with, and bend an elbow with. In past years, that group has been basically limited to the other Quick folks that were up there or a small circle of people outside of Quick that I knew. This year, though, that number was much larger. I can easily attribute this to two things.
First, I got out and about in the community more in '08 than in past years, including a few speaking gigs around the region. I got to hang out for extended times with new colleagues from Cincy to Grand Rapids and a lot of places in between. That made for a lot of familiar faces while strolling around Kalahari.
Second, and this is probably the larger of the two: Twitter. I started in on Twitter last year after Codemash and before I headed to Mix, and it showed at this year's edition of Codemash. The number of people I could talk with in person because we'd had a few conversations on Twitter made starting those conversations much easier.
For the content itself, I was really impressed with the Pre-Compiler. This was the first year for the extra day, and I wish they'd have spread that material over the whole conference. I found myself wanting to be in three places at once on Wednesday. I ended up with a morning of Ruby with Joe and Jim, and an afternoon of Lean and Kanban with Dave Laribee.
For the full conference, I was all over the place. Some open spaces, some sessions, some hallway conversation, some recovery time that we don't need to discuss here, etc, etc. I took in Venkat's second session (skipped the Scala one), made sure I saw Mary Poppendieck, saw Laribee's DDD talk, and a few others.
Open Spaces I was really looking forward to on the heels of all the news from DevLink and what Alan Stevens did down there. I got to two, one on pair programming and one on branding yourself. I submitted one, but thanks to the snow and the room changing a couple times my turnout was five other people from Quick. We decided we could cover this at another meeting and headed back out into the sessions. So, overall I was a bit let down with the Open Spaces, but I think good content in the sessions combined with good content in the Open Spaces makes for some tough choices. Alan runs a slick Open Space, though. The ceremony is kind of cool. [Insert essence v. ceremony joke here]
My mini-speaking part in the show was when Jon Kruger, Steve Harman, and myself gave some first hand experiences with Kanban in the QSI vendor session. We ended up with a decent turnout and went 10 minutes over our allotted time taking more questions. I thought it turned out really well.
So, another Codemash behind me, and another kick in the butt to start the new year. Top of the list, clean up the blog. In the branding open space I learned that using the default theme from .txt turns people off...thank goodness I use the default blogger theme, instead. I'm going to get Graffiti installed and get a better look for it.
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.
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.
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.
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 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.
I had the pleasure of attending eRubyCon here in Columbus Aug. 15-17. This is the second year for the event organized by Joe O'Brien, and the first year I got to attend. Josh Holmes has put up great reviews of the sessions up on his blog.
Since I don't really want to repeat Josh, what were my takeaways from the event?
First, that I still need to get more involved in Ruby. This is just a cool language that allows you to do so much as a developer. The allure of RSpec aside, it just reads well and makes sense. So, a couple things came to mind as near term goals. First, I need to start with some simple scripts for everyday tasks, and write them in Ruby. Second, I'm going to try to wire up IronRuby to test some of my C# hobby code. Doubt I want to drag that one into the office just yet. Those two items should get the ball rolling for me.
Second, and I think the larger takeaway for me, was that the .Net community was almost totally missing. I noticed this in two areas, there were very few .Net developers in attendance, and most of the topics only recognized that Ruby people were converting from Java. There was a lot of Java venom being tossed around for that reason, but the opposite of love isn't necessarily hate. It's apathy. The .Netters took it on the chin in the apathy department.
What can we in the .Net space do about this? First and foremost, get out there and see what else is going on. There is a lot of software not written on a Microsoft platform, what can you learn from them? I'm not saying learn something top to bottom, but get ideas from others. In the end, language doesn't matter as we're all trying to solve people problems, and the better armed you are to solve those problems, the better off we are as a whole.
Before I lay all this at the feet of the .Net community, those outside the Microsoft environment have a little responsibility here, as well. When Michael Letterle and Josh Holmes were up to give the IronRuby, Silverlight double header the room cleared a good bit. For the same reason the .Net folks should look outside their comfort zone, maybe others should take the chance to look inside the big blue monster to see what's happening.
I'm well aware of time constraints and family and "I'm already learning seven other things!" and a reading list that's growing faster than it's shrinking. But, instead of hitting your fourth Day of .Net in a row, take in a Ruby or Python conference. Or, if you're already at a Ruby conference, stick around and see what IronRuby is bringing to the Microsoft and Ruby communities.
One of my favorite terms of late is Jim Holmes's "Specializing Generalist." Looking inside or outside the Microsoft space, as the case may be, will add to the Generalist side of the equation. And, who knows, may change what you decide to be a Specialist in.