Foster transparency, Inspect results and adapt from what you've learned over and over ...
Efficient vs. Effective
The idea of lean is to remove as much waste as we can from the value chain. Anything not needed to create customer value.
In purely top to bottom managed organisations, most departments created a wall of processes overhead, that almost functions as a defense system (but against their own kind). This is just one symptom of the systemic problem, which is the speed and lack of interaction.
Looking at the outside influnences, we all know about the ever-decreasing duration of innovation cycles in today’s competition. This speed forces us to rethink the way we release products to the market. In larger scale software driven businesses e.g., release management classically will have gates, in which new software products can be released. If a department or an entity misses a gate, it will have to wait for the next one to release the product. These gates of several months, half a year or annually, do not really go well with the business side having to be way faster than that.
Another issue widely underestimated in release management is that inside many businesses, development and operations departments are different entities. Because there is very close interaction needed to orchestrate the flow between artifacts to be released and the platforms they are supposed to run on, the communication gap between them is one of the drivers for noncompetitive long term release management.
Agile methods and framework were designed as a consequence of, amongst others, observing matters mentioned above in software industries. But frameworks like XP and Scrum serve the purpose of covering mainly a software develoment process. They effectivly do not include everything else in your organisation and can therefore be considered a local-only optimation. This will at best cover your production. Since we know that systems are as fast as the slowest entity (bottleneck), one faster part won't give you ad value, because it will get slown down by other slower parts.
There is a lot of buzz about scaling agile in recent years and frameworks like SAFE and NEXUS promisse to succesfully tackle that problem. How ever and what ever you think is the right approach, you need to look at your system as a whole and get out of the local optimization trap.
So, we see all those efforts to scale agility on production level across the organisation. Coming back to Scrum for instance, Scrum is a taylored model with specific roles. They often don't make any sense outside of software develoment teams. Scrum further more uses management by exception and so called impediments. When the teams cannot solve them internally, they are being exposed to the organisation. Often times though, this just becomes another term for the same process of escalation managment in waterfall classic environments and is doomed to failure more to often.
Filling the gap
From idea to impact
So where do we draw the line between agility and business agility. To make it simple, agility happens on your production level, while business agility wants to visualize the intire value chain of your business, end to end.
Stop starting, start finishing
One way of doing so is to use the Kaban. Kanban is a method by David Anderson's which he started developing in the early 2000 at his time with microsoft. It is based on the Toyota Production System and other influences. Today it's a combination of an ever evolving toolbox of practices with scientific measures. More and more Companies use this holistic visualisation and flow management method to run their entire business. The transparency gain of this method is widely documented and the approach has long moved beyond the early stages of its development and being a software development method. One of the reason for that, lies in the fact that Kanban respects and doesn'r initialy change existing roles and processes. It's not revolutionary, ist evolutionary.
The way we learn and get successfull at anything we do, is repetition. Failure is part of the repetetive leaning cycle. In this cycle we adapt to new knolledge which uccured in the process. Trail and error. In most companies still today, people are educated not make those mistakes necessary to evolve. This often rediates into anything that the organisation offers to the market. Organisations that condemn failure or foster a culture of hinding those, for example, by paying bonus for reaching local objectives and creating a systems inner competiting organism, habe a hard time engaging in managing their value chain as a whole.
Fail fast, fail early!
Organisations need to foster a culture of failing. First of all, this takes out the drama of the event. It just happens all the time. So what, you get up and do it again. Jsut like when we learned walking. We shure wouldn't have, if our parental management at the time would have moved our feed with their hands. We simply watched and copied until we mastered the task. After that, we build more skills on these base skills.
Some CEO's tell their management, that if they hadn't failed recently, they hadn't tried hard enough
Learning in the beginning and failing early will give you the opportunity to introduce measures not to make the same mistakes again. Of course, opposed to classic waterfall, in which you expose the result to the client in the end at one point in time. The risk of non-user-acceptance with this strategy is what you can whitness in many many organisation in the form of the occuring endless change request battles.
To stay competitive in IT for instance, companies need to automate workflows between development and operations. In an ideal world, that product can be rolled out almost instantly. In IT, the tight integration between those two departments is what is being refered as DEVOPS. Devops movement became a crucial investment to organisations in recent years, as it opens the door, or in other words enanbles a time2market competitive state of product delivery.
That being said, in most anything that gets produced, the end of the chain (may it be assembly in automobile or deployment in software and systems) is the most common bottleneck in organisations flow. If you can even name it flow.
Mastering the challenge is beginning the journey
All in all, it takes some experience in the classical and agile world to see and foresee all the obstacles on the path to become a more agile organisation, the way some of the global "newer" player already are. With my experience and advisory, I can help you find a way to master the challenge.