State of Scrum 2017-2018: the future is Agile!

At the beginning of new year, Scrum Alliance, the largest certifying body in the Agile community, released State of Scrum 2017-2018, an annual report which summarizes Scrum and Agile practices and predictions around the world.

More than 2,000 Scrum professionals responded to the survey, representing 91 countries and 27 industries and the report this year shows Agile transformation firmly on the horizon for organizations all over the world.

Approximately half of respondents – 53 percent – report current involvement in an Agile transformation, and of those not currently involved in an organization-wide Agile transformation, 56 percent anticipate one in the future, which is not surprising.

Other key findings from the 2017-2018 report include:

• 97 percent will continue to use Scrum in the future. 
• 85 percent say Scrum continues to improve quality of work life.
• ScrumMaster is the most popular certification, selected by 84 percent of respondents.
• 78 percent use “Scrum and Other” approaches to Agile, and the diversity of frameworks increased from the previous year. 

Active senior management sponsorship and support is the number one motivator to undertake an Agile transformation, and enterprises look to executive leadership to spearhead Agile initiatives.

While many respondents anticipate change to come and suggest it is necessary to reach business goals including improved satisfaction with products delivered, better time to market, better quality and improved staff morale, 57 percent say organizational design and culture is what holds Agile transformation back.

This definitely resonates with my personal experience in coaching and transitioning enterprise departments: company culture can make or break an agile transition.
Yet few transitioning organizations do anything much to purposefully change their culture.
Culture is seen as fluffy and intangible, and changing it is risky. Having dozens of Scrum teams is very tangible and an easy KPI, but distributing authority to teams is a bit scary and also difficult to measure.
My experience tells me that this perspective is due to a lack of knowledge about:

1. what culture is
2. the strong impact it has on behavior
3. how you make it visible 
4. how you change it.

For instance most leaders say that their biggest problem is knowing and understanding what is happening on the factory floor. Yet very few leaders and few companies spend effort on actually observing people and their interactions.

If you want to talk and learn more about any of these four topics, I will be happy to help.

To learn more about Scrum Alliance and the State of Scrum, please visit http://info.scrumalliance.org/State-of-Scrum-2017-18.html

The 21st century´s paradigm to connect people and work to be done

Few days ago I had a phone call with a friend of mine. During our conversation she shared with me one of the challenges she is facing at work and wanted to check what I might think about.

Basically they have few issues when it comes to allocating people to work on a project they sold to a customer.

The challenges are multi-faceted:     

• Finding people with the competences which fit that specific project
• Finding people who are available to work on that project
• Finding people who are willing to work on that specific project

Now the sweet point would be: a reasonable amount of people with the right competences, who are available at that time and willing to take on the project.

Very hard! Almost impossible! So what is usually the second best option?
Right! Put together on the project just who is available at that moment in time and hope it will not turn out too bad until someone with the right expertise can join and save the boat.

Does it sound familiar? I am sure it does, if we live in the same world.

But I have a second question: any guess what my friend’s job is?

Well, if you are thinking about anything among Project Manager, Development Manager or SW developer, you got it wrong. 
She is an architect: not a SW architect, a “real” architect.

If the fact that an architecture office might have similar problems to any product development company sounds unexpected to you, you have not considered the fact that the nature of the work is substantially the same in both fields: solving new problems which have undefined boundaries and multiple possible solutions within a complex environment where multiple entities influence each other in unpredictable ways.

To me this is just another confirmation of a pattern that I have seen in all organizations coping with work of such a nature and trying to apply traditional patterns to solve this challenge in the current century.

Can the situation be slightly improved by applying those patterns more efficiently? Probably yes and the PMI might have few ideas around that.

However my experience tells me that the problem cannot be solved if we do not embrace the fact that a totally different paradigm is needed.

Why?

• Customer requests are more and more unclear: they do not know what they want. Problems are wicked: there is no pre-defined answer
• Market is becoming more volatile: new and unexpected needs are emerging which require flexibility in companies
• Professions are more and more specialized. Too many individuals I-shaped skills, which means they have deep knowledge and experience in just one area
• Work is done in silos: lack of holistic view by individuals, but also knowledge domain in many professions is so big that is impossible for a single person to know-it-all
• Having parallel projects competing for human resources is not sustainable anymore in the above context
• Having people working on multiple projects reduces their effectiveness and productivity: context switching makes people waste time and produces stress, which can reduce IQ by 20%

So what is this different paradigm all about?

