Crypto Cloud Review - How To Earn Up To $500 Per DAY Of Bitcoin 100% On AutoP...
Make Continuous Delivery work for middle management
1. MakeContinuous
Delivery work for middle
management – it is not
black magic!
Matteo Emili
twitter.com/MattVSTS || mattvsts.blogspot.com
2. Who am I?
Visual Studio and DevelopmentTechnologies MVP
Visual Studio ALM
Professional Scrum Master I
Community enthusiast!
I work at One Identity (part of Quest Software) as an ALM and
DevOps advisor
3. The problem
The journey to Continuous Delivery is fraught with hurdles
Technical
Methodological
Historical
There is often friction between the CD champions (teams or C-
suite) and the middle layer.
4. CDChampions
A Continuous Delivery Champion is someone who pushes and
evangelises Continuous Delivery across an organisation
CDCs are usually from a development team or from the C-suite
They are enthusiasts who want to bring much needed value to the
company with the adoption of a successful set of best practices
They often stumble with a middle management which is not
aligned
5. Why?
A Champion often has either a top-down or a bottom-up
approach, depending on the background
Middle management is often insulated from this because they are
responsible to directors and above for their teams’ results
The disconnection makes it drift away from the priorities of the
Champion
Barriers are erected, causing friction and misunderstandings
8. Conway’s Law
“organizations which design systems ... are constrained to produce
designs which are copies of the communication structures of these
organizations”
The Mythical Man-Month – Fred Brooks, 1975
9. There is one
additional
challenge…
Continuous Delivery relies heavily on DevOps
DevOps doesn’t have a definition!
It isn’t a process, it isn’t a methodology, it isn’t a technology
There is no DevOps Enterprise Edition installer…
DevOps is a collection of best practices where the whole
organisation is involved in bringing value to the customer
Also, there are many methodologies that can be used in a
Continuous Delivery environment, leading to further confusion
10. TheThree
Ways
The Phoenix Project is a fictional story of an
organisation like many others…
One of the takeaways is about TheThreeWays
Principles you can use in any production
context, not just IT
Most of DevOps and Continuous Delivery’s
practices are derived from these three
principles
14. How to make it
work #0
Break the
barriers down
and change
things slowly
Barriers are the main issue in a CD transformation, preventing the
implementation of the FirstWay
If barriers are still in place there is no way of creating a feedback
loop across the whole company (SecondWay)
Without a feedback loop teams are insulated, and there is a high
risk of delivering little value to the customer (with lots of technical
debt) or no value at all! Not much of a ThirdWay here…
Changes should be brought forward in a small and iterative way
No big-bang breaking changes, less resistance
Automation helps reducing waste and removing bad habits
inherited from years of traditional development
15. How to make it
work #1
The Minimum
Viable Product
Start small where you can have disruptions or failures
Start by delivering something – a small set of working features
Build incrementally on top
Why?You can quickly test if your ideas are correct, and estimate
the added value for both the customer and the company
Short timebox, a few features, go!
16. Also tools!
Tools contribute to the segregation
Everything should be open to anyone (with the appropriate
security)
Closing the ALM stack to business roles (e.g.: POs, support, etc.) is
not a smart move – and it is also a barrier
Information sharing should be encouraged, in areas like
Acceptance Criteria for example
18. Data is
unbiased
With a unified platform you are generating a unique and unbiased
data source for the company
The more you expand this platform across the organisation, the
better you can use it for approaching the Continuous Delivery
problem
Involving higher ranks means you will get an expanded view on
how a certain story fits into an overall strategy
There is no such thing as “a developer/business/operations tool” –
most modern ALM/DevOps platforms are meant to be used by
different roles with different tools
19. Set your scope
Middle Management is squashed in the middle of the approach
the CDC decides to use and their visibility is somewhat reduced
Their scope is set above the single teams but below the vision and
the strategy used by the C-suite
What usually matters to them is how many features are delivered,
maybe correlated with the relevant Epics
21. How to make it
work #2
Flexible
scoping
The tool you use should be able to drill down from Epics to PBI,
but retaining a rollup view
With specific exceptions, PBIs are not really interesting for Middle
Management
Backlog is relative – what matters is what is in progress and what
is done
Focus on the value you are bringing on, drilldowns on technical
matters always come second
22. How?
Start small, with filters – make the backlog a ubiquitous presence,
tailored to what you want to show
Take advantage of items relationships (parent-children)
Use a tool you can access with Excel
Pair your tool with something that gives you a high level overview
of the release train across multiple iterations
24. Make Product
Owners meet
the customer
Product Owners should know the customer demands for real, not
from an analysis point of view
The strategy should be focused on customer feedback and
priorities should be dictated by what customers really want
POs and above must be in agreement
Added value is going to be perceived both ways
25. So, how to
make things
reasonable?
“You can’t change what you can’t measure”
In the Build-Measure-Learn loop the Measure stage is the most
important one
By measuring you gather evidence of something to change or
improve without relying on biased opinions
Only Metrics will tell if you are going in the right direction, so it is
critical to ‘get them right’
Extend your product to include what really matters
Reduce maintenance costs
Proactively understand potential problems
26. How to make it
work #3
Insights for the
win
Instrument your application and gather insights on how users
behave
Telemetry is a must have these days, providing your teams much
needed information about usage patterns and performance
Real world example: your exceptional market changing feature you
spent millions on might be buried beneath seven different user
interactions
Nobody uses it and the company just wasted resources
The Product Owner drifts away in its own bubble
28. Recap
People first,
process then,
tools follow
Remove bottlenecks
Facilitate communication
Start small, build on top of your wins
Show evidence and gather actionable and objective data
29. Recap
Share it all
Every role in the company should have access to what you work
with
Try to estabilish a ubiquitous language across the toolset
Non-technical management should have a clear idea of the
direction of the product
Stakeholders are part of the process, they are not separate
30. Recap
Close the loop
with feedbacks
Feedbacks and insights, coupled with internal data make sure you
are getting in the right direction
Quickly validate your ideas against real world usage
You are building for the customer, the customer is sharing its
priority
Everybody take advantage of it, from developers to Product
Owners
