What is your Cycle Time? How long does it take for your Agile Delivery Team to go from Idea to Production?

1. Ashley-Christian Hardy
Improve Your Cycle Time
What’s your
Cycle Time?

2. Hi, I’m Ashley-Christian Hardy
In Progress…
full- stackagile.com
achardy@fullstackagile.com
@achardypm
facebook.com/ fullstackagile
medium.com/@achardypm
pinterest.com/achardypm
instagram.com/achardypm
linkedin.com/in/achardypm

3. What’s your Cycle Time?
How long does it take you to get from A to B?
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?

4. What’s your Cycle Time?
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’ start by defining two concepts in Kanban; lead time and cycle time.

5. Lead Time
Ticket Created Ticket Resolved
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.

6. Lead Time
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 to be prioritized, 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.
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.

7. Lead Time
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.

8. Cycle Time
Ticket Created Ticket Resolved
Lead Time
Cycle Time
Start Work
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.
This is based on time frame (and obviously cannot be shorter than the lead time).

9. Cycle 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.

10. Process Steps
Open Backlog
Item
Requirements
in Progress
Requirements
Complete
Mockups & Design
in Progress
Mockups
Complete
Detailed
Requirements
Document in Progress
Document Complete
& Submit for Review
Estimates
Pending
Estimates Received
Pending
Development

11. Process Steps
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.
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 in companies with a process like this….

12. Process Steps
And also more enjoyable ones like this:
New
In
Progress
Closed

13. Process Steps
The first example 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.

14. 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?

15. Thank you!
Full-stackagile.com
achardy@full-stackagile.com
@achardypm
facebook.com/ fullstackagile
medium.com/@achardypm
pinterest.com/achardypm
instagram.com/achardypm
linkedin.com/in/achardypm
slideshare.net/ ashlychrstn
tumblr.com/ blog/achardypm
https://plus.google.com/ achardypm