Kanban: Goodbye PAIR, Hello COMIK
In the constant pursuit of kaizen, I was reviewing a couple of recent work items and similar things kept cropping up. Upon reflection, I believe these issues occurred due to the all-too-common lack of quality preparation.
“Quality” Preperation?
Now, I know what some of you (software heads) are thinking.. “oh noes! massive technical specs, requirements specs, specs of specs and specs that show how weak your kung fu is”.
Incorrect. I HATE excessive documentation - with a passion.
<rant> Seriously, for the most part, heavy spec requirements are fluffy bullcrap to normally protect a crappy software dev team from actually doing what they are supposed to do and build software that provides value to the customer. </rant>
Anyway, I don’t need to go into detail on that – we know what we need to work.. Or do we?
Where Did PAIR Let Me Down?
To recall, “PAIR” was Preparation, Action, Implementation, Review. I found there was a lot of value in this since it forced me to think about doing the “right bits” in development of deliverables (not always software-based).
However, me being a geek and wanting to get to the good stuff quickly – I often neglected the "preparation”. Or the “preparation” would simply be me re-hashing what I WANT to do, not necessarily HOW I was going to do it.
So, to be fair to PAIR (no rhyme intended) it wasn’t PAIR letting me down, I let MYSELF and PAIR down. Neither of which is good.
I also found that the Action and Implementation phases were a bit of a grey area on many tasks. Is there a real distinction between the two? Does the language convey that? Who really gives a crap?!
Think, Geek!
Having a good brainstorm on it led me to the following thoughts:
I’m Crap
I know better, we all do, but at some point we decide to be crap and either turn a blind eye or “forget”. Hey, it’s not our fault, we are human right? Well yeah, but it’s still YOUR fault!
Sometimes I Need Help
A tough one for me to admit, and to be honest it’s only a little bit of help (grin). But yeah, I need help to keep me on track. I would rather swallow pride and admit it and get better right?
Sustainable Pace?
I am sure most of you know me know that I am forever working. Sure, my GTD process is constantly improving and I am getting more done, but I need to make sure I don’t just keep throwing more on to drown myself. I need to limit my new work and work at a pace that I can keep working at.
I Wasn’t Embracing Kaizen
… as much as I needed to. “Review” is simply too “fluffy”. I often pretty much just glanced at my tasks notes rather than actually take time out to think about what went good/bad and how to learn and improve on that.
Now What?
Taking the above into account, I decided it might be a good idea to:
- Break out the “preparation” into separate, distinct phases that force me to think about the the task and requirements for it.
- Focus on adding value rather than just doing tasks. Think “80/20”. This naturally reduces the amount of work that I actually then do.
- Creating a “form”/crib sheet to work through to make sure I go through the required motions, each and every time.
- Strengthen the focus of kaizen rather than “reviewing” (which can be rather “wishy-washy”).
The result? COMIK.
COMIK? WTF?
COMIK stands for Conception, Obstacles, Model, Implement, Kaizen.
Conception
This is where we write down the idea. “Save the cheerleader”, “hug a koala bear” or perhaps “make a sandwich”. The focus is to then find the value. Of the three above, the latter two may be really nice things to do, but what value to they really add? Saving the cheerleader though? Sounds pretty important. First off, you need to save her to save the world, secondly, look at her! (nom). *cough* Anyway.
Ask yourself:
- What do you want to do?
- Why do you want to do it?
- What value will that bring?
- Are you reinventing the wheel?
The last point is important – the truth is this, a lot of good ideas have already been done, check them out. Sure, your version might be better, but understanding what is already there can either cause you to save [wasted] time reinventing or better apply it to building something better.
Obstacles
Here we are simply aiming to note down anything that you will think will get in the way of you achieving your success criteria.
For me, I find these are normally things like:
- Learning a new technology.
- Me procrastinating.
- Unclear objectives/unsure of what the hell I really want.
Again, the last one is important. How can we possibly complete a task that has no real end? However, this is a common occurrence and we should accept it. It’s perfectly normal to have a cool idea and have no idea how you are going to get there, that’s where innovation comes from.
Model
Now, we have an idea of what we are doing, why we are doing it and things that are going to try and stop us. At this stage we are looking to flesh out the task until we are ready to implement.
Some points to note here:
- Coders, do not even think of writing the modelling code in your actual project. Keep them totally separate. The modelling process should be fast and messy and should never seem “Release” configuration ;)
- Keep trying new ideas until you have a good understanding of where you actually want to take the task. This can take time. Be prepared to spend it. You will get a better result at the end, it’s an investment - speculate to accumulate.
- Isolate the individual task from everything else. Most tasks are part of a big complicated project. Keep the worries of “all the other bits” away from your modelling process – unless they have specific meaning/impact. **
- Stop when you feel like you are looking at the solution you need.
** For example, I was recently prototyping stuff with MEF. Now, I intended to apply it to Tomato Timer (TT) so I modelled based on the TT architecture, but I did not import any of the TT code (and it’s dependencies) etc. In doing so this allows you to focus on what matters.
Implement
Now, if you have done your modelling right, this process should be relatively easy. I say relatively because there are always numerous things that may come into play when playing for real money:
- Coders, production code should be a lot more readable and robust than your modelling code. Not to mention test-supported.
- Everything needs to be documented in some way. Other people need to understand the model you have designed and why.
- Legal and compliance bits and bobs that need to be addressed.
- … any other constraints that apply to your work!
Here the focus is adding the value. Note, “value” is often misinterpreted as “cheap”. Incorrect. Value is the perception relative to the worth of the “goods”. “Good value” is a low price for a top-quality product. We should embody that in our work. Just because we want to make things cheaply and quickly it should not degrade the quality.
Our modelling stage was for the quick-and-dirty work to make it easier to produce a high-value product.
Kaizen
Finally, I wanted to actually include the word “kaizen” since it really gets me in the mindset of improving. This isn’t a “review”, this is a really serious reflection period on how I can do things better. Even if you come up with just one thing, one tiny thing - you will find that you will quickly find lots of great ideas to get better at what you do. No matter how good you think you are.
Summary
I feel like this process falls a lot more in line with how I work. It is probably best suited to the more “project-y” tasks rather than standard “personal tasks” (e.g. “walk the dog”) where a simple “waiting, doing, done” process works fine. This is the benefit of kanban, it’s really flexible.
I created a simple “crib sheet” which just contains the above COMIK headings. I then print one of these and write in the boxes – yes, in good old-fashioned pen - as I progress through the task.
I find this then gives me an excellent resource with which to approach kaizen. Hand-written notes as you go will be a lot more honest and display a more accurate timeline of steps completed and problems encountered along the way (scribbled out bits are a classic indicator). Noting these roadblocks can highlight key areas for future improvement and areas for study.
Separating the “preparation”out into “conception”, “obstacles” and “model” really helps me digest the task requirements before I start burning hard time on it. I spent only 1 hour completing these steps modelling MEF items mentioned earlier. I am 100% confident that if I had prematurely got straight to coding (as I would have done) I would have spent more than 4 times that amount arriving at the same place. No doubt this would be with a headache and a large amount of crap to unpick. Not good!
As always, this process can (and should) evolve. I just wanted to share my thoughts on it with you. Thoughts?
Work hard. Play harder!
Comments
Post a Comment