Focus in Pandemonium OR Chaos due to other Impediments: Why do I Recommend Kanban for Startups?
Which road do I take?, The little girl asked. Where do you want to go? responded the Cheshire cat. I don’t know, Alice Answered. Then, said the cat “it doesn’t matter”
There are similar situations exists in today’s business due to increased complexity and other uncertainties. But based on my experience, It’s okay at-least if you don’t know exactly where you’re going – because things are always changing – just so long as you’re focused on the Right Things. But this is really tough for a startup precisely because everything is always changing. For any Start-up Product Development or Service Organization, It’s essential that your developers are okay with these points. In most of my training/consulting/coaching & mentoring sessions, It drives me a little bizarre every time I hear a startup developer complain that things are changing all the time.
This often plays out something like this. The Ineffective Way to Build Your Startup’s Product
Let me jot down a typical scenario, from my previous consulting experience:
*A – CEO/Founder & *B – Development Lead/Manager
A: We need to get this “Minimum Viable Product with Killer Features” out the door to start bringing in revenue if we’re going to survive. How long will it take you to build this?
B: I can do it in 2 weeks.
A: Let us go ahead and do that.
Couple of days later…
A: I just spoke with some potential investors and they said we need to develop “Features – 1 to 5” if we want to raise money. Do that instead. How long will it take you to do that?
B: Well, if I stop working on the MVP with Killer Features…
A: Yes, Let us stop working on that – raising funds is the most important thing
B: Then… I can probably do Features – 100 to 105 in 3-4 weeks.
A: Sounds Ok by me, Let us go ahead and complete that.
The next week…
A: We found an investor who is willing to pay us money if we give them Features 500 to 505. Can you work on Features 500 to 505 while you’re building Features 100 to 105?
B: Sure, but it’s going to take more time if I have to work on both of them at the same time.
A: That’s fine, do it. We need both to survive & move forward
B: *rumbling* okay…
3 weeks later:
A: I’m curious to watch the demonstration of Features 100 to 105, Let us schedule the demo this afternoon?
B: I’m not done with it yet because you asked me to spend time building Features 500 to 505 as well.
A: This is ridiculous & cannot accept at all, Why can’t you ever get anything done?
We’re now in a situation where we spent 1 month into our startup without a thing to show for it and is visible that the applied development method is “Not effective at all”.
Do you face this situation within your project/program team and look for a better Method to move forward and make things happen?
Let us Experiment Kanban:
Kanban Method practice #1, Visualize: In Kanban, We set up different types of task board based on need. Probably starting with a Simple Task board with To Do, In Progress & Done columns. In our To Do column, We put up some cards representing the tasks to be completed. In Kanban, We uses different types of Visualization, Do you want to learn/explore more, up-skill yourself, that too with the globally accepted credentials / badge, Please feel free to reach us:
Note 1: In the above mentioned scenario, If your startup needs to be able to change what’s being developed on a daily basis, then it is not advisable to assign your developer 2 week long tasks. Instead, determine your minimum time between changes & keep tasks small enough to fit within that.
Note 2: I’d recommend starting with a maximum of 5-10 tasks, or about 1-2 weeks of work. Your Kanban board should be displayed largely and prominently for everyone to see. This keeps the team focused. It doesn’t mean you might not have a billion and 3 other things you’d love to do, but that can be confusing and – at a startup where things are constantly changing – can send developers spinning. So keep those other items in a spreadsheet or notebook for yourself. And keep the Big, Visible focus on what we need to be doing Right Now.
Kanban Method practice #2: Limit Work in Progress (WIP)
Once a person starts a task, it can’t change while they’re working on it and they must complete it before beginning the next.
This is Super Important as it allows the developer to get into a cadence of continually delivering value (no more “Why can’t you ever get anything done?”).
Occasionally you’ll find it was the wrong task or defined incorrectly but our tasks are tiny (e.g., 1 day) and I promise you the value of all the correct tasks that get completed will greatly outweigh the occasional wrong task that does. Do you want to learn/explore more, up-skill yourself, that too with the globally accepted credentials/badge, Please feel free to reach us:
Note 1: It doesn’t help to build product at lightning speed if you’re never stopping to validate that you’re building the Right Thing.
You don’t actually count something as “Done” until you’ve validated whatever it is you were hoping to achieve with that feature.
Kanban Method practice #3: Manage Flow
Flow-based planning maximizes a team’s efficiency and eliminates bottlenecks. The training makes the team owns the process of how work gets done. Using measurements of queues, cycle time, and work-in-progress (WIP), the team decides how well their process is working and whether it needs adjustment.
Flow-based work includes holding a daily stand-up meeting to discuss recently-completed stories and prioritizing and assigning stories in progress. Instead of creating tasks, a team member takes the next item from the queue of stories. Do you want to learn/explore more, up-skill yourself, that too with the globally accepted credentials/badge, Please feel free to reach us:
Note 1: In the above scenario, I’d recommend defining how long you think you can afford to go between validating ideas. In an early stage startup, you probably want to keep this to 1-2 weeks at most.
Kanban Method practice #4: Make Process Policies Explicit:
Making the Process policies explicit can enable the team to create rules for how they work. This defines the Pull criteria, Prioritization & WIP Limits . The most important point is that the Policies should be developed collaboratively. Always post policies where you can see them.
If you look forward to learn more about the tools, techniques, principles etc.., Please feel free to reach us:
Let us go back to the startup scenario, My recommendation would be to:
- Find out out the riskiest assumptions in your business model.
- Find out how you can learn & validate, whether your assumption is true or not.
- Find out what the smallest possible thing is that you can build in order to validate it.
- Break this down into tasks that are <= your WIP limit & place them in your To Do column.
- Once the tasks are completed, take the time to learn whether your assumption was right or not.
- Use what you learned to determine what the most effective next thing will be for you to focus on developing
If you’re new to Kanban or want many more info or interested to learn Kanban, Please read my other listed articles on https://hangoutagile.com/blog/
My recommendation would be to up-skill & Certify yourself by learning through simulation & other tools/techniques, that too with the globally accepted Credentials/Badge, Please feel free to reach to Reshma@diaame.com