It is simple to design an agile system, but it’s tricky in the details…
Some thoughts about #digital #transformation. Today I read in Manager Magazin that seven out of ten transformation projects fail. The role of the CEO is central to this. Then I read other articles saying that the mindset of the employees is most important for transformation, then: the corporate culture!
I deal a lot with digital transformation towards self-organized (agile) network organizations — theoretically by reading and practically in daily software development with #okr and scaled #scrum. The more I gain insights, the more I think: It’s not that hard to design an agile system; but the tricky thing is in the details, or more precisely, in the #valuestreams.
First: There are established agile frameworks, already for years. Stafford Beer’s Viable System Model was developed in 1959 (#bosch seems to be using #vsm now for building a new system), Scrum has been around for almost 30 years, the Objective-And-Key-Results steering tool since 1970 (Intel), #lean Management since 1940 (see #TQM #Toyota). All of this has been proven, you just have to use it! To be honest, it is not really difficult to set up an agile system with these three/four very simple tools. It even will work as top-down introduction. A few okr-cycles, two or three years, with very good internal agile coaches and Scrum Masters for every (!) team, and you already have a quite passable agile system.
The most difficult thing about transformation is this: Identify, automate and trim your (digital) value streams. The shorter the value streams are the better! Form interdisciplinary teams around these value streams. They need every person in the team to deliver value within a sprint. To do so, you have to break down your traditional silo structures. Scrum and self-organization takes place around these #valuedriven streams, end-to-end — full responsibility.
This is the place where interdisciplinary teams work really close to #customerneeds, but of course not so close that they implement every small requirement. The teams have to skillfully balance the #value that the product delivers (small tip: #datadriven and evidence based management #ebm help to balance, monitor and measure your value).
This is where day-to-day-prioritization and product development takes place. Here, the structures must be designed in such a way that the teams largely organize themselves without losing sight of the direction and alignment of the company as a whole.
In order for the system to be able to steer itself from within and from the outside, the agile methods Scrum and OKR complement each other, so that steering is from above (#strategy) and from below, through the needs of the customers.
In this structured way (see Viable-System-Model), a system has maximum openness to the environment and represents maximum #complexity as a system itself, plus reduction of complexity, which is mandatory so that the system does not sink into chaos and delivers the greatest possible value without any #muda.
