12 secrets of a successful Agile transformation – Part3

As promised here I am to complete the list of 12 tips for a successful transformation towards enterprise agility. In the previous posts (from last week and two weeks ago) we talked about the first 8:

1. Why?
2. The approach
3. Training managers
4. The pilot project
5. Scaling up
6. The Transition Team
7. Create the new roles
8. Cross-functional teams 

Let’s complete the list with the last 4 then:

9. Technical Excellence

Scrum is not enough! Scrum is a very powerful way of organizing work, but doesn’t say anything about how to practically do the work. Instead the biggest challenge for a waterfall organization is delivering a potentially shippable product increment in a short iteration. This implies finding new ways of doing things, applying state-of-the-art technical practices and build teams of professional developers, who are able to find the right solutions to always new problems.

Continuous attention to technical excellence and good design enhances agility. – 9^th Agile principle

10. Cultural change

It’s not about doing Agile: it’s about being Agile, by embracing Agile values and principles. This means primarily focusing on value, on what really makes your customer happy and not your boss or the boss of your boss. Prioritize your work based on the contribution it gives to the people actually paying for the product and not because “we have always done like that” or in order to make people busy: busyness is not a good business.

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. – 1^st Agile principle

Then let self-organizing teams to pull the work they are able to do. This is very much connected to why Agile. We’re in an industry with such high levels of complexity and uncertainty that we can no longer assume we can know or control everything goes on. So there’s no other way than building empowered individuals and teams who are able to take decisions autonomously using their best capabilities and judgments in the moment, respond to changes fast and reach a defined goal in the most efficient way.

The best architectures, requirements, and designs emerge from self-organizing teams. – 11^th Agile principle

11. Make your transformation self-sustainable

·         Build internal coaches who can teach and coach the new roles, support people to work as performing teams and be permanent change agents: if you’re really Agile, you’re never Agile enough.

·         Nurture Communities of Practice to give people a place where to meet colleagues who share the same passion or interest and learn from each other.

·         Adjust your HR processes (Performance management, career models, recruitment, reward and compensation) to support your transformation, instead of giving contradictory messages, and enable a collaborative environment of high level professionals.

12. Use an empirical approach

An Agile transformation is not a Change Program, you can plan upfront, set goals and KPIs, deploy it to the organization and track the progress. It simply doesn’t work like this. As you might have understood introducing Agile is complex: you’ve never done it before and you do not know exactly where you’re going, how can you define the steps to get there?

The answer is then to use Agile instead: yes, use Agile to introduce Agile.

So have a transition strategy and a transition backlog, but use an empirical, iterative and incremental approach.

Prototype and refine, make assumptions and validate them through baby steps, use fast feedback loops: it’s all about Continuous Improvement.

Of course using an empirical process control implies that you can observe your system to be able to inspect and adapt. Therefore enabling full transparency is a key success factor: make relevant information visible as much as possible from everybody to everybody to be able to really understand what’s going on and act accordingly.

Otherwise your transformation will degenerate into chaos.

So here are my summary on what it takes to have a successful Agile transformation.

Happy enough, my dear cheeky brother?

BTW, Happy Easter to everybody!

12 secrets of a successful Agile transformation – Part2

Following the blog post from last week, here is the continuation of the list of 12 tips for a successful transformation towards enterprise agility. We mentioned already the first 3:

1. Why?
2. The approach
3. Training managers 

Let’s move on with 5 more:

4. The pilot project

Since we’re talking about applying an empirical process, the starting point is to setup an experiment in terms of a pilot project. Scrum can help out with its framework to give some guidance and some practices which help understand the agile principles behind. A pilot project can provide objective information on the feasibility of rolling out Agile to all the organization. Craig Larman says that if an organization is not able to implement real Scrum with only one team, how can they succeed in scaling it in the whole enterprise? But be aware of choosing a proper pilot project. It needs to be important and critical enough so that people will consider it a serious try and a valuable success (it should be used to gain even more management support for the change), but not too critical to create a safe environment for possible failure. It should be end-to-end and therefore include all the stages that are needed to bring an idea into a product and it needs to be closely monitored and supported by senior management, ready to fix possible impediments.

5. Scaling up

Leveraging on the feedback from your pilot project and acting on the findings, you can start scaling up incrementally. This will allow better control and will enable the organization to build internal capabilities to help the teams that start later.

If you don’t know what you’re doing, don’t do it on a large scale – Tom Gilb

However beware not to be too slow, to avoid the organization finding them in the ford for too long and losing momentum, sense of urgency and a clear direction about the change to make.

6. The Transition Team

Creating a successful Agile organization does not simply mean make a number of Scrum teams work: it means creating all the conditions around to enable those teams to succeed and get astonishing results. The Transition Team is an operative team, with the goal of helping and supporting the organization in implementing the Agile Transformation, by supporting teams, removing organizational impediments, training and coaching people, spreading the Agile values and Lean thinking. The team works as an agile team, driven by the so-called Transition Backlog populated top-down by the organizational transformation strategy and bottom-up by impediments from the team.

7. Create the new roles

In order to scale up you need to build new skills and behaviors for people to fill the new roles of Scrum Master, Product Owner and Scrum Developer. This is best done by means of a mix of training, mentoring and coaching and is a typical item in the Transition backlog. Understanding that we’re talking about new roles, you cannot find in the existing organization, is a critical success factor. One of the worst (and yet easy and most common mistakes) is to create a mapping between existing and new roles, like System ArchitectàProduct Owner or Project ManageràScrum Master. They are totally different jobs and you need to realize this and prepare to help individuals who are willing to learn and challenge themselves to fill the gaps needed to move to the new roles.