• Understand the flow of value you create and setup stable, 100% focused, self-organized teams with a shared goal around your value flow
• Bring highest value work to teams instead of allocating (or multi-allocating) people to work
• Having the team as the atomic element simplifies allocation very much
• Focusing on getting the most important thing out as fast as possible instead of focusing on making people busy (flow efficiency over resource efficiency)
• Teams must be cross-functional: they must have all the competence needed to get work done
• The holistic view of the work is kept at team level
• It is too much to know for a single person. Individuals should better be  “learn-it-all”*
• They can act more effectively on new wicked problems to solve: diversity beats expertise in complex domains
• Move from I-shaped individuals to T-shaped or even X-shaped professional who can do more things, so that you can have smaller teams with all needed competences
• This can be partly achieved through synergies in teams, but also having the expert teaching to the others, to reduce the bus factor

Dare to take the journey? Do you have enough courage to address your own problems?

*In her book “Mindset”, Carol Dweck talks about the following concept: if you take two people, one of them is a learn-it-all and the other one is a know-it-all, the learn-it-all will always trump the know-it-all in the long run. See also what Microsoft CEO Satya Nadella said in an interview last year about his effort to overhaul the company culture.

A conversation with the CIO community

Leadership quote by photosteve01 / CC BY 2.0

Last June I had the pleasure to get my interview published on Netweek, the biggest magazine for the Greek CIO Community (the Greek IT Managers are both readers and editors). 

I am thankful to George Fetokakis, Editor-In-Chief of Netweek to make it possible and for the interesting questions.

Since I realized that the interview was only published in Greek, I decided to post it here in English and share it with a bigger community.

Trust you will find value in it.

Looking forward to your feedback and comments.

1. How did you get started in the Agile world?

Interesting enough, I actually started my Agile journey in Greece. At the end of 2009 I got the chance to be part of kicking-off the Agile transformation in a big development organization of around 2000 people. So I got to spend 3 months in Patras, together with other 18 apprentice coaches from all over the world and 9 consultants among the most knowledgeable Agile coaches and trainers at that time. Every single day of those 3 months was an incredible learning experience and that still remains the most exciting and fun period in my professional career. Which better place to start a life-changing journey than the place which gave birth to the Western culture?

2. What does success mean for you in this world? 

In my opinion success in this context for a company or an organization means: effectively leveraging on Agile values and principles to achieve your specific goal sustainably in the fast changing world we are called to live right now.

For a development team success means delighting your customer with products that actually solve their problems. For me personally success means contributing to transforming our world of work in something more meaningful for human beings.

3. What are the top skills that an effective Agile coach should have?

The two coaching skills which helped me most in my 7-year experience as Agile coach are: empathy and situational awareness. Empathy is a crucial skill for coaches and leaders.

I learned that people want to feel themselves valued and appreciate when someone is truly listening and not judgmental. This doesn´t come easy: it is a skill to practice to be able to listen for potential, namely listening to people not for what they are, but for what they can become in the future and be committed to help them become the best they can be.

With situational awareness I mean the ability to be really present, observe carefully and understand what is going on around you: the ability of “reading the room” or “smelling the room” beyond what is said.

4. How Agile (and Scrum) has changed the way that the developers think and work?

Agile and Scrum are incredibly effective change engines: they trigger a paradigm shift in everything. Not only in how we develop products and services, but in how we lead, in the way we collaborate with each other, in the way we interact with customers, in how we consider ourselves as professionals. Embracing agility means embracing continuous change, which in turn simply means embracing reality. Someone said: life is what happens while we are making other plans. Believing that things will stay still just to please our plans is the ultimately insane wishful thinking.

5. Scrum is simple but not easy.  How difficult is to make a company Agile?

Being simple is definitely one of the strengths of Scrum but also one if its pitfalls: it is so simple that many managers fall into the trap of believing it can become a magic wand for the company´s problems. A famous quote from Ken Schwaber, co-inventor of Scrum, is: “Agile development will not solve any of your problems. It will just make them so painfully visible that ignoring them is harder”.

And that´s where the tough part starts! Scrum is not plug-and-play! It´s not just a SW methodology upgrade. It changes some of the basic assumptions about how products get developed! It´s like installing an iOS 9 app on an iOS 4: it won´t work! You need to upgrade the Operating System! Only courageous leaders, who are willing to make an impact, dare to start the journey to upgrade their company´s operating system.

6. What should companies do to achieve a successful transformation in the Agile world?

The first step is about asking “Why?” What is the problem we are trying to solve? There must be a clear need for any improvement change: imagine how crucial it is to start off such a dramatic change. So any successful Agile transformation implies a top-down approach, in terms of Company values, leadership culture, business goals and management support. However, there are aspects that need to emerge bottom-up, like practices to be selected by self-organized teams. It has to be a sandwich strategy! Given the importance of the top-down part in the enterprise change, one of the initial steps is to educate 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 prioritized, if not even neglected.

Finally it is extremely important that teams are organized so that they can deliver value to customer as fast as possible, replacing functional teams organized around the system architecture. Effective teams are cross-functional and have all the competences needed to transform a backlog item in a product increment within one Sprint.

