A Lean manager is not a coach!

Or is not only a coach.

Or, even better, is not primarily a coach.

Many times I heard people saying that traditional management style do not apply in an Agile and Lean context and therefore it must be replaced by coaching as THE way to help people develop.

I think this is wrong or at least shows a narrow, easy and fluffy view of what a manager is supposed to do for an organization in the 21^st century who wants to run its operation inspired by Lean thinking.

But let’s have a look at the different Lean disciplines one by one and try to understand better what is the essential contribution needed from you as a manager.

1. Eliminate waste

First step to eliminate waste is to see the waste. So you should know (and know very well) the Value Stream of the product(s) you’re working with and continuously challenge the current practice to identify waste. 

But this is not enough: a Lean manager should help teams remove impediments they are not able to resolve by themselves and systemize solutions in the organizations to prevent the same impediment from coming back again (see more about this in my previous post 3 things we can learn from TPS)

2. Build quality in

This means for a manager working to build a culture of discipline and excellence, that is guide on principles and values instead of giving complex rules, teach people not to cut corners, challenge people to high performance and lead by example. And yes, that implies true leadership.

3. Amplify learning

Most managers face competition with other managers trying to meet locally optimized goals and maybe look good to the next level up. But this wastes a lot of organizational learning, which can be effectively used by pairing up with peers. So building and maintaining a network of peers is essential as well as continuously challenge own management style in the light of Agile and Lean principles (see also Cultural transformation through deliberate practice of behaviors). But amplifying learning also means:

·         concretely encouraging experiments, fast feedback loops and safe/fast failure

·         providing and being open to feedback

·         striving for a radical transparency (as Steve Denning calls it) as the unique way to control the complex system your organization represents

4. Defer commitment

Keep your options open up to the last responsible moment and be capable to live with uncertainty: there’s no other way around (have a look here). Furthermore early commitment could mean discard too early real options which might have provided more value, just not to afford the cost of deferring a decision.

5. Deliver as fast as possible

The fastest way of achieving a goal is to let a diverse team of skilled people self-organize to better judge how to solve the problem. And the best way to have them self-organize is to define what the goal is, make it compelling and clarify what constraint the environment around puts to the direction. Then if you want to help your team or organization to deliver as fast as possible, set a clear vision, explain clearly where to go and why, align all stakeholders around that vision and get fast feedback. Then set specific goals derived from the vision: in that sense you’re the PO of your organization, so write a backlog of stories aligned with what you think is the ultimate goal to reach. And finally give space to your teams to reflect on what they are doing to find ways how to go even faster.

If you're not a front line engineer, there's only one reason for you to exist: help your team move faster - Jan Bosch

6. Respect people

Who dare disagree with this? Actually this apparently generic statement hides a deeper meaning. It stands for: give people the environment and support they need to do a great job and trust they will do their best to accomplish their goal. So it’s not simply saying to a team: Now you’re empowered to do what you want, but putting them into the conditions to succeed. So it’s about staying close to the teams, Managing By Walking Around and Listening (MBWAL instead of MBSR – Managing By Status Report), energizing people around you, assisting on personal development. And yes: that might be teaching, mentoring and coaching as well.

7. Optimize the whole

Optimizing the whole means having an e2e view of your system, product or organization and consequently as a manager selecting the right metrics which can help you improve, measures only what adds value (less is more) and whatever you want to measure, measure it one level up.

Of course, being a Lean manager does not mean taking decisions your team would be able to take themselves, asking for reviews and reports or pushing activities on your people.

On the other hand coaching is all about the coachee agenda, but improving theValue Stream, build the organizational culture, set the direction or define proper metrics cannot be other than about your agenda as a manager.

So were you one of those who thought that managing an Agile and Lean organization meant just coaching?   

What’s your thinking now?

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?