In the build up to the Study of Enterprise Agility Conference (SEACON) in November, I caught up with Daniel Terhorst-North, Enterprise Transformation and Technical Delivery SME, and asked him a few questions.
At SEACON, Daniel will be presenting in the final session in the afternoon on the main stage.
Here's what he had to say...
SEACON is now in its 3rd year. How have you seen the adoption or focus on Enterprise Agility practises change in this time?
I am seeing more companies realising agility is more than getting the IT department to go on Scrum training, or hiring a legion of SAFe consultants to put new labels on the same old hierarchy and hand-offs.
My answer may be skewed because my work tends to be inbound— people contact me to see if I can help them — so there may be a selection bias in the kinds of organisation I see.
Managers are becoming more savvy about measuring end-to-end lead time, including what Donald Reinertsen calls the “fuzzy front end”—all the work that happens before development effort is formally committed—and the full path-to-live until the new capability is in the hands of users and making an impact.
What will you be talking about at SEACON this year?
Last year I spoke about SWaRMing, a tongue-in-cheek acronym meaning Scaling Without a Religious Methodology. The goal was to get people thinking about the ingredients for successful change, such as investment, leadership, education, etc.
This year I want to get into the mechanics of strategy. How do you go about improving the Enterprise Agility of an organisation? What should you be thinking about? What sort of team will you need to assemble? How can you measure yourselves?
The vast majority of people I speak to, be it a Development Manager, Operations Engineer or Senior Executive, don’t know the mission of their organisation. If so many people aren’t aware of their enterprises mission, is having one important?
I think the answer lies in the enormous inefficiencies of organisations that don’t have a mission.
I don’t know how many times I’ve asked a team or division how their specific work moves the organisation forwards, and received a shrug or shuffling of feet, or some kind of defensive posturing. Having a clear mission gives people a sense of purpose, and provides something tangible to say “no” to distractions.
It’s been 10 years since Patrick Debois put a name to Devops. Since then it has become a multi-billion dollar industry. However, despite measuring and feedback being at the heart of Devops, why do so many organisations struggle to empirically measure the business value their Devops transformation activities provide?
The history of business IT is large projects with large budgets and large (multi-year) timeframes. Any business impact is necessarily distant in space and time from when the work occurred, so it became meaningless to try to map activity to results. Working in smaller chunks to deliver smaller impact more frequently means we can get a higher fidelity path from work to value, but this requires learning two sets of tricks: delivering smaller things more frequently, and measuring the value of the work we do. Both of these are non-trivial undertakings so it takes time for most organisations.