It is time to close this mini-series with some practical and personal ideas.
Work in Progress - Reducing lead time through queue control
If your team has a backlog than applying Little’s Law will not make much sense to the backlog itself. Little’s Law can be applied only to a queue and in queue systems something needs to come in and then come out. If something stays there and never comes out, then Little’s Law will not hold. From my experience a backlog is not a queue as work enters the backlog and can stay there indefinitely. When someone enters a queue, they are committed and slowly or quickly make their way through it and eventually leave the queue. If you are using Sprints then you can apply Little’s Law to the Sprint, under a Sprint condition team commits to the work, work enters the Sprint and then leaves the Sprint. If you have number of projects that are going through the system that are committed, then you can use Little’s Law for that as well.
Little’s Law is very significant to the LTDD as average Lead Time = Work in Progress / Throughout. This means the more things we commit to the queue the higher average lead time grows. So, it makes sense to pick a strategy where it is possible to quickly make space for new high priority work. This way customers don’t experience long lead times while software teams deliver their long-term commitments. This also tells us something very interesting. Average delivery lead time can be brought under control if your work scheduling is respected, this stabilises average delivery lead time which makes it more predictable and it enables planning and forecasting. However, for an organisation to benefit from low lead time they need to understand what work is important to them and give that work priority.
Understanding what work is important
Most of us heard the famous thought experiment: “If a tree falls in a forest and no one is around to hear it, does it make a sound?”. If your software team delivers a brand-new “feature A” that customers don’t care about (as they don’t use it right now), but you don’t fix their bugs, customers cases and answer their questions. Will they perceive your organisation to be responsive (low lead time) or not? In this scenario bugs, customers cases and questions are visible, that is what customer cares about, and this new “feature A” is that tree that has fallen in forest.
Prioritisation will depend on what is the most important thing for your company at that point in time. Maybe other customers have been told that “feature A” is coming and it is in the contract. Maybe “feature A” is amazing and most customers will upgrade to a new tier to get that feature. So, revenue might play a critical role. Maybe your company believes in quality above everything else. This means company might be OK with delivering new functionality a little bit slower while they prioritise customer cases, bugs and answering questions. There are two personas here: internal stakeholders (investors and sponsors) and external stakeholders (customers and partners). Personally, I don’t think internal and external stakeholders are at all mutually exclusive. However, your organisation needs to make a decision, which stakeholders lead time needs to be minimised, internal or external. Of course, there are more levers then that and it is more nuanced, but priority needs to be established.
I think that there is something that we can all learn from the Manufacturing here. Manufacturers have found that health and safety has correlation with productivity, in fact Lockheed Martin stated that by focusing on Health and Safety they have experienced 24% productivity increase and 20% reduction in factory costs. Think about that for a second. Does that mean we can focus on delivering quality service and be even more productive? There is no trade off? The answer seems to be yes. Now when it comes to software products some companies choose to sweep bugs under the rug, accept security risks and not deal with quality problems in their products in order to get more features out. This creates more escalations, customer cases, late night calls, bugs, endless cycle of firefighting and hardship. Everyone has to work harder just to keep the lights on. What if software companies on average constantly prioritised "Operational Quality" over new features first. Is it possible that software companies would provide get ~24% productivity increase by working this way?
Minimising customer facing lead time
More work there is in progress the higher lead time grows. Let’s say your team is working on important strategic project that will increase company revenue. You are about to commit to a deadline. Before you do it is important to remember that if you commit without leaving any space for customer requests, bugs, or small features customers will have to wait until you have completed your important strategic project. The only way for you minimise customer or contractual (security, SLA, GDPR) lead time is by factoring in some “operational slack” to address customer or contractual concerns. Also please don’t confuse your contingency with “operational slack”. Project contingency deals with project-based risk (discovering unknowns, someone needs few unexpected days off) and “operational slack” is space to deal with day to day operational concerns. This does mean that important strategic project will experienced longer lead time overall, but not at the cost of customer facing lead time.
Throughput - Ideas to reduce your cycle time
As you look to improve throughput you will want some explicit examples on what techniques can be used to actually achieve this. Here is a cheatsheet on what you can do per each factor:
Wait Time
Minimise knowledge, decisions and work dependencies. Try the following:
- Reducing handovers
- Prioritised Backlog
- Planning and Scheduling
- Prioritised Product Portfolios
- Project Management
- Removing dependencies on others
- Training and knowledge sharing
- Empowering to make local decisions and create knowledge
- Single piece flow
- Self-service
- Just-In-Time
- Minimise supporting teams WIP
Disruption Time
Minimise expedite (reactive work), rework, interruptions and mental health impact. Try the following:
- Building quality in to the development process and product
- Prioritised Backlog
- Planning and Scheduling
- Prioritised Product Portfolios
- Empowering to make local decisions and create knowledge
- Aligning work to an individual and company objectives
- Protecting team from disruptions and being proactive
Task Time
Minimise / Maximise volume of work, unknowns, complexity, experience, attitude, aptitude and risk. Try the following:
- Training and knowledge sharing
- Components re-use
- Involve subject experts
- Increase talent retention
- Aligning work to an individual and company objectives
- Maximise team’s strengths a minimise weaknesses
- Continual learning and experimentation
Please remember that you can make some quick wins in throughput, however really important breakthrough improvements will take time. These improvements will never really stop either, as you make some improvements, you will find new improvements that were hiding. Then you will make those and find new ones, and so on. It is important to stress that process improvements don’t have to be expensive to implement and most likely you don’t even need to build any additional software to make these improvements happen. From my experience, process changes mostly require a lot of thinking and communication.
I strongly recommend that you log all of the Wait, Disruption and Task Time during a Sprint so that your team can discuss this during the retrospective. Your team needs to take just one improvement away (ideally the one that will make the biggest impact) and actually make the change, that is the key. If after each retrospective team actually reviews issues and implements just one improvement, then after a while there will be no stopping this team.
Constraints - Remove constraints, reduce wait time
I am a big fan of theory of constraints and Eliyahu M. Goldratt’s work. After years of use, I have realised that theory of constraints model does not translate literally into knowledge work (this debate is outside of the scope of this blog post). However, I believe that there are few useful mental shortcuts (heuristic) that can be applied to get the benefit from theory of constraints in knowledge work.
Dependency constraint heuristic
If you would like to know if there is an operational constraint in the system just listen to the people say: “We are constantly waiting for X”, “How can X be so slow?”, “I can never get hold of X”, “They are just so busy, but we really need X”, “They keep promising that they will get it done by it never happens”, “Quality from X is never good enough”, “X is constantly down, this really slows us down”, etc. These constraints slow down the whole system as it can’t perform to the optimal levels. This means these individuals (can also be technology .e.g. build servers) are not delegating enough (usually managers), not saying no to things enough (anyone who over commits) or there are not enough of people to do the work (hands on people i.e. not managers) to remove this constraint.
Change constraint heuristic
If you don’t see enough change in the process it normally means that people who are supposed to be implementing the change are not prioritising it as a top priority (they are either over committed, can’t delegate or prioritise). This creates a big problem with opportunity cost. By this individual being a constraint to a process change you cannot enjoy the benefits of the change and you will not get to the desired destination sooner. Assuming that these individuals need to make the change, you need to implement a "change circuit breaker", which individual just prioritises the changes in over everything else for a short while (gracefully without impacting the customer lead time of course). If this does not happen then opportunity cost will just keep growing.
Conclusion
Lead time consists of number of items in the queue and your team’s throughput speed. It is possible to provide low lead time to your customers by leaving space in the queue for customer requests (Little’s Law). However, your investors and sponsors will most likely want you to also focus on getting your throughput improved so that they get more for their investment. Throughput is made up from three factors: wait, disruption and task time, by eliminating wait and disruption and minimising task time you can finally increase throughput speed. Once you start to eliminate wait, disruption and minimise wait time it might force you to go beyond your existing agile framework methods. As you focus on results and not methods you might end up questioning your long-term beliefs about what actually makes your team and your organisation productive.
No comments:
Post a Comment