Mind over Matter - The challenges of Leading the transition in LEAN, Agile, Design Thinking

Mind over Matter – The challenges of Leading the transition in LEAN, Agile, Design Thinking

A recent survey of 28 executives and leading managers shows that many organizations which have set out to benefit from the autonomous delivery and execution methods, like LEAN CI/PDCA, Agile and Design Thinking, are still struggling with creating the proper environment and culture, especially in the area of empowerment, but also in true implementation and execution of the principles which make these methods what they are: rapid go-to-market solutions based on autonomous exploring of opportunities and the most efficient execution. Proven small steps over designed complete packages. Efficient flexible work cells over rigid complex production lines. Many tested prototypes over a single tested end-product.

Organizations struggle at various levels with creating the right culture to let go of the classical models and systems, and that struggle in most cases starts at the top. There are still organizations with LEAN managers at local plant level, which continue to determine the LEAN projects and structures at centralized corporate level, instead of allowing the Small Group Activities and CI/PDCA process to maximize the benefits of the plants for the plants. There are organizations with Agile declarations which still have top-down roadmaps set at executive level with fixed scope and timeline, without enabling the responsible teams to explore benefits and best implementation. There even are organizations which proudly use Design Thinking in their internal and external communication, without even putting a single prototype out there.

Executing fixed-scope projects with Agile is akin to rearranging the deck furniture on the Titanic… creates a great sense of security and order but we know how it all ends. It also makes it harder to ever change that organization’s mindset, as the leadership has now appropriated a nice Agile badge while sustaining the old belief system – a really bad combination. – Alex Yakyma

Setting a fixed scope and timeline for LEAN PDCA, Design Thinking or Agile development is like driving on the highway until you have to stop for gas. You will eventually reach your destination but have missed out on all the opportunities along the way. On the other hand, using those autonomous delivery and execution methods when scope and timeline are fixed is like hitchhiking 2.000 km across Europe when you have a fixed appointment that same day. You might eventually arrive at your destination but you will never make it on time.

Empowerment and Accountability are the main enablers to achieve top performance in autonomous execution settings. Without proper empowerment combined with accountable teams and managers, none of the benefits of autonomous execution and delivery will materialize. In the same manner, applying autonomous execution methods only makes sense when there is the opportunity of focusing on delivering short cycle improvements, mitigating one pain point at a time, versus delivering mandatory deliverables prior to a given deadline, e.g. due to legislation or licensing requirements. When, and only when, empowerment and accountability are established throughout the organization, autonomous execution can provide significant benefits for the subtasks below the main objective even with a set outcome and deadline.

Leadership tends to underestimate the required investment in trust from all involved, starting with Leadership itself, during the transition. Creating a culture where failure is seen as experiences from which the team learns and improves with the findings, is a challenge when working against a fixed timeline and scope. Even more so when this culture is not actively cultivated by the leadership itself. As long as deadlines are the main objective, none of the efforts will pay off and being Agile, or LEAN or Design Thinking becomes reduced to a badge for marketing and recruiting purposes.

The journey of Agile and Design Thinking business models is easy to explain but difficult to accept for those who are used to drive business against fixed objectives. It is a matter of ‘we wanted to go to the zoo but it started to rain and we learned that a storm was coming so we decided to turn around and watch a documentary about wildlife.’ versus ‘we wanted to go to the zoo, it started to rain and a storm was coming so the zoo was closed, but at least we arrived at the zoo on time.’ The first is Agile, the second stuck with the plan. – Unknown

Those Executives who have successfully managed the transition into autonomous execution and delivery, including myself, all agree that the biggest challenge was to change their own mindset towards executing and monitoring projects. “Letting go” of all conventional controls is difficult when these conventional controls have been the method of managing. Trusting a team to come up with the best business benefits isn’t easy when setting the expectations of business benefits has always been part of the role.

It gets even more complicated when hybrids of conventional and autonomous methods are required. As Wulf Ehlers once stated, designing and implementing a safety control system with the conventional methods to obtain a license to operate, and at the same time letting the team design the HMI in iterative sprints to get the best solution for the operators and supervisors, is a tough balancing act. Not just for the responsible executive, even more so for the team members involved. One day going through detailed design papers for the safety controls prior to the actual implementation, the next day freethinking with prototypes and concept papers. Wulf called it “holding on while letting go” and being his service provider at that time, I can only confirm that it was a tough challenge for all of us!