8. Cross-functional teams

Cross-functional teams who can deliver potentially shippable product increments at each iteration are a key element in a successful Agile enterprise. So one needed step is to change your organization, remove functional silos and have self-organized teams of 5-9 people with all needed competences working together permanently. And this might imply changes in the office logistics as well, to create the right environment to enable team collaboration.

The most efficient and effective method of conveying information to and within a development  team is face-to-face conversation – 6^th Agile principle

It’s probably enough for today: any comment?

Let’s have a date for the next blog post to talk about the remaining secrets for a successful Agile transformation. 

12 secrets of a successful Agile transformation – Part1

Last week I was discussing with my brother, who works as chemical engineer and is now preparing to pass his exam for a Lean Six Sigma Green Belt Certification.

He’s studying mainly about Lean production and I was explaining him how Agile has its roots in the Lean principles and disciplines and how essential is Lean thinking and Lean management approach to support an Agile SW development.

My brother is a clever guy: so he understood very well that embracing Lean means much more than the mere application of a number of practices. So is for Agile SW development.

He’s maybe a little too clever to ask me something like: “You say that you’re an experienced Agile and Lean coach: so what do you think it is needed for an organization to really leverage on Agile and Lean to deliver quality products in an effective way? What do you think are the key ingredients to have a successful enterprise transformation?”

Cheeky enough, isn’t it?

But somehow he forced me to step back, reflect, gather my thoughts and summarize my experience and learning from the last 3 years.

Here comes then a list of 12 tips as outcome of that exercise, which I intend to share with you in a series of posts. I will start with the first three today:

1. Why?

Before exploring how to implement an enterprise transformation to an Agile organization, the first step is about asking yourself “Why?” What is the need behind? What is the goal you intend to achieve? There must be a clear need for any improvement change: imagine how crucial it is to start off such a dramatic change. The “Why?” must be clearly understood and the vision for the change communicated and shared to align the whole organization. Otherwise you’re doomed to fail even before starting (more about Why Agile? here)

2. The approach

Due to what we said above, it is easy to understand that any successful Agile transformation implies a top-down approach, in terms of Company values, Management culture, Vision, Business goals and above all senior management support: you cannot do anything otherwise. However, changing an organization (irrespective whether big or small) into being Agile is not like the nth Change Program to be deployed with targets to comply with and a well-defined plan to stick to. There are aspects that need to emerge bottom-up, like practices to be selected by empowered and self-organized teams. So an Agile transformation is a sandwich transformation: you need 2 equally big slices of bread and both are essential.

3. Training managers

Given the importance of the top-down part in the enterprise change, the very first step is training managers, for them to understand the why, be able to share and communicate the Vision, embrace Agile values and be ready to support people with a new leadership style. Many times this critical step is down prioritize, if not even neglected. It is too easy to fall into temptation that becoming an Agile organization means making Scrum teams work and that managers, well, they are clever enough that can handle themselves or can get it with a short summary from a developer attending a Scrum course: being a manager in an Agile organization is a totally different job and requires new tools which must be learnt and cannot be improvised.

How do you see yourself and your story compared to these three items?

Roadmap planning

As you might know, different levels of planning apply to an Agile SW development (actually, beyond what you can see in the picture, you have also the Sprint Planning and the Daily Planning).

It’s continuous planning with the different levels influencing each other by feedback both between levels and across levels in order to respond to changes. 

It’s a Rolling Wave Planning approach, where upfront planning is reduced to the minimum indispensable, to what is “just enough, just in time”.

As one can see, despite the myth about Agile meaning “coding with no planning”, there’s probably much more planning in Agile than in a waterfall approach.

In preparing for battle, I have always found that plans are useless but planning is indispensable.         

-Dwight D. Eisenhower

Last week we experimented a new way of Roadmap planning, aiming at understanding what will probably be contained in the coming releases.

So far this kind of planning had always been done mainly by the business guys, based on their level of understanding of customer requirements, their perception of the possible solutions and partly on wishful thinking.

This time we decided to do it differently, trying to take decisions or at least draw possible scenarios based on facts as much as possible. Once again the best recipe turned out to be a collaborative approach.

The decision was to call for a 4-hours workshop (it was actually 2 slots of 2 hours each) attended by the Product Managers, the Product Owner Team and a bunch of system architects.

The Product Managers brought to the workshop a list of prioritized requirements to analyze.

We decided to dedicate no more than a defined time-box to each requirement in priority order, so that we did not spend more time than strictly necessary at this very early stage of understanding.

The time-box was divided in 3 parts:

1.      1/3^rd to explain the requirement and clarify background and business value

2.      1/3^rd to sketch possible MMFs or epics

3.      1/3^rd to estimate the MMF or epics, a relative estimation using as a baseline the actual story points spent by our teams to deliver the MMFs in the last 2 releases

Everything was done collectively. After the workshop, given the number of sprints contained in the coming releases, the PO team did a date first planning, by considering the actual velocity statistics of our organization.

Based on that, we determined scope scenarios for the coming releases, considering the worst and the best cases in our recent history.

The feedback from participants and stakeholders both on the approach and the outcome was pretty good and I must say it looks very promising to me as an Agile coach.

At least it meant providing “just enough, just in time” information (even if rough) based on the current knowledge and understanding of requirements and above all on real data coming from our actual historical performances.