In November, 2010, Jim Benson spoke at the Oredev conference in Malmo, Sweden on Energizing the Individual Coder and the Psychology of Kanban.Clarity Means Completion: The Psychology of Kanban - Jim Benson from Øredev on Vimeo..
How We Interact with Kanban (Video)
In November, 2010, Jim Benson spoke at the Oredev conference in Malmo, Sweden on Energizing the Individual Coder and the Psychology of Kanban.Personal Kanban: Optimizing the Individual Coder - Jim Benson from Øredev on Vimeo.
Kanban for Short Intense Projects: How We Used Kanban to Visualize Our Hiring Process Workflow and Make Our Lives Easier
This is how we used Kanban techniques to visualize our hiring workflow, empower hiring process participants, and give executives a bird's eye view on a short term project.For many companies, hiring is something that happens in spurts rather than every day, week, or even month. At this very moment, many firms may be going through a hiring process, significantly staffing up as the recession appears to ease. If you are involved in this effort and are like me, you are probably banging your head against your desk as you try to keep track of all the job candidates and what phase of the hiring process they are in, while simultaneously trying to attend to your regular job.In smaller businesses that have limited to no HR resources, this process can be a daunting endeavor. To hire for just 6 to 10 developer positions, there are often hundreds, if not more, applicants to sort through, review resumes, conduct phone and in-house interviews with, and offer jobs. Frequently, company participants have forgotten the steps and effort involved from the last time this process was enacted and therefore feel foolish as they stumble through it again. Executives and participants generally have little insight into what is going on and end up constantly emailing back and forth to check on the progress of the effort, to find out who was rejected and why, or to find out who has made it through and requires a formal offer. Interviewers must always report results back to a single point of contact (or more likely a single point of failure) who is tasked with keeping track of every candidate's application "state." Finally, anyone other than the single point of contact is usually clueless when a potential candidate calls in to check on the status of their application. After going through a full on hiring process, most people, other than seasoned HR professionals, are loathe to attempt it again.To combat the organizational nightmare that is inherent in intensive short term one-off projects, a group at our company took a stab at visualizing our hiring process workflow on a Kanban board. Our CTO made the suggestion, as our company is currently in the process of making a heavy transition to Kanban (facilitated by Jim Benson's amazing consultancy) and we all have "Kanban on the brain." My first reaction to this suggestion was, "haha, thats a good one" but after a moment of contemplation, I realized this was truly a great idea. Our team used Kanban Tool (kanbantool.com), as we have multiple remote users, but this could just as easily be done on a traditional white board, with Agile Zen, or even Google Draw.I worked with our office manager Judy, the CTO Jabe, and the developers responsible for interviewing candidates to come up with a Kanban board reflecting our ideal hiring workflow, accompanied by a document laying out roles and responsibilities associated with each column on the board. We held a 30 minute kickoff meeting to describe the process to all involved and get feedback and then we were off the races. Our company has a good amount of experience with "Agile" after working within Scrum parameters for the last 3 years so everyone understood that the Kanban board and hiring process might start off imperfectly but the goal would be to adapt and improve along the way.This is the document which was shared with all hiring process participants, containing roles and responsibilities:Interview Process DocumentHere is a screen grab of our Kanban board (click to see full size):
Kanban for Hiring
If you read the Roles and responsibility document I linked to, you'll understand the hiring process we proposed and some of the changes and suggestions for improvement that happened along the way. However, even if you didn't read the document, the beauty of using a Kanban board is its self explanatory nature. This was especially apparent when few participants had questions during the kickoff meeting. In my experience, even the best laid plans are often confusing and require multiple explanations when presented in a list or outline format. Outlines and text just aren't the most effective way for people to process or remember initiatives requiring multiple pieces to be pulled through multiple phases. Kanban made this easy.When we created the board, we used color coding for the type of job the candidate was applying for and we implemented the following columns:
Candidate Backlog (candidates who submitted resumes)
Contact Candidate (candidate placed here when it was determined he/she was qualified from resume)
Candidate Contacted (candidates who had been contacted)
Phone Interview Scheduled (candidates who had a phone interview scheduled with a developer)
Phone Interview (phone interview in progress between candidate and developer)
Schedule in-house interview (candidates who passed phone interview phase and should be scheduled for in-house interview and test)
In-House Interview scheduled (candidates who had in-house interview scheduled with product owner and developers)
In-House Interview (in house interview and code test in progress between candidate, po's and developers)
Candidate Rejected (candidates who were rejected after phone or in-house interview *this column was later changed)
Simon Interview (candidates who passed all interviews and would be called by COO for final discussion)
Candidate for Offer (candidates who were receiving formal offer letter).
Candidate Info
After some experience with the process, participants asked us to add the job type in actual text to each card (the color coding was considered a bit too confusing on its own). We also split the "Candidate Rejected" column into "Candidate Rejected - No Interview" and "Candidate Rejected - After Interview" and added a column for "Candidate On Hold."The nice thing about using something like Kanban Tool is the ability to add candidate information, such as a link to each candidates resume in Google Docs, to each Kanban card. This information is readily accessible when a card is clicked. This makes it easy for interviewers to find documents and information associated with each candidate in a timely and efficient manner.There is also an area for interviewer comments so executives and anyone else can effortlessly check in on why a candidate was rejected or passed on to the next stage:
Card Comments
Card History
Finally, Kanban Tool records each step along the way, allowing us to know exactly who made which decision, in case we ever need to trackback (although this feature, along with comments, is just a perk of the tool we used - not something completely necessary to visualize the workflow).Using Kanban to visualize this intense short term effort resulted in many positives compared to using traditional project management approaches. Here are some of the things we saw:
Rather than relying on single point of contact for all information, participants and interested observers could get just about everything they needed from the board.
Participants were empowered to make the hiring decisions themselves because they readily understood and could act on the goal. The Kanban board visually facilitates this type of understanding.
Executives, who often worry about efforts which are extremely important to the company, were able to see the plan was being followed, the rate at which the process was progressing, and the status of each candidate at a glance. This meant less questions from above, and therefore smoother day to day operations.
There was little confusion concerning the process at kickoff because of the visual nature of Kanban.
Participants felt free to make change suggestions to improve the process on the fly. Those changes could be made and disseminated quickly. This is crucial to a short term project where oftentimes if change can't be made extremely fast, it's not worth making.
We now have an easily accessible and quick to read "living" document of how this process should work for future reference.
For some reason, this process just felt much more effortless than times in the past when I've gone through something like this. I believe this is because, by empowering all participants, a "team" mentality was fostered which led to cooperation and a culture of improvement centered around a short term process (unheard of!). This was good for everyone involved and good for the company.
One thing to note: Seasoned Kanban practitioners might wonder how we dealt with WIP. We did discuss WIP limits in the beginning but as this was for a hiring process and not development, we decided not to set any and to see what happened. The WIP for this process seemed to work itself out and stay low as each phone interviewer could only obviously handle one phone interview at a time, and each in-house interview group could also only interview one candidate at a time. It may also have been the superb scheduling abilities of our office manager but it never became an issue and there were very few bottlenecks, the worst being "phone tag" moments. This is not to say we would not have immediately imposed WIP limits if flow or end results were poor.Finally, a word of warning: As with anything, someone still needs to "own" the process, watch the board, and make sure the gears keep turning. Our office manager Judy assumed this role. She made sure busy developers had the interviews scheduled on their calendar and if a responsible party let candidates stack up or sit too long in a column Judy would make sure to poke at them until they took action.So that, in a nutshell, is how we used Kanban to keep ourselves sane and productive during a massive (for us) hiring effort with no HR staff. It would be interesting to see comments on how our process could be improved!
Would You, Could You on a Plane?
As a matter of fact, yes.I boarded the first leg of my flight from Seattle to Hanoi. I had 19 hours of flying ahead of me. I also had a backlog, and no wifi. Agile Zen was not going to be useful for me. So, I opened Open Office Writer and made a quick table.I had a series of things to do, but with a few constraints. The first was that I was likely to fall asleep at some point, so I wanted to knock out the most important task first. The second was that I had a list of commitments I'd made over the week and needed to make good on them. Fortunately, I have a 17 hour battery and a 4 hour battery as backup, so I had enough juice to cover me.In no particular order I wrote down my work. I had 14 papers to read for Hanoi, so I began with those. I knew that not finishing them first would mean I'd read them when I was too tired to retain anything. Then I went to work on the feature sets for the new software projects. Finally I ended with blog posts (of which this is one).In the end, I had a full accounting of what I'd done - so I could make sure that the files and work completed in-flight made it to the appropriate people and after-action steps were taken.I want to point out again, you don't need special hardware or software, you just need to visualize your work, limit your WIP, and prioritize.
When Good Tasks Go Bad
Yesterday we were introduced to Richard, who is juggling the demands of several clients trying to keep each of them happy. His largest project entails working alone on a client's mission-critical legacy system. So in the last blog post we discussed his tasks and task types. As we discovered, outlining those task types proved invaluable to him when needing to communicate how he was working to meet his client's requests.In addition to needing to distinguish task types, Richard explained one of his biggest problems he faces is getting mired down in tasks where the solution was difficult to find. (Remember, the system he's working on is undocumented, complex and the work of several coders - so interpreting what he's reading is kind of like solving the DaVinci code every day.)Interesting work perhaps, but it can eat into your personal life when tasks routinely cause you to work late.When I asked him out of 20 tasks, how many are likely to go afield, he responded with a tentative "15."Holy moly - FIFTEEN!Needless to say, 75% of something impacts process. You can plan for 75%. 75% is not an error, it is status quo.Then I asked, "Does your client understand the miracles you are working?""Not really," was his reply.When the client doesn't understand status quo, that's also a problem.So I explained how we needed to make these issues explicit for two reasons:1. To Stop Richard from Becoming Mired Down We want to give Richard the ability to note a task as blocked, to identify the type of blockage, and to explore some options for action. (Note: the task may be blocked, right now that's miring Richard down. We want to give him permission to move around.)2. To Communicate Status on Specific Tasks We want the client know at all times, what's going on.First, we examine what the major blockage types are:
Interaction Blockages - These tasks have begun and require help from an outside party, and
Slogs - Tasks Richard has to slog through, alone.
So, just as we did with the task types in the previous post, a useful way to visualize these blockages is also with color.Task types were specific to, and travel with, the tasks. If these types of blockages are rare, then they would also be task-specific. But at 75% they are actually part of the workflow. They are likely events in Richard's regular working.His workflow would go from this:To this:Richard allows himself an overall WIP limit of 2. But "Stucks" get so stuck that the only way he can move forward is to do other work until something happens that will unstuck a stuck. (release a stuck?) This results in exceeding his WIP limit because incomplete tasks wind up littering his value stream.The new "stuck" columns are WIP-exempt and allow Richard to put active tasks in Coding, Testing, etc. while the stuck tasks are allowed - at least momentarily - to languish in the stuck areas.Admittedly, this is totally not a preferred way of working. If Richard were anything other than a lone actor, I would do everything in my power not to suggest this. I would be looking for ways to bring teamwork to bare to solve these stuck tasks. But historically Richard has had no team to rely on, and it serves little purpose to have him try to force solutions when they are slow to come by design.Again, with a full 3/4 of Richard's tasks being put into a holding state due to complexity or the need for additional input, that activity needs to be visualized before it can be dealt with. We need to see the procedural breakdown to refine our understanding of it and then, and only then, can we hopefully deal with it.Perhaps 70% of these stuck tasks deal with a few, identifiable areas of the system. Richard could then add up the time he's spent working with those specific areas and approach his client with a suggestion that he actually re-write those areas from scratch. As Richard did so, he could document his code and adhere to a coding standard that was higher than the one the original authors adhered to. This in turn would make the code more maintainable and, in the end, remove 70% of future blockages, saving his client money and Richard future heartache.I can't stress this point enough - the goal here is to visualize what is really happening, and then do something about it. Without the assistance of visualization in this and the previous post, neither Richard nor his client could gain clarity into the complexity of Richard's work load. Now that both he and his client have work types and are visualizing the tasks that are mired down, they can at long last make decisions that free Richard from long work hours and difficulties in estimation.Now Richard can better schedule his work time and attempt to achieve the coveted albeit elusive work / life balance. Not surprisingly, tomorrow's post will address this very topic.Photo by Steve Jurvetson