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.

The importance of working with requirements

Two weeks ago (and the week before) I held a couple of sessions of Product Owner training in Sweden. 

As you know, I’m particularly interested in Product Ownership, being such a critical (and often underestimated) activity for the success of an Agile organization.

Anyway, regardless of this, every time I facilitate a PO training, one of the most interesting discussions happens around the subject of requirements. And the reason is that even experienced analysts or system engineers are sometimes not used to work with requirements properly.

The first important concept, which looks straightforward and totally sensible, but happens to be pretty hard to apply, is that a requirement is expression of a need, not a specification to implement.

It is an item in the space of problems: it is a problem to solve, not a function to deliver. 

On the other hand developing SW is just about solving problems, not writing code, right?

For instance, if one says: I want a bridge, is this a requirement? Is it a problem to solve or a solution?

A right conversation would then be: 

- What is the need behind this request?

- I want to cross a river without getting wet.

Eureka! This is a requirement and, as you might guess, this opens up more than one option to find a proper solution. One solution is definitely the bridge, other solutions could be a boat or a raft or even swimming. And you don’t even need to build anything in the latter case.

This is a very important job: understanding the real need behind a customer request. That’s why we don’t say writing requirements or defining requirements, but eliciting requirements, because it is about digging out real problems and helping the customer understanding her real need (or at least making a hypothesis on the real need, which must be validated through a fast feedback loop).

Then you as PO use your brain, your skills, your domain knowledge and the brains in your team to translate the need in business solutions, you can write in forms of User Stories, which is the language you speak with your team.

Requirements are instead the language the Product Owner speaks with customers, but it would be too easy and not profitable downloading the requests on the team as they are. Challenging customer needs is a very crucial activity for a Product Owner to be able to find a solution compatible with business and maximize the Return on Investment. 

I repeat many times to my PO team: your job is not to push your team to do as much as possible – your job is to challenge requirements, so that your team can do as little as possible.

Cutting some scope because it is not needed has an effect that no efficiency program whatsoever can ever beat: effectiveness eats efficiency at breakfast every morning.

Unfortunately I saw too many times the pattern of jumping directly into solution mode as soon as a request arrives and business solutions masked as requirements.

Buddhist masters know that, if you spend enough time in finding and formulating the proper question, the question itself will contain the answer. But how do you feel is the ratio between the time spent on defining the problem and the time spent on the solution in your context?

5 things you should know about Organizational Coaching

Some days ago I was having a coffee with one of my colleagues.

While answering to his request of feedback about his work as a Scrum Master, we ended up in talking about what organizational coaching means in practical terms, what it is really and what it takes to be effective.

I cannot report the whole interesting discussion, but here are some takeaways as summary for you: 5 things you should definitely take into account, if you want to become an organization coach.

1. Use a system approach

An organization is a complex network of people, who are complex beings. If you really want to leverage on all potentials to affect it, either to make it better or simply to help your team, you must look at it as a whole system. Try to sketch a strategy of the possible options you have ahead, possible impediments and way to overcome them to reach your goal: you might realize that a single isolated step is not enough, but you need to take many steps, in order to get any progress.

2. Know your organization

Try to understand your organization very well. Learn not only about the official and visible structure. Learn much more about the invisible networks, the inner relationships among people, who is friend of whom, who is most sensitive to certain subjects and who counts more or is more decisive on certain tables, whether he has a formal power or only a subtle influential leadership. You cannot imagine what competitive advantage this will give to your effectiveness.

3. Act on different levels

Challenge the status quo and don’t limit yourself to the most obvious actions. Prefer actions who affect the environment around or the process to do things, instead of addressing directly a specific problem: they will have more and lasting impact.

Talk to people, with a preference for informal chats - coffee machines are a perfect place sometimes :). Try to find initiators and innovators to help you and sponsors to support you in difficult situations. And, whatever level you want to affect, consider acting also one level up.

4. Understand the effect of your actions

Before taking any steps in your strategy, try to guess which effect it will have in relation to your goal. Make a hypothesis and try to validate it as quick as possible. Find even people who to share your thoughts to and get feedback. The sooner you know if your strategy can work well or not, the better it is: you will then be able to adjust it if necessary and speed up the achievement of your goal.

5. Try things out

Finally organizational coaching is not mathematics and the system to act upon is many times far too complex to draft a strategy since the beginning, indentify any viable action or understand the effects of possible actions. That’s why sometimes you must simply try things out. And that's not wrong, stated that you try to fail fast and reflect on what you learned to find a different path.

That’s my experience. What did you learn in yours?

Daily Scrum or not Daily Scrum, that is the question!

A couple of weeks ago, back from Christmas vacation, I had an interesting view exchange with some Scrum Masters about what to do when the team is not motivated to have the Daily Standup. 

What I experienced is that, when the team argue the value of the Daily Scrum, most time it's because they misunderstood it.

Credit: Playmakers! Theatre School

They normally say: Why do we need a meeting to share what we're doing if we're sitting together all the time and know it already?
I would say that, from this perspective, they are totally right!

The point is that the Daily Scrum is not for the sake of sharing, but it has a totally different goal: stand back for 15 minutes and collectively assess where we are compared to our Sprint goal and collaboratively decide what is the next most important task each team member have to complete to move forward towards our goal.

So what I did in those case is to re-discuss with the team what is the real purpose of the Daily standup. That normally worked! I prefer to call the Daily Scrum as Daily Planning to make the real purpose more clear.

If that didn't work, I would name this as a good chance for the Scrum Master to wear his/her teacher hat and re-affirm the fact that the Daily Standup is a fundamental part of Scrum.

Here the Shu-Ha-Ri metaphor works perfectly.

BTW, are you familiar with martial arts?

If yes, you might know the Japanese concept of the 3 levels a martial artist goes through on his way to get mastery in his discipline.

In the first place, the Shu student goes to the master and simply observes and replicates the master's moves, even if he doesn't fully understand the concepts behind.

When he becomes a Ha, he starts to understand the principles behind the moves well enough that he can stop imitating the master rigidly and start trying different moves.

Finally, when he reaches the Ri state, he finally becomes a master himself: he has understood the principles of the discipline so well that he can shape new moves himself to adapt to new situations and can teach others.

So, it's essential for the Scrum Master to openly share with the team his/her feedback/advice that, since they're probably still in the initial (Shu) phase of the learning curve towards Agile, they'd better follow the practices suggested by Scrum and give them a try for a certain amount of period, even though they do not understand them completely. 

When they fully understand the underlying Agile principles, they can dare and break the rules.

A good compromise here is to suggest to keep the Daily Scrum and stand-up anyway at the agreed time: if they are happy about the daily planning for every team member and do not have anything to add, they can sit down after 1 minute. 

You will see they normally take the whole 15 minutes instead 

A final option could be a healthy safe failure approach, which normally works with kids as well as with teams