{"id":21302,"date":"2019-10-22T11:20:36","date_gmt":"2019-10-22T10:20:36","guid":{"rendered":"https:\/\/www.devopsonline.co.uk\/?p=21302"},"modified":"2019-10-22T11:21:05","modified_gmt":"2019-10-22T10:21:05","slug":"value-stream-mapping-why-it-matters-and-what-best-practice-looks-like","status":"publish","type":"post","link":"https:\/\/devopsnews.online\/value-stream-mapping-why-it-matters-and-what-best-practice-looks-like\/","title":{"rendered":"Value Stream Mapping \u2013 why it matters and what best practice looks like"},"content":{"rendered":"

Value stream mapping is fast emerging as a successful technique for maximising efficiency\u00a0 and reducing the waste within the modern software development lifecycle, particularly in Agile and DevOps environments.\u00a0 Here we will take a look at what value streams and value stream mapping are, why they matter, and suggests some steps towards successful implementation.<\/p>\n

Most organisations want to move towards faster and more agile development and to deliver continuous value internally and externally. Identifying what activities will deliver the best value and reduce wasted effort plays a major part in achieving those goals. It matters because many teams spend a lot of time on actions that do not have the same beneficial impact as others.<\/p>\n

I\u2019ve personally seen organisations waste 15-20% of development effort. Some might be more. Some might be less. Some may have no idea because this waste is hard to quantify.<\/p>\n

As part of DevOps, Agile, and the evolution of the modern software development lifecycle (SDLC), this is why value streams \u2014 and value stream mapping \u2014 are hot topics right now. It is well known that DevOps is a complex process that requires structure, visibility, and orchestration if everything is to flow smoothly and continuously.<\/p>\n

Based on the SAFe Agile Framework, value streams have been defined as representing “the series of steps that an organisation uses to build solutions that provide a continuous flow of value to a customer”. So far, so good, but mapping those value streams in relation to each other and their impact is hard, but important work.<\/p>\n

Understanding value stream mapping<\/h4>\n

Value streams vary. Some are more efficient than others. Some are manual while others are automated. Some are necessary and others are hard to justify against business outcomes. So, identifying the ‘right’ value streams, (those that address customer pain points, for example), planning around them, and building continued value around them via well-managed release trains, is going to contribute towards a successful, on-time, and relevant project.<\/p>\n

However, that depends on building value stream maps (VSMs) to ensure scaled and synchronised product development builds on top of each stream with high velocity and quality. The potential benefits are reduced lead time, faster releases, and continuous improvement of software release trains, ensuring that the identified value streams meet the delivery date expected by the customer.<\/p>\n

The theory is fairly straightforward, but what does it look like in practice? I agree with Mike Jones, delivery lead and scrum master at AGL Energy, who has previously cited the importance of the conversations that are held when VSMs are being created. These conversations promote useful interaction among all stakeholders. This should eventually lead to building the right software and reducing risk and waste from the overall SDLC process. These conversations usually \u2014 and should \u2014 involve conversations from all the feature teams and their managers and typically take the form of a workshop.<\/p>\n

After this initial session, a visualisation of the entire software development is usually created, from A to Z. This will help expose areas of waste or inaccuracies in critical activities. It also helps identify delays, constraints, and duplication of efforts. It also provides visibility into the entire tool stack used in the process, which can benefit the entire team.<\/p>\n

A great VSM workshop\u2019s output should be able to show the team everything in a very clear way, such as backlog sizes per team, manual versus automated activities and their dependencies, new versus legacy components within the process, utilisation of the tool stack, time estimates per feature team, or functionality. Ultimately, this can contribute to a more efficient SDLC.<\/p>\n

TIMWOOD<\/h4>\n

In the DevOps lexicon, there is a name for the pitfalls that cause wasted time and slow down release trains: TIMWOOD. Each of the seen letters of TIMWOOD stands for a type of waste caused either by a tactical or a strategic inefficiency. In most cases, tactical wastes can \u2013 and should \u2013 be solved within the feature teams, while strategic inefficiencies are more complex and require cross-team collaboration to resolve.<\/p>\n

There is a lot of information available online, together with process-based tools, that can be used to help handle the tactical waste VSMs identify.<\/p>\n

Here are each of the seven wastes identified by TIMWOOD:<\/p>\n