7. What words of advice would you give to people who are just getting started with Agile themselves?  

Every context is different: so simply copying from others will not work. Scrum is a good way to start, it is a great teacher: if you have never tried Agile development, Scrum can give you the framework to be able to start. At the same time, you need to know many things outside Scrum to make Scrum work effectively: having an experienced Agile coach to guide you through the first challenges can be a key differentiator between success and failure.

8. What are the biggest challenges that they have to confront, what are the biggest mistakes that they should avoid?

I have seen few recurrent failure patterns: Product Owners without authority, knowledge or time, superficial knowledge and lack of coaching on Agile practices and principles, complacency as opposite to a culture of continuous improvement. Well, avoiding these failure patterns is one of the biggest challenges to confront. One of the biggest mistakes is considering Agile as something to implement: Agile is rather something you are or can be. Agile is an adjective, not a noun.

9. What should people and teams do to make their workplaces and lives more productive with Agile and Lean?

There are few things that helped me become more productive and I have seen also helping individuals and teams I have coached:

• When you have a question to answer, spend time in understanding the question before jumping to the answer.
• Do not make assumptions: genuinely ask why. If you have to make assumptions, try to validate them as soon as possible.
• Challenge how things have always been done.
• Work on your strengths, more than your improvement areas.
• If you wish to succeed at anything, have a clear vision of what you want to achieve and consistently take baby steps in the right direction.

10. Where do you see things going to Agile in the future? What changes are coming?

I see contrasting things. From one side I see more and more “Agile” instances which have nothing to do with agility, where people and especially managers have lost or probably never got the original meaning of Agile manifesto: where, for instance, individuals and interactions are in service of processes and tools rather than the opposite. This can be also considered a normal evolution. When an innovation reaches the hype, it starts getting late majority or even laggards in the game: they probably accept Agile just to look fashionable or to please their boss. On the bright side I see a convergence of researches, theories, methods and practices coming from really different domains (Entrepreneurship, Neuroscience, Psychology, Finance, Management, Non-profits, even Military and Government) which are collectively creating a very visible red thread. And this red thread is all about coping effectively with fast change by using an empirical approach, embracing individuals as whole human beings not as resources to exploit, being mindful, decentralizing power, and creating meaningful relationships. That´s really exciting and resonates a lot with agility. On a broader scale, our generation is experiencing a growth in our consciousness as human race (let’s take for instance social responsibility) and that´s going to create benefits not only to our industry but to the entire world. 

Installing Scrum effectively: Upgrade your company´s Operating System!

Magic Wand by photophilde/CC BY 2.0

Scrum is simple but not easy!
I'm sure that those of you who had seriously tried Scrum can recognize what this sentence really means.
And being simple is definitely one of the strenghts of Scrum, but also one of its pitfalls: it is so straightforward to understand by managers than most fall into the trap of believing it can become a magic wand for the company problems.
Sometimes without even reflecting about what the company's problems really are!

Ken Schwaber, co-inventor of Scrum said once: “Agile development will not solve any of your problems – it will just make them so painfully visible that ignoring them is harder”.

Missing operating system_ {error message} by Karl-Ludwig Pogemann/CC BY 2.0

And that's where the tough part starts!
Scrum is not plug and play! It's not a simple upgrade of the SW methodology currently in use in the company! It changes some of the basic assumptions and thoughts about products get developed!
It's like installing an iOS 8 app on an IOS 4: it won't work! 


You need to upgrade the Operating System!

I would like to share with you what I learned to be three fundamental upgrades needed in the company´s Operating System to install Scrum effectively.

1. Cross functional teams self-organized around value delivered to customers

It is extremely important that development teams are organized so that they can deliver value to customer as fast as possible and not around technology or internal product structure.

You do not want to have unproductive teams overwhlemed by thousands of dependencies, right?
You do not want to create unnecessary coordination work and increase your overhead, do you?

So move away from micro-managed functional teams organized around your system architecture: you will heal your company!

Effective teams are cross-functional and have all the competences needed to transform a backlog item in a potentially shippable product increment within one Sprint.

They work together to remove waiting times and handovers, which represent waste of time and knowledge. 
This does not mean at all having a team of generalists. It means instead having a team of specialists with T-shaped competence, so that they can contribute in doing the work when necessary, even in knowledge areas different from the one they are specialized in. 
Cross-functional teams learn continuously from each other's skills and share knowledge inside the team and between different teams.

These teams must be self-organized: they are the ones who have the best knowledge and must be empowered to decide how to do the work and continuously adjust their process.
A cross-functional and self-organized team can have the possibility to look at the whole development process, find the weakest link or the bottleneck at hand and do whatever they see as necessary to fix it. They have enough visibility of the whole to avoid sub-optimizations typically happening in traditional environments.

2. Agile Leadership

