Improve your Work Process — What’s your Cycle Time?
Improve your work Process
What is your Cycle Time?
I have seen many different ways that people manage their work flow 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, but I think the most important question is how many steps are there?
There are two very extreme ends to this spectrum, 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 or legacy 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.
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.
If you think of it in software development terms; and lets take a bug for example. When a bug is identified, you would probably create a bug item (in JIRA, TFS, Ralley or whatever tracking software you use) to be prioritised, if its a production issue its probably high or critical. The lead time will start when the bug is created (the request) and will end when the bug fix validated and ready to be deployed. Remember that the time should end when the bug is ready to be deployed, and not when it is actually deployed. The reason for this is that you will have delivered the fix or new feature, but as I mentioned the decision to deploy should be that of the business or the requester. There may be circumstances that mean that the fix should not go live at that time; for example if the fix is for an on-line sports betting company, its probably not the best idea to release during the World Cup final, or if the fix is for a trading platform, releasing the fix during trading hours may give someone an unfair advantage.
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, but you may have a lead time of 10 days due to all the other things that might happen along the way (internal communication, reporting, QA validation, merging, code review, automated testing, deployment process, sign off process….).
The lead time in organizations 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.
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 making money. Its the Cycle Time a development team can use to improve their delivery, but often there maybe a time to wait before the issue actually hits the development team — so time here could also be reduced.
Process 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 (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 its 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 I moved to the above approach 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 started also reaped the benefits by seeing their ideas go from conception to production bound a lot quicker and of a higher 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?
This post was originally posted on: theproducthub.io
https://www.theproducthub.io/2019/10/20/improve-your-work-process-whats-your-cycle-time/
Please check my site to get the latest articles first!
About the Author
Ashley-Christian Hardy
theproducthub.io
Product Leader. Over 10 years in product development; with experience in product management, UX & UI, product design, product & delivery methodologies and product leadership. A strong advocate in innovation, experimentation and building great products with the use of qualitative and quantitative research, putting an emphasis on a customer centric design and approach.
Website: www.theproducthub.io
Twitter: www.twitter.com/achardypm
Facebook: https://www.facebook.com/theproducthubio
LinkedIn: mt.linkedin.com/in/achardypm
Medium: medium.com/@achardypm
Instagram: https://www.instagram.com/theproducthub.io/
Pinterest: pinterest.com/achardypm
SlideShare: slideshare.net/ashlychrstn
