Define Value-Adding Activities

Step

Value Adding

Ideation

Well, we can’t do anything without an idea so, yes, value adding. But best to get the ideas straight from the customer, no matter what Henry Ford reputedly said. And don’t spend too long gathering huge lists of requirements; staying lean and agile means small batch and being experimental.

Change Approval

Definitely not value adding. Also very annoying for most employees. Not only do CABs slow down flow as teams have to wait for them to meet, usually they are making sure checklists are being followed. Get rid of this one entirely. 

Develop

Absolutely. Undeniably. Indubitably. This is where the magic is happening.

Build

No. This is the mechanics of putting the gift in the box. It can’t be removed though.

Test

This is the one that always causes the most controversy in the room in my experience. So much so that I used to concede and draw a dotted line around the step on the board in the VA color. I say it’s not VA because it’s not creating anything additional for the customer. But the counter-argument is, that without it, what the customer has could be so bad it’s useless. We can all agree it’s essential, but we should look for ways in which to ensure it doesn’t slow flow. Also, we don’t want to spend all our time making sure something works or it works fast; the customer is expecting all of that. What differentiates you is in what you enable your customer to do in your product or service that enhances their life. Focus on that. (The magic ‘Develop’ step, above.)

Integrate

Not VA, but the new code’s going to have to be spliced into the old code at some point. But, how long’s it going to take you and how much rework are you likely to create?

Release

No. This is the mechanics of putting the gift in the post. Essential it is, VA it is not. This isn’t a step you can get rid of, but can aim to shorten as much as possible. And also keep an eye on the rework you might create if you mess it up.

Step

DevOps Interventions

Ideation

• Don’t slow yourself down by gathering big batches of requirements up; continuous delivery, remember:
• Having small changes means small build, test, deploy cycles later (you may find this driving architectural changes too)
• Be experimental and shorten and amplify the feedback loops to power ideation
• Ensure you have a value hypothesis at this point and that you know when you are going to measure what

Change Approval

• Lightweight, peer-reviewed change in multi-functional, autonomous teams
• Checklists are automated into the CICD pipeline including non-functional tests for compliance and security

Develop

• Don’t remove the magic, but key to all of this is getting that cycle time down. Developers can help with that with using practices like trunk-based development, Test Driven Development (TDD), keeping user stories small and being prepared to deliver when they reach Definition of Done

Build

• Automate it and keep them small

Test

• Automate all the tests: unit, integration and user acceptance at minimum for continuous integration and your non-functional tests too
• This likely means some upskilling for your testers and developers (see also TDD above) and some stern words with anyone that’s pushing change over improvement time. Teams need space to make improvements that inject capacity later and this is a classic example

Integrate

• Automate it using a CI server
• Practice trunk-based development
• Put all those automated tests in your CICD pipeline and aim for Continuous Deployment to reduce time spent here to as small as possible

Release

• Automate it - automate the infrastructure/environment provisioning and tie the configuration and code together
• Release automation also helps you with incident management - it makes it easier to redeploy last known good state for example
• Use release management tools to manage dependencies while you break them
• Use dark launch/limited blast radius techniques like canary testing to derisk release moments

Operate

• Use AIOps to reduce noise from monitoring and your MTTD and MTTR
• Use the time saved from having less unplanned work to do more toil automation, pay down technical debt, build mastery and innovate
• Use chaos engineering (now that you have the time!) to experiment to build more reliability into your platforms 

Observe

• Don’t just monitor problems, incidents, outages, performance issues and all the bad stuff - look for positive customer reactions too (usage patterns, social sentiment, referrals, reviews)
• Connect what you learn through observation back into the value stream as you ideate your next sets of experiments.