Transformation aimed at the flow of value from exploration to cash improves competitive advantage

We ask how long it takes to deliver a single line code change to production as a measure of how responsive the CD pipelines are in getting changes into the hands of the user as well as shortening time to repair defects or recovering from outages etc. This is a very useful measure however we should also ask how long it takes to go from exploring and identifying an opportunity to getting the cash back as well as how effective we are at identifying new opportunities. Just going from concept to cash ignores the important measure of how long on average it takes to synthesize new concepts. The time it takes to identify a new product/service opportunity and deliver it into the hands of the user is a reliable predictor of the ability to assess and respond to a changing market, new technology, competitive threat or user feedback. Maintaining a competitive advantage by never identifying new opportunities and always following competitors is a tough proposition.

This supports an adaptive business strategy for example; by allowing the business to pivot to a new customer segment earlier or head off competition by innovating and going to market first. The continuous flow of work products through the entire business from exploration to cash is what I will refer to as the business (system) being in flow. Flow is created when value is being added continuously to work products i.e. work products are always in motion throughout the process and having value added at every stage.

Short dev-test-deploy cycle times are necessary but not sufficient to guarantee a sustainable competitive advantage. There are three points of measurement; the velocity of work products moving through the process, the value added at each step and the overall value observed at the end.

The business needs to be able to determine whether value is being added throughout the process, not just at the delivery point. Only inspecting the work products or services just before delivery is ineffective and wasteful. This implies the customer is not the sole judge of value as the customer cannot judge the value of the work product while it is in progress. The customer can only judge the end product.

Non-vanity metrics such as repeat customers can be used as a lagging indicator to determine whether value is in fact consistently being added but this cannot show whether value is being added continuously throughout the process. When the consumer of the work product is a system then the change in performance of that system could be a useful indicator.

To observe the work product as it goes through the process a good starting point is to first understand the value stream map for that product or service. It highlights the value and non-value added steps and where waste might be occurring. The value stream map can be used as a guide to implementing observation points throughout the process to measure continuous addition of value objectively. Be aware of vanity metrics here as they are not helpful e.g. number of lines of code or number of user stories delivered has no relation to value.

Many companies start their enterprise agile adoption with a bottom-up, scrum teams first, approach. This is a common entry point for transformation programs and has worked for many companies. However in other cases it stalls leaving a handful of isolated scrum teams, fewer benefits than promised and a poor experience of agile. People commonly say things like “our team is agile but the company isn’t” The moment at which the transformation usually encounters a turning point is when the leadership realise that the way projects are initiated (conceived, approved, funded and resourced) is incompatible with the flow of value through the business that the delivery teams are trying to achieve. The business and delivery units remain in silos with little or no alignment or synchronisation.

They still have big project specification phases that need heavy weight business cases, ROI analysis and funding approval followed by standing up a new team, implementing tools supporting the deliver (often the same tools the previous project used) etc. In other words this up front work is really just a big batch with a high transaction cost that is not guaranteed of delivering any value. This is then given to one or more scrum teams to deliver in increments. The continuous flow of value doesn’t really exist in this situation and enterprise level benefits are going to be a fraction of what they could be. Added to this, the cost of starting up a new project every time the business has a new idea or wants to pivot is prohibitive and should be considered waste. New teams need time to become effective, they reinvent the tools and processes and it takes time. The opportunity may have passed by when the first release goes out the door.

It is far better to keep the transaction cost low by having teams already in place, already working well together and already having all the tools and processes in place to pick up any piece of work. There may need to be teams with specialist knowledge but if there is sufficient demand then this is a cost effective option otherwise existing teams can cross-train on specialist areas.

The business has a prioritized backlog of work fed by a continuous exploration activity. The business always ensures the backlog reflects the vision, mission and strategic priorities. This helps build in alignment between the business and delivery teams. The teams pull the work they can accomplish form the top of the backlog rather than the work being pushed onto them. Self-determination here is a great way to keep teams engaged. When that work is done or no longer required they pull the next highest priority from the backlog. This ensures the team is always in an effective state working on the highest priority work.

This opens the possibility to progress smaller batches of work through the system to deliver value in increments without having to be a part of a long winded, expensive initiation process. It also supports the principle of being able to identify inventory, manage WiP, manage queues, reduce non-value add time, decentralize decision making and implement economic frameworks across the business not just in the delivery department. This is how we achieve flow in the business but it requires transformation of the entire company, not just the delivery teams.

The message to companies embarking on such a transformation is to not stop at just changing a few delivery teams as this is just a local optimization. Optimize the whole system (business) by transforming the company to support the value stream including the involvement of supporting departments such as finance, HR, competitive analysis, procurement etc. Local optimization is costly, provides limited benefit and wont sustain a competitive advantage.