Improve your work process
I have seen many different ways that people manage their work flow and product delivery process.
By this I mean how you get something from idea to delivered in production, and the steps in between. How do you track these steps and how does everyone keep in line. I think the most important question is how many steps are there?
There are two very extreme ends to this spectrum of product delivery. Teams that do the bare minimum (Kanban end of the spectrum), where they might have a ‘to do’, ‘in progress’ and ‘complete’ stages. The other end of the spectrum, the more waterfall approach is to have many little documented, process driven steps. With the later I find that these are usually enterprise companies that have scaled badly or have a lot of development teams they struggle to keep inline.
Let me start by defining two concepts in Kanban; lead time and cycle time.
Determine Lead Time
This is the time it takes your feature to get into production from the initial idea being added to a backlog to being ready for deployment. Its important to note that when a user story or new development is ready to be deployed — the go ahead should always be a business decision.
The Lean & Kanban blog defines it as:
” Lead time clock starts when the request is made and ends at delivery. Cycle time clock starts when work begins on the request and ends when the item is ready for delivery. Cycle time is a more mechanical measure of process capability. Lead time is what the customer sees.”
I think this is a very important measure; think about it. If you are a Product Manager, Product Owner or some kind of stakeholder, when you make a request how long is it before you see it in production being used?
NOTE: The scale for new features and bugs is probably going to be different, depending on your process. A new feature may involve, design, UX, architecture meetings, prototyping; where as a bug is usually find the issue, solve the issue, so there is probably going to be a gap in lead time so I would keep these separate.
Issues
If you think of it in software development terms; and let’s take a bug for example. When a bug is identified, you would probably create a bug item to be prioritised, if its a production issue it’s probably high or critical. The lead time will start when the bug is created and will end when the bug fix validated and ready to be deployed. The time should end when the bug is ready to be deployed. The reason for this is that you will have delivered the fix or new feature, but the decision to deploy should be that of the the requester. There may be circumstances that mean that the fix should not go live at that time. An example if the fix is for an on-line sports betting company, it’s probably not the best idea to release during the World Cup final. If the fix is for a trading platform, releasing the fix during trading hours may give someone an unfair advantage.
Agreements
So this is the key; lead time is duration and not effort/capacity, and can actually be a good way to identify bottle necks or get the true efficiency of your team.
You might only have to work 30 minutes to fix the bug. You may also have a lead time of 10 days due to all the other things that might happen along the way.
The lead time in organisations can often be referred to as your SLA (Service Level Agreement) or Resolution Time when dealing with issues. This ensures that your lead time is not indefinite and have to be resolved within a certain amount of time.
Understand Cycle Time
If you are a development team manager, scrum master, IT project manager; then this figure might be more interesting to you. The cycle time for example; is the time from when you start working on the bug to when the bug fix ready to be deployed. Again this is based on time frame (and obviously cannot be shorter than the lead time).
From a business point of view, the lead time is obviously the most important. How long does it take from when you have a great money making idea to when this idea actually starts generating revenue?
It’s the Cycle Time a development team can use to improve their delivery. Often there maybe a time to wait before the issue actually hits the development team — so time here could also be reduced.
Varying Steps
So as I was saying, how many steps does it take for you to get your features into production. For now I am just going to focus on the cycle time. The lead time is a whole other beast I will tackle in another post. It is important to mention though, any process improvement should happen end-to-end, fixing one small part of it might not have the desired effect you want.
I have worked i companies both ends of the scale, one that looked like this for their product delivery (yes they are actually user story statuses):
And more enjoyably ones like this:
The first is very heavily documented, strict and restricts innovation and collaboration. It often includes very painful hand overs, politics, friction and reduces speed greatly. The second promotes collaboration, discussion, transparency — but most importantly a shared knowledge and understanding of what “Done” means. In scrum it’s called the definition of done. This is like a check-list of things to do in order to get a development from ‘In progress’ to ‘done’. If the definition of done is discussed and agreed upon as a team, then there should be no problems here. This is also something that can grow and adapt as you, your product and process to too. The definition of done usually includes such tasks as design, testing, deployment, merging etc.
Summary
When moving to the above approach for product delivery with little steps, I saw an increase in quality, team moral and collaboration. The flow was simple and everyone did what it took to get a feature from ‘done’ to ‘complete’. It was a pleasure to work with such simplicity, and remove the grey areas. The user story was either complete or it wasn’t. Team members didn’t need to keep referring to documentation or process flows to understand what to do next. Any ambiguity, politics and inefficiencies were removed. Not only did this benefit the team becoming more efficient and motivated, but the business also reaped the benefits by seeing their ideas go from conception to revenues quicker with improved quality.
Team empowerment and process simplification for me are the future of software development, and where possible; these legacy heavily dependent processes need to be removed.
Just to put things into perspective. A lot of the big technology companies can now have a lead time of 1 hour or less.
Can you have an idea or find a bug and have it in production whilst your boss is on his lunch break?
Social Media
Please check me out on social media:
