This guest post was written by Kit Friend – Agile Coach and Atlassian Strategic Partner Lead for EMEA at Accenture
The views, opinions and positions expressed within this guest post are those of the author alone and do not necessarily reflect those of Accenture or their clients.
Let’s recap briefly why this Value Stream thing is getting everyone excited (and not even particularly recently – SAFe’s value stream architecture credits key elements to 2004’s Implementing Lean Software Development: From Concept to Cash by Mary and Tom Poppendieck, and much of the logic is far older). Though there’s a huge amount of complexity in actually mapping the things within an existing complex enterprise, the concept itself is fairly simple – effectively it’s far better to organise your efforts around creating and iterating a channel that links the raw ingredients your company can access, all the way to the people willing to pay for them (usually your customers). I like to describe this in terms of two competing companies running watermills – it doesn’t matter how impressively or hugely a company builds segregated ditches from their water source, the company that builds a thin channel all the way from source to destination is going to win every time:
…and on top of this, which company is going to discover a critical fault or efficiency in paddle wheel bearings first? It’ll be the one with something working in the market and the ability to make small changes quickly of course.
So far, so good – but rallying your large siloed enterprise around the concept of a better way is just the theory box ticked, to mobilise change (particularly working the pandemic-shaped world of 2020 and beyond) it’s essential to invest in tooling to turn value streams from being a (digital) whiteboard and slideware exercise, into a living part of how you organise teams. Gartner splits these toolsets into:
|Value Stream Delivery Platforms
|Value Stream Management Platforms
|‘provide a fully integrated set of capabilities to enable continuous delivery of software. These capabilities may include project or product planning, build automation, continuous integration, test automation, continuous deployment and rollback, release orchestration, and automated security policy enforcement, and may provide visibility to key value stream metrics.’
||‘enable organizations to optimize end-to-end product delivery lead time. These platforms provide greater visibility and traceability into the flow of all product delivery processes, from ideation to release and operation’
Amazon Web Services
…essentially the Management Platforms seek to provide some intelligence to help knit together the lakes of data and activity being generated by the people and tooling doing the Delivery. It’s enticing to think that we should be able to jumble this all together and point some sort of neural network at these kind of problems, but giving all the data meaning and enabling teams to take actions from it isn’t quite so simple. Common issues faced by teams trying to tackle this include:
- Disparate toolsets and stacks (challenging to pull data from)
- Multiple data sources and data hygiene issues
- Challenges in processing this data into accurate, transparent, and actually useful metrics
- …getting people to understand how to use what they are seeing
The last can often be the most difficult – where large organisations are still struggling to understand how to implement agility consistently at various levels, a lot of data can be a dangerous thing.
How to avoid creating a (data) monster
As the Large-Scale Scrum Guide stipulates:
It is common for organizations to look for tools to solve their problems even though tools are rarely the cause of the problem. Avoid solving problems with tools unless you truly, deeply understand the problem and consider a tool to be the right solution for that particular problem. https://less.works/less/framework/product-backlog.html
Over-emphasising the role of tooling can distract organisations from making the investment in supporting the people and process changes they deeply need in order for the tooling to make any sense. Instead, particularly in a maturing organisation, it is wise to view of the role of tooling as provide visual clues as to the problems you need to tackle:
A cumulative flow chart might help identify where bottlenecks in your team’s flow are
A Gantt Chart and complex permissions on ticket movement won’t de-risk your deliveries
Faced with the opportunity to create hundreds of fascinating graphs, charts, and metrics in a few clicks, it’s tempting to overwhelm teams and stakeholders with screens full of data without focussing on what is actionable. This inevitably results in the “email newsletter problem” – people only read and digest the first couple of items. When curating your tooling to support a value stream it’s therefore important to come to terms with there not being a one-size-fits all approach – far better to have a flexible set of tools which allow users to easily create views which are relevant to them.
Outcome vs Output
So you’ve assembled your Value Stream, got some fancy tooling, and have a bundle of agile teams hard at work – what could go wrong?
The next piece in the puzzle is to ensure they aren’t busy creating chocolate teapots and fish bicycles terribly efficiently. Christophe Achouiantz sum this up neatly in his writing:
How Outputs generate Outcomes that generate Impacts by Christophe Achouiantz
Whilst implementing both elements of the aforementioned value stream tooling is vital to continue to optimise the Output segment here, teams not adopting Product-led ways of working and introducing a feedback loop to measure and integrate the performance of their products in live will swiftly find themselves experiencing disappointment. The rise of OKRs and platforms like www.gtmhub.com reflects the challenge in meshing together these very different worlds of data, but the majority of organisations still struggle to follow through on tracing the benefits data which is locked in before delivery begins, once the products they were associated with make it into live.
(An aside: be careful with language when comparing the concepts of efficient and effective with international teams – Howard Johnson and I encountered an amusing problem whilst teaching in Sweden, where both terms translate to the single Swedish word ‘effektiv’ – thankfully this hasn’t stopped Swedish companies like Saab becoming icons of agility)
How can these host of challenges and vague warning translate into something workable? Many of the same tips to pragmatically mixed agile transformations apply:
- Engage your teams, and save them time
Try to avoid anything which creates additional overhead for your teams – anything requiring manual time logging in particular should be viewed with suspicion. Engage your teams early, and find out what data would help them take action to fix existing pain points.
- Plan on it being messy, full of surprises, and… not what you plan
Don’t make the mistake of waterfalling your agile tooling – embrace an approach where elements can be created and validated early, changes made, and customers engaged.
- Maximising the number of tools not used vs experimentation
Remote working expert Molood Ceccarelli cites the importance in not flooding people with too many tools – a critical philosophy in a world where more remote working away from office dashboards is likely to continue. Balance this with not narrowing down your options too early – use pilots and trials to gives teams the opportunity to provide real feedback before you narrow down your choice of tooling.
- Embrace the cloud
Many organisations still struggle with opening up their data – blocking their ability to make the most of a flexible range of SaaS and PaaS services. Tackle this early, challenge assumptions (there are examples of adoption in pretty much every country and industry), and get sponsorship for the journey to the cloud – spinning up large platforms within your own infrastructure is unlikely to produce the best outcomes for supporting your teams.