In today’s blog post we will start with common senses that regards scaling, i.e. big organisations, and we start with common senses that are normally not influenced by other people, methods or frameworks.
Common sense: Interdependencies and dependencies between activities will always be present, on all levels of the organisation
When teams are working together, no matter cross-functional teams or not, there will always be interdependencies and dependencies to the other teams and to common experts, which need to be handled. This is handled by planning, for example with an accuracy of days for the coming weeks and with an accuracy of weeks for the longer perspective, so called rolling planning. Not handling the interdependencies and dependencies only leads to inefficiency, both of our resources and flow. Another risk is that the interdependencies and dependencies are noticed, but due to lack of control are handled by separation of the teams’ (inter)dependencies for example with a sprint, meaning that flow efficiency are negatively affected.
Common sense: Passion for experimentation is needed on all levels of the organisation
This not only means to have an understanding of that experimentation means to gain knowledge we do not have and that experimentation is unplannable, since we do not talk about closing a gap to a predefined future result. It also means that all levels in the organisation need to be able to experiment. For example, the top level, when we are making a platform, or a suite of products on a common platform, that the whole organisation will benefit from, and that requires transdisciplinary teams.
Of course, we also need teams on lower levels making experimentation to gain knowledge in their area of expertise, but the main point simply is that experimentation to sort out complexity can be done by any team on any level.
And as we also can see in the agile transformations going on around the world, is that if we forget the portfolio level, or leave it as the last step for our transformation, it means that we will lose the wholeness, the transdisciplinary ability on high levels and the Big Picture. This in turn means that we indirectly continue to make our disciplines/silos/team of teams egoistic, which is the opposite to one of the goals with agile, namely to better unify the organisation with cross-functional thinking.
But, as stated before, the experimentation need to be done either when trying to solve a root cause if and only if we do not have the current knowledge, or in order to solve an activity that has been achieved from top-down planning and systems design. Why? Since we cannot solve symptoms, not even with experimentation, how hard we try.
Common sense. A flat working organisation will make the work easier in a big organisation
That is the result of for example Chinese whispers, the more intermediates we have in the chains of interactions, the more time it will take, and the more information will be corrupted and lost, both efficiency and effectiveness as discussed earlier. This means that in a big organisation, the working teams needed for delivering for example new products, cannot mirror the line organisation, since the line organisation are needed for stability and to keep track of the long-term competences needed for the aim of the company, as well as administrative activities).
A flat delivery organisation means that transdisciplinary work is easier and natural, since every discipline will be in the same room. Looking at the long-term view, people will also learn from each other, making the transdisciplinary work even easier. Note that multi-disciplinary work is not the same as transdisciplinary work, where the former only means experts from different disciplines sitting in the same room and giving their respective expert view of a problem, but actually not working together to solve the problem. This often also means that in multi-disciplinary work, the experts only give their opinions, but not actually working close to the teams. This results in that the teams will miss or misinterpret important information, where needed rework will follow.
Common sense: There are many different contexts in an organisation, so it is not reasonable that they can have the same way of working
Lean thinking, values and principles are a very good example of this, since from this has arisen three well-known and very different ways of working depending on their very different context; Lean Production (for production), Lean Product Development (for hardware product development, including modular platform development) and Agile (for software product development).
But, we also need to be vigilant regarding the software development context, since it can be very different even within a context, for example, consider some different aspects to think about regarding the software to develop:
- Can the software be built incrementally giving the customer new value for every feature?
- Is the user interface towards the customer simple and straightforward?
- Does the customer know what he/she wants or can we convince the customer of the need? (this means simple and non-complex)
- Is the core of the software including the architecture simple and non-complex?
If the questions above to a high degree can be answered with yes, one suitable solution is to have direct customer contact, use short-term planning and continuous integrations, like Scrum thinking with takted 2-weeks sprints.
But on the other hand, if we change our answers on the first two questions to a no instead, then we will not benefit from short-term planning and continuous integrations to the same degree anymore.
And if we also answers no on the last two questions that regards complexity, then 2-weeks sprints are too long or too short depending on the experimentation need both towards the customer and regarding the software solution. This means that takt time is inappropriate as well. And depending on the size of the software, the complexity may well be on a higher level then team level, meaning that we transdisciplinary teams on the team of teams level or higher.
So, as usual, everything depends on context, or as Dave Snowden at Cognitive Edge puts it [1]; “…agility is not needed in day to day business. Trying to make everything agile, is as much a mistake as making nothing agile…” and he also finalises this key note speech with the following [2]; “The future is multiple methods, which are context aware and context dependent and don’t claim to be context free.”. This means that we for our context free (or context independent) set of principles need to find a continuous method for a smooth (product) value flow taking care of the different contexts. This is especially valid in product development which many times passes all domains of the Cynefin™ Framework and this is elaborated on in this series of blog posts about the Product Value Flow in the Cynefin™ Framework.
Beware also of the Hawthorne Effect*, since we humans like everything that is new. So, in Agile’s case we like it because it is new at the introduction and we like it more since it is appropriate when introduced in small scale with independent Agile teams, but it does not mean that it will scale or that it is sustainable [3], as Dave Snowden states.
Common sense: It is good to involve our people in the wholeness, especially in a big organisation where it is easy to lose the Big Picture
To specialise our people too much or when an organisation gets big, will automatically make our people lose the Big Picture. Big room planning in agile is therefore an excellent way of bringing people together around a product, service or a problem that need to be solved.
Big room planning has its origin in Oobeya (Japanese for “large room”) rooms, that explicitly and continuously shows what is going on in a project, presenting goals, plans, status, teams, etc, on the walls in the room for everyone in the organisation to view, to get the Big Picture. Oobeya is strongly connected to Genchi Genbutsu (Go and See) as we discussed earlier, since there must be something to see if we want our people to go and look, to get their own understanding.
But, beware of when the Big Room planning is not considering the whole product, only a part of the product. Because, then we are still not having the Big Picture, and what is more treacherous is that we are conceiving that this is the Big Picture, which will lead to sub-optimisation due to autonomuous thinking. A top-down approach as discussed earlier, is also a must, before a Big Room planning even can be considered.
This was the last blog post about common senses from our free will that depends on scaling. Tomorrows blog post will once again cover the scary part when our free will is strongly affected by external forces wanting us to ignore our own common sense.
C u then.
*The Hawthorne effect (the observer/novelty changes output)
Which argues that humans respond well to novelty, but you should not confuse the novel thing with novelty in respect of cause and effect [4].
References:
[1] Snowden, Dave. “From Agile to Agility”. Link copied 2019-08-04.
https://www.youtube.com/watch?v=xF6qH8PnxAc at 36:53 minutes.
[2] Snowden, Dave. “From Agile to Agility”. Link copied 2019-08-04.
https://www.youtube.com/watch?v=xF6qH8PnxAc at 1:03:29 minutes.
[3] Snowden, Dave. “From Agile to Agility”. Link copied 2019-08-04.
https://www.youtube.com/watch?v=xF6qH8PnxAc at 45:10 minutes
[4] Snowden, Dave. Blog post. Link copied 2019-06-04.
https://cognitive-edge.com/blog/of-effects-things/