How is your Agile transformation journey going?

Did we question ourselves how/why the Agile transformation in our Company started? What was the main trigger point for the change? Did we raise a Business Case before “moving to Agile” ? I have rarely seen it.

Why?

Short answer: we take the return of investment for granted. Most Companies adopt agile successfully. Why should we not ?

It’s very common the IT teams get very excited on Agile because the work is funnier, the collaboration with people is more effective , the team feel empowered to make decisions and job is easier when complex problems are broken down into simple ones. Right!

And many software developers I met raised the point:

why Agile was not “formalized” earlier in the age, when the software discipline was born? This is indeed the right way to work!

Good question, it deserves a dedicated post!

But I have noticed that the excitement from IT peeps is not always reciprocated by the Business people. The most common concerns are related to:

1. Not being able to set clear expectations, in absence of medium-long term planning.
2. Harder work on budgeting and forecasting, without knowing the total cost to deliver a programme or project of work.
3. The perception to burn money quicker, without going faster.

Fair questions, which can be answered assuming our audience is open to understand what shift of mindset an agile transformation entail.

It’s not about standing cross-functional teams and it’s done. Main challenge for any Agile Champion is to support all functions in the Organisation on transforming their way of working by providing assistance on their daily job and during any major transition.

Planning and Budgeting will never cease to exist, it’s about doing it in a different way!

I know managing the reluctance of people in the Organisation can be painful and it sucks our time. However, it’s a point to not underestimate and worth spending time with who doesn’t believe on it, who doesn’t see the benefit.

In a similar way we measure the satisfaction of our customers with NPS, it’s fundamentally important to get as many promoters as possible.

It will be 10 times more difficult to implement a successful transformation if we are dealing with passive people or detractors.

The main point is to understand what it matters for them and how “Agile” changes can have a positive impact on their objectives.

Another key element for our transformation is to decide which one is our target delivery model, where do we want eventually to land and how do we get there. It’s essential to plan our journey and to be aware it will take us time and probably few intermediate stops, in a right or often wrong place!

Failure is part of the leaning process. Understanding the complexity of our journey can save us a lot of time and money.

From my experience, a typical evolution journey has 4 stages. I’m not expecting this to be valid and applicable for all Companies but I see this as a recurring pattern.

Evolution pattern to the target Agile model.

• First harbor is the “break with thee past!”. I have seen people becoming “Project Allergic”. Allergic to any project life-cycle, project meeting, project planning, project documentation, even Project Managers. As reaction Project Managers appointed Scum Masters but overall reluctance to follow any old practice. All never actually stated or “banned” in the Agile Manifesto!

Individuals and interactions over processes and tools doesn’t mean no processes. Responding to change over following a plan doesn’t mean not having a plan.

• At some point, the Company might realize the current agile basic model is not enough structured, not much controllable, non-scalable, not manageable for bigger changes and multiple products and stakeholders. It’s the moment to look at an agile scaled framework. Which one and how to implement it? A standard solution or building a new one ad-hoc? A meaty topic for a new post.
• After having experienced the “cost” of introducing a more complex model and processes (again!), our Company is now likely in the condition to find the best compromise between a simple basic agile model (e.g Scrum, Kanban), a scaled basic one(e.g Scrum of Scrum) and a scaled framework (e.g SAFe, LeSS).

The best model is what realizes “your” objectives, not what is good for the majority of the cases!

Hope this article has inspires some thoughts.

Please share your experience in the comments!