In an environment where teams are empowered and self-organized, leaders stop taking project decisions or asking for review and status report.

They focus instead on removing impediments, aligning stakeholders, building a trust environment, coaching, providing feedback, developing people’s skills and building the capabilities of the organization: they basically create the conditions for the teams to perform at their best.
They cultivate skills of servant leadership, are empathetic and willing to help.

This is applicable with different flavors to managers, Scrum masters and Product Owners.

• Scrum is enabled by managers who build a culture of discipline and excellence, guide on principles and values instead of giving complex rules to follow, teach people not to cut corners, challenge people to high performance and lead by example. They empower people to choose how they want to work and give room for experiment and safe/fast failure. Good Agile managers stay close to the teams and Manage By Walking Around and Listening.
• Scrum is enabled by full time Scrum Masters who have a very good knowledge of Lean, Agile and Scrum and can coach the team to apply Agile values and principles. They teach and coach them to challenge the status quo and continuously improve, think and work as a team, collaborate and challenge each other to grow.
• Scrum is enabled by Product Owners who clarify the Why? and the What?, but not the How? Therefore they trust the team will work at their best. At the same time they challenge and support them to continuously improve. Good Product Owners paint the big picture for the team to take responsibility of the product as a whole and actively support the team to find ways to connect with the customer. They take the responsibility to act as a unique interface to the organization for any work request towards the development team and protect them from interferences.

It is a lot about being more than doing. See also 3 necessary management mindshifts in a fast changing world.

3. Well groomed backlog

People might be arguing about what a good Product Backlog is, but here is what definitely a good Product Backlog is not (but far too often seen around): a generic list of work items which are not user centric, not split end-to-end, not estimated, not even always prioritized.

A high quality Product Backlog is an enabler for iterative and incremental delivery of high quality potentially shippable product increments, which is the core of Scrum (Garbage In-Garbage Out theory applies in this case). It helps the team focus on the right things and build them faster.

A high quality Product Backlog is a manageable size, living artifact of Independent, Negotiable, Valuable, Estimable, Small, Testable (INVEST) User Stories.

Such stories are easier to understand for the team, easier to plan and easier to work, so that the team can be more productive.

INVEST stories allow:

• Minimize the risk that the team does not deliver anything at the end of a Sprint. 
• Faster learning and faster development because the team gets feedback and finds problems earlier. 
• Better prioritization and defer decision due to a shorter feedback loop. 
• Deliver value more often and therefore can make customers happier. 
• Teams to be more focused and more motivated, because they feel a sense of velocity and accomplishment.

Where do you think you should start first in your OS upgrade?

How to teach Scrum to your boss (and why)

One of the biggest challenges I usually faced in my experience as Scrum coach is not really related to Scrum as such, but more to the consequences that Scrum creates in the organization by exposing the real problems.

So it often happens that some people (especially among managers and senior technical experts), afraid of losing their position, start to get alarmed by the serious challenge of the status quo and do their best to slow down the change.

Ever seen that? I'm sure you have. 

And if you want to have any probability of success with Scrum, you'd better do something to address the natural resistance of middle management to move away from a command and control leadership style.

Where to start? Don't look too far: Start with your boss. 

Help her become a professional 21^st century manager capable to build a trust environment where people can develop and team can flourish at their best potential. If she becomes knowledgeable enough, she will understand and consequently start dismissing traditional management practices, which make no sense and are even detrimental in a knowledge working environment.

That's what I normally do with the managers I work with.

In two of his inspiring articles, Steve Denning, author of the best selling book The Leader's Guide to Radical Management - Re-inventing the Workplace for the 21st Century, says that Agile is The Best-Kept Management Secret on the Planet and that Scrum is a Major Management Discovery. 

Bingo! If you want your boss to support your company Agile transformation and introduction of Scrum, you just have to teach her... Agile and Scrum.

How can you do that?

1. Training and self-education

I dedicate a consistent amount of time in delivering training to managers, in individual coaching as well as in team coaching with the Leadership team. 

The Management learning program I propose has the following structure:

- Kick-off with 2-days Scrum training

- 2-days Lean and Agile Leadership training

- Individual and team assessment to identify strengths, improvement areas and further learning needs (I described a bit the content of the assessment tool in a previous blog post).

- Training program (monthly sessions) based on assessment outcomes, which is usually self-led by managers pairing up with a coach and leveraging on a Learning by Teaching approach

- Weekly self-learning activities (Lunch and learn or Lunch and share, Book club)

2. Gemba

Respect is one of five Scrum core values. Getting bit deeper than its generic surface, it means giving people the environment and support they need to do a great job and trust they will do their best to accomplish their goal. It’s about staying close to the teams, where "real" things happen and you can identify ways to improve the system .

