I’m sure most of us have seen the famous cartoon strip about requirements management – which highlights what the customer asked for vs. what they really wanted!
The same applies to software or product development processes. Most teams have a general idea of what their development process is or looks like. In fact, a lot of them have the processes well-documented as well (altho’ not many people might be able to find that documentation! But that is a different post.)
What process do you have?
The Kanban Method tells us to ‘start with what you have’ and improve gradually. But very often ‘what you have’ is really ‘what you think you have’ or worse ‘what you think you should have’. It is possible that you may have started to use a process that was actually what ‘you thought it should be’. However, through a series of ‘evolutionary’ steps, that process you might have started with gets ‘tweaked’ or ‘morphed’ into the process that your team actually uses.
This may happen for a variety of reasons –
1. Over-engineered Processes (yes, even Agile!): Very often, process improvement initiatives – with all good intentions – define a high-level process that everyone agrees to. However, when the process gets detailed, so teams and individual roles can actually use it to do their work, the process starts to get ‘heavy’. Overzealous process architects, enthusiastic practitioners – and the often unsuspecting team members – all participate in detailing the process definition. Document templates get defined, workflow steps put down, checklists get drawn up, even phase gates and other review ‘check-posts’ get put in. And voila! The “Process Handbook 1.0” is suddenly there.
However, as teams start to actually use that process, they start to quickly realize that the process is too rigorous or heavy to use. And that’s when the process starts to morph. Through a combination of planned and unplanned/ unforeseen/ unshared ways, the process gets tweaked to a more workable or usable process. Process steps might get skipped or dropped. Process steps may get combined. Checklists or documentation might be dropped or simplified…
However, if you were to ask any of the people involved – ‘what is your process?’, they will most likely still point to the “Process Handbook 1.0”!
2. “One-size fits all” doesn’t: Another common reason why a processes may not be what it is perceived to be is that the team starts with a specific development process and applies to all the work it does. So, in the case of a software team, they might have a perception of a development process that works for user stories, defect fixes (for critical as well as low priority defects), enhancements, etc.
The reality might be somewhat different. While low priority defects may go through a normal process, critical defects may have an extra step or two to verify and ensure that they have been truly fixed. Large work packages (exceeding a certain dollar value) may go through a different specification and approval process from smaller work packages. Emergency patients will follow a different workflow before seeing a doctor from regular patients.
Of course, some of the differences are very stark (there is no way a hospital will design the same process for emergency patients and regular ones!) – but others are not. Trying to put all the different items through a common process may not be the best way to deal with them.
3. Lack of Resources/ Time: This is perhaps one of the most common challenges in knowledge teams, especially software teams. Many software teams (believe they) lack senior enough architects or developers who might work on Design or Code Review activities in their development process.
Consequently, they may see two problems. On the one hand, they may experience a bottleneck in the Design or Code Review steps since no one is available to do that work, or more likely, one or two senior developers get completely bogged down in doing these reviews – and find themselves simply unable to cope with the load.
On the other hand, and perhaps more commonly, most work items will skip these steps altogether and management might turn a blind eye to the problem until it is too late. Only when customers escalate problems or worse, vote with their feet and just leave, management wakes up to the challenge and tries to take corrective action.
Most of us have known QA managers and testers who will lament that they simply do not get sufficient time to test. While Agile practices and automation have certainly helped development and testing steps to be done hand-in-hand, the pressure of time and (customer) delivery can lead to crucial process steps to be skipped and bad quality software or product land in the customer’s hands.
So, what should you do? Should you embark on an expensive and time-consuming work-study or yet another process improvement initiative?
Maybe not this time. This time you have Kanban to help you!
Start with What You (think you) Have!
Kanban has the great potential to give you a visual and continuous feedback on how well is your process working for you. All you need to do is get started! So,
- Start with what you (think you) have – and visualize it on the Kanban board.
- Establish WIP Limits.
- Establish Pull.
- And manage the flow
Very soon, you will start to get a sense of how your process is working for you. While it should mostly work well for you – after all you have been running your business on it so far! – you will also identify possible issues with the process. These might be bottlenecks (WIP Limit reached or exceeded), blockers, missed process steps, rework, etc.
All of these present opportunities to improve your process! Keeping your team aligned to the rest of the principles of Kanban, you will be able to –
- Use models and the scientific method to improve collaboratively, and
- Implement feedback loops – review meetings of various types – to identify, study and resolve issues, risks and so on.
Pretty soon, you will be making changes to the process that will impact your system positively over the long term. For sure, there might be missteps – but Kanban will help you correct them as well.
Can Electronic Kanban boards help?
Electronic Kanban products certainly have the advantage of helping your distributed teams collaborate more easily – and collect data and metrics automatically, instantaneously and uniformly for everyone.
SwiftKanban in particular has a couple of really cool features that will help you in this journey.
One is what we call the Adjacency Matrix – shown below. The adjacency matrix is automatically generated based on the process you have set up. The rows represent the ‘from’ process step – and the column represent the ‘to’ process step. As a card moves from one column (step) to the next, the matrix increments the count just above/ to the right of the diagonal line. If a card skips a column, the matrix increments the count in the corresponding column. The counts below the diagonal represent backward movement of cards similarly.
Sometime after you start using the board regularly (once you have sufficient card movement data), you can study the numbers on your adjacency matrix. You will get to see counts which are away from the diagonal line – which represents missed or skipped process steps in your overall workflow. Thus you will get a clear picture of which of your process steps are not really being used – and you can filter this by card-type to get greater insight into what kind of work that may be happening for.
The other tool is the Board PlayBack – or as some of our customers have called it – the ‘Kanban Movie’. The Board PlayBack is a powerful tool to give your team a rich, visual feedback on how your team and your board performed over any period of time.
You can play it back since your last release or last sprint or last week or last quarter – whatever makes sense for you.
All you need to do is sit back and watch it run – ideally on a large display so everyone can study it closely. As you watch, you will start to see some patterns emerge – and of course, it depends on how you ‘made the movie’! You might see –
- Bottlenecks build-up (WIP Limits)
- Rework (cards flowing backward)
- Resource overloading
- Period of low or high flow (with the CFD buildup)
- And many more!
Two interesting things might happen in this process –
- You may see that the process that your team is actually following is not what is on your board. You really started with what you thought you had!
- You will identify ‘clear and present’ issues with your process that your team can work on to fix.
Over a period of time, you can see how these two tools show the way your process changes and improves – and other metrics such as Flow Efficiency, Cycle Time and Blocker Analysis – show better value delivered.
And most importantly, you will gradually evolve your process that REALLY works for your team and your business!
Do you believe your Kanban board reflects the process you actually have? Or the process your team thinks it has? Either way, I hope that Kanban is already helping you evolve to the process your team should have!
Cheers!
Mahesh Singh
CO-FOUNDER, CMO/ HEAD OF CONSULTING
PS: If you liked this article, please don’t forget to share it with your friends. If you have any comments, please do share them with us. Thank you!
