Digital succeeds executed at speed
In Japanese, Hayaku means quickly, it's essence of digital execution
Embedded Files
Digital Transformation notoriously has an 84% Failure Rate
Digital Transformation notoriously has an 84% Failure Rate
McKinsey’s 2018 survey reports that 16% of enterprise digital transformations are a success, which leaves a woeful 84% failing against their objectives. You are probably reading this because you’ve had a role in one of those failures, which given the odds, is no shame. While any Big Four management consultancy will advise expensively on 'What can be digitised’, they offer no help on ‘How to do it’ because ‘it depends…’. The field is left vacant for the scattered, narrow and self-serving propositions of the juggernaut Cloud Platform vendors, hipster DevOps gurus and earnest Agile evangelists. Businesses are left wandering in a delivery know-how wilderness, where old reliable structured agile and waterfall approaches repeatedly lead to costly dead ends of no value. This is the primary root cause of the expensive 84% failure rate. Solve this delivery problem and become a rare winner, able to navigate to a successful digital transformation that creates a stream of high value business ideas and delivery.
The Quick and the Dead
The Quick and the Dead
While they don’t explain how to do it, McKinsey Insights do helpfully signpost that a successful digital strategy is one delivered quickly - “digital rewards first movers and some superfast followers”. Traditionally, companies could monitor competitors’ successful moves, and then ‘outexecute' them. Microsoft were the outexecution grandmasters - the inspired product positioning of Windows NT stole the entire LAN market from a technically superior Novell Netware in around two years. In digital, today, this is completely upside down; an outexecute strategy guarantees you lose in a digital gunfight. Digital speeds up events, and plays out on an open, transparent playing field, where being fast to execute puts you in front, then directly embeds and strengthens new a digital capability to accelerate away from everyone else. The more often teams deliver and launch, the more they can learn about the market and product, and improve their approach, service, and skills. Their capability to react, absorb, adapt, and scale up forms a virtuous, fast, success cycle. While the quick business celebrates the release of Shiny New 4.2, the dead slow will be reflecting on the troubled launch of Lacklustre AlsoRan 1.0.
In Japanese, Hayaku means “quickly”. Being quick is the core, critical attribute for digital success. We must form our teams and choose our tools to work at speed; provide planning and governance that facilitate results. The Hayaku method provides the first concise, coherent instruction manual for a new art, how to be quick at enterprise digital delivery.
A diagnosis, and a quick cure
A diagnosis, and a quick cure
We saw that digital success is built on speed. The simple insight of Hayaku is that speed must be the guiding star for selecting the techniques methods to create a coherent holistic methodology. Perhaps counter-intuitively, quickness also creates efficiency; there is no cost/speed trade off. Delivery happens quickly by eliminating wasted effort using constant, rigorous practise and promotion of the right techniques, that become an innate, muscle memory for the task, like a virtuoso musician approaching a musical phrase.
To help, the Hayaku method is organised in four disciplines, each with a set of techniques to practice.
Teams - Adopt a product perspective and work with your customer. Assemble the talents and then trust them to deliver product and service. Support and enable the team to make their own, good choices.
Tools - Automated everything. CI/CD toolchains dropping code at will, use cloud native design patterns, and consume and create services. Test, test, and more testing. Application and Infrastructure security must be integral to delivery.
Plans - Combine the elements of Agile, Lean, and Design Lead thinking for the situation. Use constant, realtime, iterative planning, Make work visible and keep it online. Link business ideas to strategy to epics to story to code.
Governance - Set the vision, monitor key deliverables using OKRs. Seek and neutralise dependencies. Make decisions as late as possible
A brilliant guitarist’s fingers aren’t any faster than yours, they just move less.
Guthrie Govan, guitar virtuoso and teacher
Teams 組
Self Sufficiency - Get all the skills and experience in place to give teams effective, autonomous decision making power, and not to be waiting on anyone else for help or approval be it security, architects, or operations. Delay is fatal to the overall delivery.
Assemble all you need in one place - In agile, any skills, dependencies and decisions external to a team and its direct line will disrupt and stop a team from delivery; it’s inevitable. Using Agile at scale exaggerates and multiplies this effect; at around four teams plus product delivery visibly slows to a crawl. A pernicious hidden impact is the undermining the teams’ belief that delivery is in their hands to win or lose. If they are waiting for approval or input, the temptation is to point at reasons for non-delivery, a temptation to stop taking responsibility and ownership, and performance will suffer.
When you assemble your resources, bring all the expertise you need into the team, or give them unconditional, immediate first call on any missing specialist expertise expertise they lack, whether this is technical, functional or business context.
The Expertises Required - Identify and recruit a core of engineers who have breadth and depth in tech skills, the "E shaped" people. Developing and fixing digital requires knowledge of multiple disciplines, and they interact. This means finding people who know or have the attitude and aptitude to learn specification, pipelines, cloud infrastructure, development languages, testing, networks, security and architecture. People that are simply not interested or capable in an area will disrupt the flow of your team; at a minimum respect for the importance of each expertise and how it plays its part is required.
Architecture is worth a special mention. It is not needed as a discrete team expertise because so much is done for you by the Cloud Platforms’ products. Recently, IT architecture has started to become software choices rather than design work, so concentrate on recruiting people who understand the Cloud world, believe in it, and keep their knowledge current. Be aware that this change is not a reason to avoid drawing a picture of how a application fits together as a solution architect would; this is a key piece of understanding.
Product Manager and Product Owner roles are a vital part of the team; without them the digital team will flounder trying to complete anything of value. Make them integral to your way of working.
The ability to learn quickly is a key expertise in itself; find people who are used to change and renewing their skills and outlook in a technical and commercial landscape moves on a quarterly cycle
Trust - Trust your team of people to deliver and operate the product. Let them make their own, good choices from the options available; they will learn and mature quickly. Save your own interventions for preventing big mistakes, rather than guiding smaller decisions. Bring them into hiring decisions, and ideally delegate them entirely; again, responsibility and ownership breeds better decision making and outcomes.
Product perspective -Encourage design-lead thinking and good, economic innovation and MVP experiment design from your product people. Life is too short to build things nobody needs; the Product people need to evidence why the customers do really need the things they are asking for.
Operating Model -"You build it, you run it” is a simple mantra of both the DevOps and Site Reliability Engineering movement, and it's superb advice.
It's simply amazing how this galvanises attention to detail, automation and resilience and a robust, consistent customer experience.
Tools 具
Automated Everything - Whether this is the automation the team has built to code apps, test and deploy them end-to-end, or the automated platforms you are building on provided by the service providers in the PaaS and SaaS products, automation adds the speed required to succeed at the work. Further benefits of relentless automation stem from the rigour and accuracy that automation requires. This adds a robust layer of quality to deliverables, and an enforced rehearsal of recovery from issues. Automation is hard work, but any let up proves a false economy.
Maximum CI/CD - Continuous Integration and Continuous Deployment are mandatory items. These have to go all the way to Production to achieve the pace of delivery and resilience/recoverability you require. Accept no substitute.
Having seen a few of these in action, a pattern on which one to choose for which job ? The more modern and recent ones are good. Use the cloud providers own (Azure DevOPs, Google CloudBuilder...) to stand up a team for quick results. Build your own as the work gets investment and complexity grows.
Keep infrastructure builds on a separate pipeline journey to the app where this makes sense.
Cloud Native Platform - Kubernetes deployments will give you speed, efficiency and resilience, but come with overheads in set up and security. Google's version is quicker to get going and comes with security features out of the box that others need third parties for. WebApps are all good options for the right sort of app and scaling requirements, as are the mobile development tool sets, and all (currently) come with less overheads than full containerisation.
Services, Internal and External - Use them to deliver and operate. Services to manage user identity and databases speed delivery exponentially. Building your own API Gateway using a tool like Kong or Apigee is a great way to manage and right-size microservices at your application level, and abstracting those services from each other to make future large component and functionality changes so much simpler and quicker to carry out. Provide your team with the technical and commercial information, and trust them to make their own, choices on what to use against the product requirements with their operational insight.
Testing
Embrace and encourage all flavours of testing to include in the pipeline, beyond functional testing written for the app code. Ensure infrastructure inspection and cyber tests are enabled and the resulting tech debt identified is reduced regularly. Testing is the safety net of automation; without comprehensive coverage the team will deploy bugs and vulnerabilities into Production with commendable speed and frequency.
Program and Product Tooling
Agile tools to manage everyday work is a well understood area. Jira is simply becoming a de facto standard to run your scrum and kanban with.
Add a whiteboard tool like Miro to make the strategy and roadmap visible to everyone, so the engineers can quickly understand and orient themselves with the flow of work and identify priorities.
Operations Tooling
You build it you run it - the engineers will need tools to run things. Slack or Teams is an obvious place to manage everyday comms traffic, and also the incidents as they arise. Support the team with an array of monitoring, alerting and ticketing tooling to support their workflow, and the new operating model.
Plans 企
Make Everything Visible - then everyone can quickly understand what needs doing, why, and how to do it. It is astonishing how quick drift sets in with busy people, no matter how clever they are. Keeping things visual, symbolic and simple will speed and ease communication, and get the right focus, decisions and productive work done
The acid test of a good set of plans plan is to try and trace a route that traces back from a line of code deployed to production, back up through the reason the function was required, and that function mapped in turn to the simple stated strategy and vision. The aim of the planning process is to establish and continually visually reinforce the threads that bind Strategy to Roadmap to Development Stories to the Repository of working code.
Break down the work
An old technique but a great one. A prerequisite to making everything visible. Inside vague titles for epics and boxes on any flow chart lurk the details that will change your approach to ordering work to be done, understanding the size of it, and organising the best flow of the delivery
Use spikes to decide the best course forward. These are intense, practical pieces of work to evaluate options against your situation and future path. The most valuable is proving to be the architecture spike, used to choose what cloud services to deploy. Practically trying out a thin end-to-end implementation will greatly enhance the information available to the team to make decisions. Does the product/service really do what the brochure says? Do we actually need all those features...and how much does it really cost in a production posture?
Remove Technical Debt
is as an important a contribution to delivery speed as automated testing; it has to be part of a delivery planning and approach. Neglect and compromise will soon kill your deliveries for months as you pay down the accumulated debts with a compounded APR. Technical debt is a stealthy, smothering killer, the carbon monoxide of digital engineering. Watch carefully for workarounds emerging as a pattern on standups, and listen to the teams’ discussions on how quickly they can deliver. As a leader, pushing too hard for delivery when the tools aren’t ready will create tech debt pollution, and you must plan for a clean up crew afterwards. Addressing technical debt little and often is one option; sometimes there is no alternative to major surgery when small compromises accumulate, or a new pivot needs to be pursued, driven by business opportunity, competitor activity, or emerging technology - sudden technical debt can be created by external events.
Optimise for Flow throughput
Delivery flow takes priority over organising and planning for resource efficiency. No one will thank you for saving a bit of money and not delivering the product. Delivery always outweighs the savings. Use Work in Progress limits on kanban and scrum boards as a simple technique to achieve this.
There is no such thing as a RAID
Do not have a risks, assumptions, issues and dependencies board for the team; the actions on it rarely get taken, the board gets watched as it fills up and spills over. Instead, make all risks and issues into task cards on a board, assigned to someone to resolve. If everyone decides it’s not worth a card, it’s not worth worrying about.
Dependencies must be removed, and actively managed by the leadership team every day until they are taken care of. That’s the job of management.
Assumptions? Make them into spikes and plan them into the roadmap to validate them. Unexplored assumptions kill products and programmes.
It’s not saying no that’s the problem: it’s saying yes slowly.
Matthew Syed, How Innovation Works
Governance 攬
Simplify, Delegate & Measure - Digital work has to move quickly to succeed. This can't be done with the multiple gates and checks that organisations have put in place to stop overspend, define and enforce architecture standards, security breaches, data leaks, and resource optimisation. To enable quick digital work, bring the expertise governance into the work itself and build a constant feedback loop on the business effectiveness of what is conceived, chosen, how it is delivered and operated, and the outcomes in cash and happiness.
Tracking and (Re)focus
The digital team's value depends on the generation, market testing and deployment of business ideas. This must be the prime focus of the governance effort - are we doing the right thing, and how quickly can we keep doing it? Feature uptake, revenue, and time to market from idea to operation are all good things to measure and build into the application and processes you are automating. These can all feed into your living, monthly iterative planning process.
Architecture, Security & Data Compliance
To be able to move these functions into the team's work they must possess the correct practical knowledge, and the custodians of must trust or agree that good decisions are being taken locally. The digital team needs to move review and evidence into automated testing and compliance reporting into their automated pipeline and routines to demonstrate the depth and quality of checks taking place. Working this way means the team can leverage the knowledge and speed built into services and products; if these are agreed and approved, there is simply less governance to do. The absolute best solution does not need to be found every time a choice is available; keeping decisions flowing and making sure there is allow friction path out is more important; presenting engineers with a simple choice and asking why it won’t work is one way of achieving this effectively.
Governance functions
are winners too - they can move resources from a transactional review activity into added value improvement and innovation work
Financial Control Review deliverables and benefits, assess confidence in how well things are running, and give the team direction and release funding on a quarterly cycle. This enforces constant focus on relevant deliverables by the product team and the engineers, and gives the Executives teeth to invest, accelerate, change or halt the work. Quarterly checks allow us all to review the business priorities and market events, and technology changes from the vendors and service providers.
Make decisions late as possible
Having fixed gates and committees to timetable decisions practically ensures bad ones will be made because of convenience. Instead ensure the people dealign with the armed with the best knowledge of what needs deciding have the fullest support not to chose an option that will cause problems elsewhere by facilitating the right co-operative ways of working.
Join the 16% - become Quick, not Dead
The Hayaku method is a set of techniques that provide a concise, coherent instruction manual for a new art of how to be quick at enterprise digital delivery. Adopting any of them will start to help you join the 16% of successful digital transformations.
Its techniques provide benefit beyond the immediate delivery of an important product or project; practising them will fundamentally change any enterprises’ permanent capability for the better, making you able to deliver digital at a speed that pleases the board and shareholders, excite talented teams, and worry the competition. Our implementation of some of the techniques set out here have transformed organisations’ ability from releasing software every four months, to dropping features four times a day.
Rather than lighthouses, exemplars or pathfinders, It is crucial to consider the digital capability as a permanent new established digital work mode and operating model, delivering and working in a new way.
Contact tim@hayaku.digital
Page updated
Google Sites
Report abuse