LEANability – Lean Business Agility for the Learning Organization
LEANability likes to work together with you to find the best possible leverage to make your deliveries, prioritization or predictions a little better every day. We work at team level or across teams together with the entire company depending upon the situation. Together we will reach the ideal flight level. At the heart, there will be Kanban and its principles for help but that is by far not all.
The flight levels are not wallpaper that you can simply stick over any company and everything will be fine. Recently I was a guest in the video podcast of Mathias Tölken, who, together with his business partner, specialized in the IT management of small and medium-sized companies and founded the eXuviate network. Many SMEs are now beginning to engage in agile work. Mathias and I therefore talked about what “Do not start by making teams agile” means for these companies. Flight Level 2 is of particular importance – it is at this level that middle management, which is very often the initiator of agile work in SMEs, can make the most difference.
It strikes me that it is totally important for most companies that their staff is working. “Yes, I’m working on it” is the answer you want to hear. To be honest, I would get totally worried if I heard from my staff all the time that they were “working on it”. Working is far too expensive! I don’t want them to work, I want them to deliver!
The idea that working is a good thing is so deeply anchored in us that we align our actions accordingly. What is usually prioritized? Right, what is to be worked on. Wouldn’t it be smarter to look at the board from back to front and prioritize what we will deliver next and not what to work on? And what do people often talk about at stand-up meetings? Right again: What did I work on yesterday and what will I work on today? Isn’t that weird? Shouldn’t we rather ask ourselves what was delivered yesterday and what will we deliver today? As a customer, I don’t care what anyone is working on.
Since my new book Rethinking Agile was published, readers have been posting excerpts from it many times. I have noticed that many readers are particularly interested in the topic of cross-functionality. Like the Spotify model, cross-functional teams belong to the inventory of the agile reliquary shrine: their existence is usually worshiped without reflection, but often they are nothing more than silos whose walls have been repainted. I am of the opinion: True cross-functionality does not arise from simply throwing people from different disciplines together in a team. For all those who have not yet read Rethinking Agile: Here is the section from the book that deals with it.
Cross-functionality has nothing to do with team setup It all sounds very romantic, doesn’t it? The fact is, though, this is about enormous change. Why should the business departments simply go along with it? The demarcation between “us” and “them” is a fundamental historical problem that exists in most organizations, regardless what type of organization it is. This can be attributed to specialized splinter groups that typically organize themselves into departments. They split themselves apart from each other and the whole organization. Requests and results are usually “given over” (or tossed over) to the other departments, whose approach and requirements might be completely different than in their own department. Then the demarcation can be seen: the departments are a red flag for product development, software developers are better than software testers, the business departments see everyone else simply as suppliers, and so on.
Trying to make a company agile does not inevitably make this situation better. Cross-functional teams are great to have and an important part of the company. However, it doesn’t necessarily mean that old prejudices just disappear. Now you just have cross-functional Team A that performs better than cross-functional Team B. Instead of functional silos, there are cross-functional silos. Congratulations! If you reduce the dependencies and combine teams according to product lines, Product Y is naturally more idiotic than Product Z. And taken from the portfolio point of view, there are only complete morons sitting at the top. With “performance” bonuses, you can easily reinforce this animosity or even make it worse. In doing so, only individual parts of an organization will be optimized, but not the value creation for the customer.This competition must first be removed. As I have shown with this company, it isn’t as easy as it sounds. It is a cultural process that already starts with recruitment. The required maxim should be “don’t hire skills, hire attitude”. Sure, subject matter expertise is important, but it is much easier to acquire subject matter competence than it is to change attitudes. Cross-functional teams are in no way the Holy Grail of agility making social points of friction between the performance areas of a value stream just magically disappear—sometimes they just shift. Bringing together various schools of thought in one team is still better than focusing on individual performance or on the performance of individual specialist silos. When it’s about focusing on the customer, integrated value generation is only a small drop in a very large bucket.
Cross-functionality is a company mentality and not an organizational setup for teams. It means creating an environment where it is ok, or even desired, to perform poorly locally (whilst learning) if it helps the overall performance of the organization. It isn’t enough having everyone is pulling on the same rope—they must all pull in the same direction, too.
First of all, the clocks tick differently in Bangkok – the jet lag has really got to me this time. Apart from that, I was overwhelmed by the enthusiasm I experienced during two Flight Level classes, a top management workshop, an Applying Kanban training and a talk in 12 days Bangkok. My two Flight Level classes had three special features:
Nearly consultant-free. Apart from me and organizer Kulawat Wongsaroj and Kamon Treetampinij from Lean in Consulting there were almost no consultants. Nevertheless, the first training was sold out within a very short time and we had to set a second date because many managers wanted to know more about the Flight Levels. I think it’s best not to have more than 15 people in such intensive classes. Anyway, we also succeeded with once 18 and once 23. The fact that the Flight Levels went beyond the participants’ limits also had to do with my talk on business agility at the Agile Bangkok Meetup. 150 people were in the audience, but what I didn’t know was that more than 1000 more were watching my talk via the Facebook live stream!
Nearly tech-free. We have mainly focused on the Flight Level idea in rather non-technical areas: marketing for beauty products, medical supply management for hospitals, real estate development and wholesale of sexy underwear. An insurance company and a bank were also there.
C-leveled. Amazingly many representatives from the C-level found their way to the Flight Level classes in which they were exactly right. Many said after the training that they finally have something totally practical in their hands. In Kanban classes or in Scrum training you learn how to build and run boards – but especially top managers can’t do much with that. Their feedback was that thanks to the Flight Level training, they now know which boards are needed in the organization, how to connect these boards and who should coordinate with the systems. The trick is not to optimize the organizational structure, but to maximize value delivery to customers. We used three examples from completely different areas to see how this works in practice.
You can laugh – as loud as possible!
Who ever has the possibility to play the ship folding game or TWiG with a group of Thais, absolutely should do that. I rarely experience so much positive energy: people have bent over with loud laughter, discussion and explanation. Unfortunately I didn’t film it, it was a real highlight for me. According to all the feedback I got, TWiG was great fun for them, because it summarized everything they had learned during the two days. Thai people are really the best example of fun at learning and that’s why I’m very happy that I’ll be in Bangkok at least one more time this year.
TWiG 1.5 is done. The biggest highlight right away: The simulation is now available in 6 languages (English, French, German, Italian, Polish and Russian) and the seventh language (Spanish) is Work in Progress. Many thanks to the TWiG Community for your support!
In addition to the languages there are a few smaller and bigger changes like for example we change the WIP limit in the simulation and there’s a bit happening concerning metrics. I would recommend every TWiG user to switch to the new version.
I would like to thank all the people who are willing to contribute to TWiG and post their experiences and suggestions for improvement in our Slack Channel. THANK YOU! A special thank you also goes to the following people:
Florian Meyer for the TWiG Facilitator’s Guide – that’ s really a lot of work in it!
“Hooray, we have a board and we are doing standups. We are agile!”
That would be nice.
Many people still think of a board with colourful stickies when they think of agility. And it’s perfectly clear: Visualizing work and workflows on a board is basically a great thing and an important prerequisite for improvement. However, many “Hooray Agilists” still don’t understand that more brain fat is necessary in order to fully utilize the real benefits of agility. This is what happens in many companies: Every team has its own board and uses it to push and pull its tasks back and forth. In some cases even the management team has its own board and manages its tasks on it. If the management also has a board, some already interpret this as enterprise agility or business agility.
Two things are wrong here:
Waterfall 3.0: It’s great when many teams visualize their work. That’s a start. But you can also be totally unagile with lots of boards and visualization if nothing else is created but a waterfall 3.0. The analysts have their Kanban board, the developers have their sprintboard, the testers have their Kanban board. As before, tasks are simply passed on. The dependencies between the individual teams, let alone between operational and strategic levels, are completely ignored and not actively managed. In the best case scenario, a team always optimizes itself, but the company as a system of connected individual parts remains unaffected. In other words: It remains as little agile as before.
Administration of the existing: Management boards in particular are usually just a prettier to-do list. The tasks are processed well, but there is no change in the way HOW these tasks are processed. And it is also not considered whether the tasks are meaningful at all. Sometimes it gets even worse: The visualization makes constant re-prioritizing and working with high work in process much easier, and that can drive a company into agile madness.
The fact that there are certain artifacts like boards or standups does not make an organization agile. Boards of all kinds – Kanban, Scrum or anything else – can be used to perfectily manage existing dysfunctions.
This happens when the focus is not on “business agility” and instead the methods are worshiped as “agile”. Everything then revolves around how many columns and swimlanes a board may have and whether a stand-up should not last a second longer than 15 minutes. You can make great but completely useless retros if you don’t follow the findings or if you never check whether actions were successful.
Where means and ends are confused, agile transformation intentions usually fall into the trap.
You get what you’re optimizing for. Deming has already said, “Every system is perfectly designed to get the results it gets.” If we build a work system in which it is important that everyone is working at 100% capacity, then we will get exactly such a system. And now the important point: This does NOT mean that work is finished quickly!
If we want work systems in which work is finished quickly, we must – surprise, surprise – finish work. Therefore, the work in the system must be limited so that the focus shifts from starting to finishing. And now comes the disappointment for full utilization fetishists: That is not possible with 100% utilization!
When we make plans with 100% utilization we have to be aware that work is getting done slowly and that we will not meet deadlines.
Whenever agile methods are introduced into organizations, discussions about “prioritization meetings” revolve quite quickly. Replenishment, planning, grooming, blooming, zooming and whatever they’re all called. It must be made sure as soon as possible how new work gets into the system.
My experience says that the subject of “replenishment” can be initially neglected. I’ve never seen (and I use the words “never” and “always” very rarely) a system that wasn’t clogged at the beginning. It makes absolutely no sense to discuss replenishment until the clogged system is cleaned.
We need to shift the focus of prioritization: Priority must be given to which work is to be completed and not which is to be started.