DevOps and Hoshin Kanri – A dream combination
Hoshin Kanri is a Japanese managerial process that DevOpsDays London organiser Barry Chandler has recently discovered, and he wants the world to know how teaming it with DevOps can mean great things for enterprise organisations.
“DevOps alone is not enough!” This is basically the key message of Barry Chandler, who is an organiser of DevOpsDays London. Instead of “only” overcoming the fracture between application development and IT operations, organisations should be working towards optimisation. The path towards such a solution has long been clear to Chandler: Hoshin Kanri.
At the beginning of his reflections is the question of what needs to be observed to ensure the success of a company or organisation. His sobering realisation: Consider the software development process for example, which includes hundreds, if not thousands of factors (both internal and external) that have either a positive or negative impact.
SEE ALSO: Is DevOps making you sick?
In order to avoid danger, Chandler suggests that “choosing which metrics to use is akin to picking your battles”, meaning that a company should consider its focus. The fundamental objectives of an organisation are appropriate to recall here: In the case of the private sector, they’re usually looking to achieve maximum profit, whereas the public sector company might be striving for the best possible service.
The aim of DevOps is often paraphrased as “deliver faster, cheaper and higher quality software” with some variations. Chandler thinks back to Patrick Debois’ “optimise the whole” diagram, where an extension of DevOps principles (culture, automation, measuring, sharing) should be pursued by all teams part of the organisation.
Ideally, the overarching goal is subdivided into ever finer levels of detail, trickling down throughout the entire company. Chandler learned that this type of idea had a lot in common with Hoshin Kanri, a Japanese management approach originating from the manufacturing industry, whose origins lie in various systematic control mechanisms and planning concepts of the 1960s.
The Hoshin Kanri System
Hoshin Kanri is described as a methodology for strategic orientation. It strives to “get every employee pulling in the same direction at the same time.”
In addition to the already mentioned cascading process involving the company’s goals, performance indicators and metrics, Hoshin Kanri places additional emphasis on making these things visible in the organisation. Not only are organisational drivers presented (in a vertical orientation), but the improved visibility also opens up better coordination and collaboration opportunities at the horizontal level (i.e., the team with which you work as a software developer).
Chandler describes the Hoshin Kanri style consisting of 3 phases, which are repeated at all levels. At first you have the initial vision, objectives, performance indicators, etc., and the necessary measures for their implementation. For the next step, strategic plans are set out and executed. The last phase of the process sees the monitoring of these plans in order for them to be constantly adapted and further developed.
This process can equal to numerous organisation advantages, in Chandler’s opinion. As a company shares a “consciousness”, the impending results lead to a best-case scenario, thanks to more clarity on objectives and how they are measured. Every employee knows where the company stands and in which direction it is developing.
A positive result of this consciousness is that employees can better assess whether their decisions are in the best interests of their organisation, or whether they’d be detrimental. Furthermore, it should also reduce the potential for conflict; better coordination of (joint) objectives are achieved while ambiguities are eliminated and teams collaborate successfully. On top of combatting the silo mentality, it also facilitates a strategic realignment of the company in both vertical and horizontal directions.
Large companies, in contrast to small startups, should benefit the most from this process according to Chandler.
The combination of Hoshin Kanri and DevOps
Just like DevOps, Hoshin Kanri’s basic principles (visibility, transparency, continuous improvement) play a large role in defining corporate culture. The greatest similarity of both approaches is their horizontal orientation: DevOps aims to ensure that teams collaborate, to streamline the workflow and thus procure the realisation of corporate goals better.
Chandler considers DevOps a horizontal extension, which has properties only found in the context of technology. This is also the reason why he imagines a partnership between DevOps and IT security (DevOpsSec) in that they also share a horizontal flow. According to Chandler, this fundamental principle can be expanded to further areas:
Recognising that the basis of DevOps can be modelled and mapped to a framework which has scope covering the entire enterprise helps us understand that focusing on DevOps in isolation might not reap any significant benefits in enterprise terms.
And this is where Hoshin Kanri comes into play. The system provides a basic prerequisite to fully exploit the potential of lean processes, agility and DevOps. All members of an organisation, no matter what level of the hierarchy they’re in, are pulling together with visibility, transparency and sustainability at the core of their new way of working.
Chandler can’t offer a recipe for the successful implementation of Hoshin Kanri, however he advises us that instead of trying to do everything at once, proceed with caution and consideration.