My own learning moment of “letting go” with autonomous execution is long ago but I still use it as reference for others and as reminder for myself. Coming from a conventional “specify, design, implement, test, deploy” setting, I got infected by the autonomous execution “virus” and hired an ambitious scrum master candidate. During his first week at the job, we had a team meeting about my plan to make our solutions fully configurable to enable us to sign up service partners abroad in the next year. In my thinking we would generate significant business benefits when third parties would be able to install and manage our solutions. Bigger installed base of our solutions and less resource constraints during the rollouts. Such kickoffs of new plans and features were part of our business culture and in the next phase, a solution architect would start specifying the requirements.

Not this time. The young ambitious scrum master suggested to stop right there and take the business benefit as project goal “Enable signing up third party service partners to achieve faster rollouts with less resources”. On the one hand, I thought this was a good idea and that was just what I hired this talented guy for. On the other hand, the thought of not going to the technical specification cycle worried me. A lot! But I decided to go with it, convinced that I could interrupt this trial when things would not be going according to my expectations.

We had a workshop, brainstorming about the plan and how we could accomplish that. Some really great ideas, a lot of thoughts we had to take a closer look at. Pain points were identified. Benefits of this versus that were discussed. There was even the suggestion to write an epic for the first step and assign that to the first available sprints. But no specification for the whole solution based on which we could create a design for the whole solution. I already read the book and even wend to training, so I understood that this was basically the way it was supposed to be but I also ran a very successful software company that was very successful by doing things “the old way”.

Other members of my management team started to express my concerns in their own words. “This is not the way we do things here” and the CTO called me in the middle of the night just to check if this kept me awake as much as it did him. It did. Many nights I decided to put an end to this but the following day, the progress and energy, the motivation and results provided by the scrum master and his dynamic team convinced me to give it another try. “I will see how this goes for another month” was most of the time my explanation to my management team and after a few months, it became less of a problem in my mind and it became less difficult to convince the others that this was the way to go. But there were still a lot of doubts, including with myself.

Things got really cooking when the team invited the management team for a presentation. First slide: the goal “Enable signing up third party service partners to achieve faster rollouts with less resources”. Second slide: A list of identified tasks for now, and making our solution fully configurable was just one of them. Third slide: an overview of the completed tasks by now, the learnings from that, and priorities for the upcoming tasks. Forth slide: a bold statement that we could now sign up third party service providers and have them install and manage certain parts of our solutions with our support at 70% less effort from our side compared to when we would do it ourselves. Presentation off, live demo on! We left the meeting room thrilled and I had to suppress a couple of “I told you so” comments.

Two months later, the team was able to add more components to manageable solution suit and further reduced the effort we would have to invest when working with a third party service provider. The list of completed tasks was extended but the total list of task had also increased. How could that happen? Now my biggest learning came and after the first joy of success, I wasn’t ready for this. The team had analyzed the results which each iteration, prototype and release, and found several unforeseen issues. Important learnings but they extended the scope, and the timeline! Were these really necessary? Could we not move faster? Would this have happened with the conventional model?

The moment I asked myself this question, I realized how important answering this question was and I decided to do this with the entire team. We were now 6 months into the project. In our conventional model, we would by now have a final draft of the technical design. Paperwork based on our knowledge of our solution and the processes for its implementation. We would review this design intensively, maybe identify some required modifications and after final approval start with the development. By the time we would have developed the components, intensive testing would start, some modifications would be needed, more testing done and eventually, we would gradually deploy the latest greatest version of our new features. This would have taken at least another 6 months, maybe even 7 or 8 with the upcoming holiday season decreasing our capacity.

The team under the guidance of the scum master had flipped this model upside down. Pain points were identified. What is standing in our way to achieve our goal? What is complicated and what is relatively easy to achieve? Are we sure we need this? Can we break that complicated hurdle down in steps we can handle? And most of all, can we test this as soon as possible? 6 months into the game, we had a bunch of steps towards our end goal out there. Working! We could already work with external parties at significantly lower effort from our side. We continued to add components to the manageable suit. And we did that step-by-step. Drops versus waterfall in the best practical context.

OK, so the scope was extended and the timeline also shifted for the final goal. The benefits however came in significantly faster. In our conventional model, we have invested at least another 6 months before we could achieve any benefits and now we were already reaping significant benefits although we hadn’t even finished. That is my learning from letting go of the conventional models. That we could already achieve benefits during the process and not only afterwards. And that I had I hard time accepting this and keeping my team and myself motivated enough to believe in this. But my biggest learning from this experience are all the restless nights in which I had already decided to end this and finding motivation and inspiration the next day to “give it another try”.

It took courage. And truly established empowerment and accountability. And more emotional competence from all of us than I was able to identify at that moment!