Help! My Company is Stuck… (Part 1)

My coaching engagements often bring me to organizations well underway with an Agile transformation or have attempted, with little impact, an Agile transformation in the past. After a short time of observation, it becomes apparent some of these organizations are stuck between the old and the new…and the strong pull of the old provides easy opportunity for stubborn habits and behaviors to fortify their position.

Perhaps you have been experiencing this. Everyone says “We’re Agile!” but something doesn’t feel very agile. Ceremonies are followed and time boxes are in place but it still takes months before anything is released to customers. A complex and fragile architecture keeps maintenance high and quality low. While continuing to say they want to be “agile,” leaders continue to exhibit controlling leadership styles and their behavior limiting people from full engagement and restricting organizational health and innovation.

Your company is stuck…and this feeling of being stuck between two worlds can feel worse than what is being left behind. This is often when you hear the voice of the “I liked it better before.” crowd gaining volume.

If find your company with stalled transformational progress, here are a few situations to address and a few simple suggestions:

Hanging on to old artifacts. Status reports and resource capacity planning are a few coming to mind and I’m sure you can come up with a few more. Long, unneeded requirements documents or test strategy documents can also be prime suspects.

Ask why. Dig into why the old artifacts are still being requested and collectively discover ways to remove and purge. Guide people on a journey to discover new, lightweight ways to accommodate the needs of the original artifacts. As you know, its much easier to add process than remove them so fight to keep things simple and valuable.

Lingering defensive processes. Similarly, there is often a build-up of processes put in place over time to provide blame-free evidence when something goes wrong. This is on of the the reasons projects become lengthy and significantly reduces the efficiency gains from a transition to Agile. Numerous sign-offs and exhaustive governance approvals are often the culprits here.

Change the language. During a recent coaching assignment, a new agile team was finishing up their first sprint planning when a tester spoke up and said “My manager requires me to sign-off on our testing plan.” One of the other team members responded, “How about we all sign it? Quality is all of our responsibility and if something goes wrong we’ll all take responsibility.” This subtle shift from “me”, “my”, and “I” to “we”, “us”, and “our” begins to whittle away at the need for unneeded defensive steps. It was a powerful moment for this team.

Multi-month (or year) “projects.” While there may be a reason for the occasional lengthy project or release, many organizations (especially large ones) have made this the de facto approach to building and releasing products. If the number of sprints since the last release is in the double-digits, you probably have a problem.

Stop talking and start building. A recent tweet stated, “one prototype is worth a thousand decks.” So true. This excellent presentation from Leisa Reichelt  is worth viewing for an example of how the UK government has used Agile techniques to deliver new features quickly (and also learn about their customers). You can also leverage techniques such as story mapping to find smaller functional pieces to deliver.

Poor craftsmanship. In my opinion, nothing keeps a team or organization from experiencing optimal agility more than poor craftsmanship. When valuable time is spent fixing bugs or patching a fragile architecture, precious time and effort is focused inward, on our own needs, instead of outward, on the needs of our customers.

Use elements of XP (eXtreme Programming). Far too often, this is where I see organizations fail to invest the proper amount of time and money. Agile practices are implemented but the technical aptitude continues to be lacking, keeping the team and organization out of flow. Begin experimenting with and investing in techniques to drive technical excellence. Enterprise architecture can also help by intertwining your architectural vision and roadmap with the product vision and roadmap. This helps by implementing technical capabilities in advance of the needs of the product (instead of reacting with short-term solutions). 

Being “stuck” in a transformation can be frustrating but it is possible to build momentum again. In part 2, we’ll cover a few of the more challenging scenarios causing stagnation and diminished agility and what you can do about it.

References: eXtreme Programming (http://www.extremeprogramming.org/rules.html)

Join over 2,200 subscribers!

Get the book Becoming a Catalyst for free when you subscribe and be the first to know when a new post is published.

SUBSCRIBE!

You have successfully subscribed! Check your inbox for download instructions.