Gemba is the Japanese word which means "the real place" (for instance Japanese detectives call the crime scene gemba). So if you want to help your boss to learn Scrum, encourage her to walk where work happens and Scrum actually comes to life.

In all teams I coach, I try to introduce managers into this “go and see” culture, not only with the goal of getting them to understand teams’ problems and ready to support, but also for making them learn Scrum by interacting with a real Scrum team.

Advertise Sprint reviews (maybe posting catchy flipcharts) or encourage your team to forward invitation even to top managers: for some of them it might be a culture hack, because they might think it is a development team’s stuff.

Pass by your boss' desk and invite her to join for the Daily Scrum. She might claim that she does not want to disturb the team: challenge her to stop asking weekly reports and join the Daily standup instead.

3. Deliberate Practice

Scrum is founded on an empirical process control: the biggest amount of knowledge is created by experience and feedback.

I usually coach the Leadership Team to use Scrum for their work, so that they can learn Scrum by actually practicing it.

Have your boss feel the pain as well as the excitement of working in short iterations.

Additional suggestion  

Have a look at the book Teaching smart people how to learn by professor Chris Argyris, Harvard Business School. 
He talks about avoidance of learning and how discrepancy between espoused and actual theories of action harms people’s learning: these are actually the biggest problems I found with people and especially with managers which you would not classify as innovators or ealry adopters in the Rogers’ Bell curve on diffusion of innovation.

So try to keep an empiricist approach: you will lower down your boss' defends and have her more open to new things, because she would feel less in danger.

Address concrete and painful problems and show how Scrum can help her with them. Avoid to fall into the trap of: "this is Scrum, this is not Scrum", or "this is right, this is wrong". Escape discussions based on personal opinions, but try to build a we-are-together- against-the-problem atmosphere. At least you will save a lot of talks and useless discussions.

Warning 

I learned not to waste too much time with laggards and cynics. So if you classify your boss like that, just spend enough time to make sure she does not pull others and the organization to old behavioral patterns. 

Or better, quit your job!

Being a manager in the age of Agile

I was reading back the post I wrote about one year ago, where I talked about what a manager can do to build and operate effectively a 21^st century organization rooted into Lean thinking.

To take a long story short, if you are a manager who was told not to take decisions your team would be able to take themselves, ask for reviews and reports or push activities onto your people, you’d better not to. But there are plenty of things indeed you can do (and should do) instead.

I tried to summarize them in the mind map below (click on the image to enlarge).

