A green dashboard with only green colour, is really good news, and brings harmony to the contemplator. To show for all employees what is going on in the company, is simply also the Lean way of doing things, no matter if it is manufacturing, service or product development. We can show progress or status of products, projects, maybe the on-going transformation and a lot of other things. But, if you ask Toyota, they would be worried if the dashboard is always (and maybe all) green, since that according to them, means that we have stopped all problem-solving and all improvements. And that is clearly not Lean. If we believe that the dashboard, that is only a really simple tool, is the main thing of Lean, we have missed the whole mindset of Toyota, the necessity of always become better. That we always can become better.
In many cases though, a green dashboard does not mean that we do not have any problems, instead the main issue is that we underneath the green colour has some mess alerting, a red colour that do not reach the dashboard. The reasons for this are many, and one of them has its own expression; “don’t kill the messenger”. Maybe we all have worked in organisational cultures where only optimistic and positive information are brought upwards to higher manager levels. We are talking about the phenomena the watermelon effect; bad messages (the red meat) stay underneath the watermelon’s peel, and only good messages (slices of green peel) are shown.
Since the market is constantly changing, so do our ways of working, which is the reason that this blog post goes one step further than the watermelon effect normally does. The reason is because now we have in many areas entered the “gigs era”, small parts that are done separately and aggregated (actually false integration) to a whole. A good example where gigs are done to a greater and greater extent, is in software product development.
Software product development (Scrum as example) has, as a result of the agile movement, entered a way of working that also at scale is represented by small implemented parts of independent functionality (gigs). Agile software development originated from one or a few autonomous teams responsible for a product (the whole product), implementing the functionality (parts) in small gigs. These parts are often end to end functionality and the teams are keeping track of the wholeness themselves. The teams with their Scrum Masters together with the Product Owner, could together give a good status report regarding the progress of the whole product, since they also had responsibility for the whole product.
But with product size, there is a need of scaling, and the agile scaling approach has in the most cases been bottom-up. The problem with this approach is that it is really no difference about all necessary work on the whole (system) product that need to be done. Here size does not matter, so we still need to keep track of the whole, the functional and non-functional system requirements, do the systems design, keep track of the emanated parts and their interdependencies, their architecture, the integration, verification and validation of the whole, etc. The few teams make also this work all together, like a small company, and they do the work top-down in order to reduce complexity on the whole*, to be able to make smaller pieces, that at the end can be integrated.
So, when we scale bottom-up to tenth or even hundreds of teams, who is then taking care about all this necessary work on the whole? No one. It is simply “lost in translation”, since the focus has been on autonomous teams, not on the wholeness. And refactoring a big system to achieve structure again, is simply not possible due to high complexity, see this blog post for a deep dive into refactoring.
Who can we ask when we in big organisations start to get delays, quality issues or performance problems on the wholeness, our product or our organisation? No one, since no one represents the whole product, or the whole transformation. As you understand, a coordinator will not be of any help, coordination of parts has never solved a complex whole. If we ask around in the organisation, everything is ok. The respective department/ section/ unit/ group/ team think that they have everything under control for their respective part of the product. And if the future shows that they actually have problems on their part, they simply state that they will do Continuous Improvement that is hypothesis-driven on their part, so no worries. We have therefore nothing to dig deeper into, because the problem on the whole is always someone else’s problem, or regarded as an easy fix. So, we seem to have coherence, but where is the cohesiveness in our new innovative product?
What does this mean for our dashboards? Traditionally we had parts of the whole (product or organisation), that have been derived from systems design and at the end integrated to a whole, most probably through some iterations or prototypes. Every part could be subject to be shown on the dashboard, where of course the risk always is that the correct status is not shown, if problems (the red meat) are not shown. Nowadays we instead got thinned slices in many different directions, it can be end-to-end functionality (user story, feature, epic), architectural modules, components, value streams, etc., but that has never been part of a proper systems design. So, when these slices are put together, they are not integrated, but instead aggregated or false integrated to a whole. What does this mean for our dashboard? It will be green as grass. Since everybody is doing their own independent gig of functionality, according to their own independent planning or burn-down chart, every part is independently green. And if there are problems with a part, hypothesis-driven Continuous Improvement will solve them. We are therefore totally blind(ed) by the green colour until we need to deliver, which will be very painful, since we are only very, very lucky if our aggregated parts also integrate together as a whole.
So, the interpretation of our dashboard when it has only green colours, has moved from: all parts (or shown as a collection from a program or project) for the whole (product, transformation, etc.) is ok, even though we also need to scrutinise that existing problems really are colouring the dashboard, to: we have no clue about the status of the whole, since scrutinising will only show green light for each and every part, and no red alerting meat. The meat is actually gone, and left is only independent peels of watermelon.
Traditionally we could ask the Project or Program manager about the status of the whole, but now there is no one to ask. It is simply no longer possible to get someone to report the status of an important delivery anymore, a scary situation is the least we can say. This is the situation for many companies and governments that have started to work with transforming their way of working to frameworks for agile scaling. Which comprehends not only software development, but also the whole organisation that at the same time is transformed, bottom-up as well, to some kind of agile thinking.
As we can see, our dashboard “problem” is only a symptom or an unintended consequence of not properly reducing the complexity, which should have been done by a systems design in the first place. Of both organisation and product, and in this order, since the way of working for the former is a prerequisite for the developing the latter. So, it is first about understanding the purpose (which is a context-free constraint) of the organisation, in order to achieve the way of working in the organisation.
Once again, we can understand also in this blog post, that our agile way of working with bottom-up scaling, is not giving us the cohesiveness, we so badly striving for, no matter if it is regarding our organisation or our products.
So, now it is time for us to think anew, act anew, change our thought patterns, or pattern of thought, since we can clearly see that at scale, the new way of working is missing the whole, which the old way of working was good at. Time to combine them. This will be done in a series of coming blog posts describing Test-Driven Systems Design, the urgent need of designing also the tests for the total system as well of a systems design top-down approach, which will be intertwined with other important and related blog posts especially regarding this rabbit hole series.
C u soon again.
* Traditionally, in hardware product development, the parts always emanated from the requirements of the whole, when developing a new product. This is what is called systems design, which is aiming for the ability to integrate the parts together (iteratively with prototypes) fulfilling the functional and non-functional requirements of the whole. What has happened lately, is that of the integrated parts of the systems design, only an architectural sketch on the top level, is done. Then the teams do the end-to-end-functionality, small parts of the functional requirements in gigs, which resulting for example in micro services, or similar, as often in an agile architecture.
It is hard to make a short, but good analogy about the extreme risk-taking when starting with small slices of end-to-end functionality without first start to think of all aspects of the whole, especially the non-functional requirements. But, with a bigger system, implemented by many teams, the complexity increases exponentially, as well as the risk, if there is not a proper systems design done on the whole from start.