And well, I also re-used the title of the workshop I held at LESS 2012 J (see http://www.slideshare.net/giusdesimone/learning-to-be-a-manager-in-the-age-of-agile)

So, what do you think? Does this visualization support a clearer picture?

What thoughts did it trigger?

What else will you add as necessary or valuable?

What would you like to see changed in your organization?

What would you start doing differently from tomorrow?

The metrics enigma - 2

Second part of guest post from Mauro Bagnato about organizational metrics. Enjoy!

In my last post The metrics enigma I tried to look at the metrics from a different perspective, starting from the method proposed by D. Hubbard in his fantastic book How to measure anything. In order to turn these insights into practice, I arranged a four-hours workshop with the whole leadership team. Main goal was to share knowledge and to come up with a bunch of brand new organization metrics.

This “clarification workshop” was arranged in the following way:

Step 1. Learning&sharing. 1 hour.
Goal of the first timeslot was to introduce a new way of looking at metrics and share insights and reflections. Definition, purpose, risks and incentives were on the agenda.

Step 2. Understanding why. 30 minutes
The second timeslot was dedicated to the WHY. We tried to answer the question: “Why do we need metrics?” After a very interesting and intense brainstorming session, the leadership team came up with this answer: “We need metrics because we want to understand if we’re improving”. Good start, clarifying the purpose helps tracing the direction to get the metrics we really need.

Step 3. Undestanding what. 30 minutes
The third timeslot was focused on the OBJECT OF MEASUREMENT. Now the question was:” What are we going to measure?” Well, starting from the why found in the previous step, we just needed to measure the improvement. Unfortunately the word improvement was definitely something too vague and hard to measure, unless we had been able to turn it into something tangible. “What does improvement mean for us?” or better “Let’s suppose to be able to clone our organization and instill in the cloned one a massive dose of improvement, while holding the amount constant in the original one. What change do you imagine you would actually observe in the cloned organization?”. Those questions triggered an interesting discussion ended up with the statement: if we want to understand whether our organization is improving or not, we need to observe certain dimensions: delivered value, external perception, learning, innovation and climate. Now we had five objects of measurement even if they still needed further clarification to be measured.

Step 4. Metrics definition. Two one-hour iterations
The fourth timeslot was focused on turning each dimension into metric. In order to facilitate the discussion and to work on more items in parallel, I split the leadership team into two groups and asked them to go through a four phases discussion. The following picture describes the proposed logical path.

If we are able to turn each dimension into something really tangible, it should be easy to directly derive the metric…basically this was the main idea. For example, if innovation meant generating ideas only, we could assume that measuring the number of ideas would tell us how innovative we are. Thus we must understand the meaning of innovation first. In other words the further clarification phase (see the picture) means keep repeating the actions in the step 3 till the vague concept of innovation becomes tangible.

A deep clarification of the object of measurement should lead us to the metrics but… how can we check if those metrics are really good? Did we consider all the aspects? Did we miss something? Next “control” phases in the path help answering those questions. Before going deeper into those phases, we need to make some reflections first. Let’s start from the assumption that measuring means getting information and that getting information requires a certain investment. The amount of this investment should be tied to the importance of the information. Since the reason why we collect information is that we want to reduce the uncertainty related to a certain decision, then the importance of the information is directly related to the relevance of the decision we need to take. (in the financial context reducing the uncertainty related to an investment decision could save a lot of money). Starting from these considerations, the phase 3 requires to answer the question: “which decision does this measure inform?” or in a different way “do we really need this measure?”.

The last “control” phase comes at the end of the chain. Setting a metric in itself inevitably influences people behavior in ways that may or may not be the intended outcome. Here is an example of possible side effects or incentives a metric may produce. Let’s assume that the metric used to monitor a help-desk performance is the number of handled calls. This metric may generate the side effect that help-desk workers are encouraged to conclude the call as soon as possible without solving the problem. In this case the real outcome (side effect) of the metric is far from the expected benefit. On the other hand if the metric was the customer feedback collected at the end of the call, then help-desk workers would be encouraged to give the best service possible to their customers.

It was interesting to see that only few of the metrics found at the beginning of the path, passed the final control phases!

The outcome of this intense, tiring, but interesting workshop was a bunch of metrics related to two dimensions only. Yes…we didn’t manage to complete all the work, but we learnt together how to tackle the metric problem in a different and structured way. We found out how to solve the metrics enigma!
It was a collaborative work of the whole leadership team that gained the fundamental result of building a shared vision around the metrics.

The metrics enigma

This is the third post I host from Mauro Bagnato: my friend, if you keep producing at this rate in 2014, I will be gladly forced to open a special column for you!

A hot issue is touched this time: organizational metrics. The ones among you who are constantly reading (R)Evolutionary Agility know that I wrote already an article about this subject and I have plans to write more about it. 

Whether you celebrate Christmas or not, I wish you all restful and peaceful season’s holidays!

I’ve been struggling against organizational metrics for almost two years.

I must say that it’s a bit frustrating to look for a reasonable answer to the question: “which are the right metrics that an Agile organization should have?” and get the feeling to be very close to the goal, but without being able to hit the target!

These days I recalled a famous quote from Charles Kettering saying: “A problem well stated is a problem half solved”. It made me reflecting. 

Couldn’t it be that it’s so hard to find the solution of the metric enigma just because of the wrong question? Got convinced about it, I decided to start from scratch and to ask myself: Why do we need metrics?

Here you are the answers which came up in my mind.

We might need metrics because we want to:

•  find the evidence that the Agile transformation is worth the investment
• understand if we’re improving
• understand if we’re getting closer to our vision
• show our stakeholders we’re a fantastic organization
•  etc. (I could go on…)

This approach looked promising. Clarifying the purpose traces the direction and helps identifying the metric we really need, the ones linked to our goal. So far so good I’d say!

And now? How to move further? How to turn this goal into metrics? How to measure something so vague and undefined like stakeholders’ perception, improvement, ROI of the agile transformation etc.? In other words, how to measure intangibles?

The answer, or better, the method to measure this kind of things is described in the book “How to measure anything” from Douglas Hubbard. This very interesting book proposes a three steps way to measure intangibles:

1. Concept of measurement. What does measurement means?

Usually measurement is thought as the process aiming at quantifying something or giving something an exact value. This common conception implies that measurement means reaching a sort of certainty (numbers or values are expression of certainty).

This idea fits very well with the measurement of lengths, widths, etc. but when it comes to the intangibles (like happiness, empowerment or motivation) it doesn’t help a lot.

Scientists use a different definition: A measurement is a quantitatively expressed reduction of uncertainty based on one or more observations.

This definition introduces two interesting points:

·     Measurement is no more connected to the idea of certainty but is defined as reduction of uncertainty.

·     It’s possible to measure anything (intangible or not) observing the impacts, the effects, the results.     

2. Object of measurement. What do we have to measure?

Even using the new definition, something could still seem immeasurable simply because the object of measurement is not clear or is not clear enough. Very often clarifying the meaning of what we want to measure makes the problem much easier. What does it mean? That’s the fundamental question to answer.

How to measure happiness? One million dollar if someone is able to find the answer!
Let’s try to change perspective and decompose the problem by answering the question: What does happiness mean? For me happiness means having enough time to dedicate to my family and to my hobbies. Measuring the time spent that way gives me an indication of how happy I am!

I found something measurable to observe reducing the uncertainty related to the measurement of happiness!

It might happen that the answer to the fundamental question is still something intangible. In this case the trick is to repeat the question till the answer is become something measurable.

D. Hubbard suggests also a different way to clarify the object looking at the effect or the consequences: Let’s suppose to be able to clone someone and to be able to instill a massive dose of happiness in the cloned guy, holding the amount constant in the original one. What do you imagine you would actually observe that would change for the cloned guy?

Whatever the method, once the object of measurement is clear, it’s possible to find the way to measure it.    

3. Methods of measurement. How do we measure?

I’ll not dig too much into this point but D. Hubbard suggests to make use of whatever methods of measurement based on:

·     Sampling. It simplifies a lot the process of measurement. We need much less data than we think to get a valid measurement.

·       Experiment. Anyone can develop an intuitive method for measurement and the best approach is to try it and learn from it.

Let’s come back to the starting problem and see if the method works. Assuming that we need metrics because we want to know if we are improving, next step is understanding what improvement means. Assuming that improvement means delivering more value, now we need to understand what delivering more value means. Assuming that delivering more value means delivering what customers really need, what happens when customer have what they need? Assuming that when customers have what they need, they simply use it, we could start observing how many customers really use what we deliver.
We got the object of measurement! Now the point is how to measure it? How many data are we going to collect? Making a sampling of the customers could simplify a lot the measurement itself without compromising the results (see “The rule of five” proposed by D. Hubbard).

It seems we got the point but…could we get there without wasting our time with all this stuff?

Before answering the question, we should consider that the outcome of this method is not only metric itself, but mainly the path to get there. Questioning the need (what we want to achieve), decomposing it reflecting on its meaning/effect and then finding what to measure, builds a sort of picture communicating:

• what we want to achieve
• how we want to achieve it
• What we consider important, what we care of.

Then metric becomes the logic consequence of this journey.

In the next post I’ll tell you how I applied this method in a 4-hours workshop for defining the metric of the organization I work with.

The snowball

This week I host another article from Mauro Bagnato. Today he shares some reflections about his experience with enterprise Agile transformation and provides a concrete example of a management practice about leading self-organizing teams.

After almost three years working as Agile Coach, one of my personal take away is that the Agile transformation is like a rolling snowball.

Once you really walk this way, your mindset will gradually but inevitably change till the moment when it’ll be impossible to get back to your old way of thinking, just like a snowball getting bigger and bigger while rolling downhill.

A clear example of what I’m saying happened weeks ago.
After a complete re-organization, the management team decided to let people self-organize to form twelve brand new teams…and the snowball was thrown! The team setup was a great whole day event (if you’re interested have a look at my previous post).

Everyone had the chance to choose the team to work with, but we all knew that this was just the starting point.

How to select the Scrum Masters and the Product Owners? 

How to group the teams to form four development units? 

How to assign a manager to each unit? 

Those questions and many many others were on the table and needed a fast answer.

”Why not letting teams decide again by themselves?” said one of the managers.

"Did I get it right?": I thought.
The snowball was getting bigger and was still rolling…

So…after having given people all the support and information they needed to make a conscious decision, teams were asked to select their Scrum Masters and Product Owners and to give their preferences among the list of managers.

How did it go? I would say that the whole experiment was a complete success!

I’ve got this feeling not because I’m 100% sure that we found the best setup possible, but because of how much we learned out of this journey.

And now? The snowball keeps moving and we’ll see what happens!

Self-organized team setup: how to cook it!

Today I have the pleasure to host an article from my friend Mauro Bagnato. It's an interesting post around self-organization and what it takes to make it happen and working functionally to achieve a compelling goal. 

What does self-organized team setup mean?

Put a hundred people together in the same room, ask them to form twelve teams and wait till the magic happens!

Sounds quite easy, fun and fast, right?

So…why don’t we try it tomorrow morning in our organization?

Unfortunately it does not happen that way; you need to mix together the right ingredients in the right quantity and with the right timing.

If you want, here is my recipe: 

1. Start with a massive quantity of the Lean discipline Respect People: trust them, let them decide and truly believe that, given the goal, they will find the best way to get there. 
2. Keep on shaking the whole organization (starting from the leadership team) to be sure that this fundamental ingredient is very well spread and understood by everyone.
3. Now mix with a purpose, a goal that WE, as a collective, strive to achieve. Take it very carefully, because only a common and inspiring goal may overcome the inevitable selfish choices that may occur during the team setup: we’re not here to build only one marvelous team, we’re not here to fulfill only our personal aspirations, but we are here to work TOGETHER to build a brand new organization setup that will take all of us close to our goal. That’s our mantra!
4. Don’t forget just a pinch of organization constraints: a very few rules the teams have to respect while forming.
5. Now blend everything together in a whole day event where the initial chaos, due to a hundred people moving, chatting and laughing, will turn step by step into twelve groups of people (the future teams) ready to cope with all the challenges they will face.
6. Don’t forget that good ingredients are not enough to have a perfect flavor. You need the right cooking time and procedures as well: in our case coaching and communication. Involving the whole organization during the preparation, keeping everyone informed, letting everyone understand what we’re doing (and above all why we’re doing it that way), challenging the current way of thinking are definitely what we need for a perfect flavor.

And now enjoy!

Change is optional: survival is not mandatory

As many of you can have guessed, the title I chose for this post is inspired by a quote from W.E. Deming.

When I got to know Deming for the first time, many of his lessons came as a revelation to me: they were kind of resonating with my personal thoughts and reflections, but still they cleared out many clouds.

One of those I prefer is: 

“…most troubles and most possibilities for improvement add up to proportions something like this: 94% belong to the system, 6% are attributable to special causes.” 

I think that this simple sentence can trigger several reflections about how to make things happen and especially how changes can have a chance to happen and possibly stick.

Below are mine, from my personal survival handbook J.

1. Look at the system

An organization, even a single team, is a complex network of people, who are complex beings. If you really want to leverage on all potentials to affect it, you must look at it as a whole system. 

Try to sketch the possible options you have ahead, possible impediments and way to overcome them to reach your goal: you might realize that you need to take many steps, in order to get any progress. 

Prefer actions who affect the environment around or the process to do things, instead of addressing directly a specific problem: they will have a more lasting impact. And, whatever level you want to affect, consider acting also one level up.

“It does not happen all at once. There is no instant pudding.”-W.E. Deming

2. Involve people

Try to understand your team or organization very well. Learn 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 influential on certain subjects, whether he has a formal power or only a de-facto leadership. Talk to people, with a preference for informal chats (coffee machines are a perfect place sometimes).

“A desk is a dangerous place from which to view the world” – J. Le Carré

Create an alliance: find initiators to support you and involve them in creating a shared strategy for the change. 

Chase innovators eager to try new things out first and learn from people actually doing the work. 

Find also sponsors to support you in difficult situations and leaders who can help with crossing the chasm and reach out the majority.

“The greatest waste … is failure to use the abilities of people…to learn about their frustrations and about the contributions that they are eager to make”- W.E. Deming

Strive for ways how to collect as much feedback as possible, especially from skeptics, but do not spend time in convincing cynics and possible saboteurs.

3. Communicate properly

You cannot just plan your change at your PC, create a slide ware and then ask to deploy it to the whole organization.

How many times have you tried to do that way? How many times did it work?

“Insanity: doing the same thing over and over again and expecting different results.”- A. Einstein

Instead explain the “why” for the change; make people aware of what it might mean and relate the change to their daily problems.

Have people desire the change (what’s in it for me?), support them with the change, provide the necessary knowledge and give them time to learn. 

Offer role models, lead yourself by example and help people with mentoring and coaching on how to change.

“If you want to build a ship, don't drum up people to collect wood and don't assign them tasks and work, but rather teach them to long for the endless immensity of the sea.” – A. de Saint-Exupery

4. Reward behaviors not outcomes

When you make a change or learn something new, usually your performances at the stuff affected by the change are getting a bit worse, especially at the beginning. So give room for experiments and possible failures, so that people are not afraid to try new things.

Celebrate short-term wins and success stories; make them visible and share the results with information radiators. 

Publicly reward those who are learning more or sharing more with others, so that the change can go viral. Express appreciation for the right behaviors so that the desire for change is continuously reinforced.

“The most important figures that one needs for management are unknown or unknowable” – W.E. Deming

5. Use an empirical step-wise approach

Before taking any step, 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 with minimum viable actions and fast feedback.

However changes in a complex environment are never a linear process you can plan upfront, set goals and KPIs, deploy it to the organization and track the progress. That’s why sometimes you must simply try things out. That is sometimes absolutely not bad, stated that you try to fail fast and reflect on what you learned to find a different path.

Of course using an empirical process control implies that you can observe your system to be able to inspect and adapt. Therefore enable full transparency; 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 change will degenerate into chaos.

“It is not enough to do your best; you must know what to do, and then do your best.” – W.E. Deming

How much time and effort are you spending really nurturing your system?

How much are you learning from people actually doing the work?

Are you really making changes happen or just increasing the entropy of your system into chaos?

And if don’t mind about change and how to make changes effectively, skip the whole article and just consider that: 

“It is not necessary to change. Survival is not mandatory.” – W.E. Deming