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!

Agile is demotivating

A few weeks ago I happened to talk to a couple of University students who were conducting a survey in different companies about the impacts on people motivation from moving to Agile SW development. What they told me could appear surprising to many of you: a consistent percentage of people answering their survey claimed that they feel extremely frustrated and demotivated with Agile. Are you hit by this? I want to elaborate in this post why I was not.

What is motivating for knowledge workers in 21^st century?

In his extraordinary book “Drive: The Surprising Truth About What Motivates Us”, Dan Pink sketches what he calls Motivation 3.0. 

Based on scientific evidence over decades of research, he explains that, once basic living needs (like food or safety) are satisfied (Motivation 1.0), the factors that are still nowadays commonly considered as motivating (carrot and stick, e.g, money and punishment) are actually working only for simple and repetitive tasks. 

These “extrinsic” motivators (Motivation 2.0) are not only useless, but even counterproductive, as soon as tasks require cognitive effort: in that case “intrinsic” motivators are the only ones which really work. Motivation 3.0 is based on three pillars:

• Autonomy - over
• Time – when to do the work
• Technique – how to do the work
• Team – whom to do the work with
• Task – what work to do
• Mastery – ability to become better at something that matters for you
• Purpose – natural desire to contribute to something greater than yourself

You might want to have a look at Dan Pink’s TED talk, The puzzle of motivation or to a nice visual depiction of the 3^rd Drive theory on YouTube to get some more insights. Or simply read the bookJ.

After having reflected around what is motivating, let’s touch a bit what Agile is. 

Well, if we want to explore the subject from the perspective of the relationship with motivation, the first thing that comes to my mind is the 5^th Agile principle: 

Build projects around motivated individual. Give them the environment and support they need, and trust them to get the job done.

Motivation looks like being somehow embedded in Agile: so how can we explain the result from the survey? 

Well I will not give an answer based on a well-defined and exposed theory of what Agile is.

On the other hand, if I look at the three intrinsic factors in Motivation 3.0, I can say from empirical evidence what Agile is definitely not.

Agile is not:

• Artificial deadlines pushed on teams for lack of trust
• Commitments taken by people not actually doing the work or, alternatively, commitment games (people pushed to commit and then it’s their business to keep the commitment)
• Processes pushed from the top (sometimes by people with not enough understanding of the work at hand)  
• Developers not allowed to choose what they consider the best tools for them to work
• A lot of gate checks before being allowed to change any line of code
• Teams with not enough skills or support to succeed
• Bossy team leaders called Scrum Masters who do the planning and assign tasks to developers
• Senior technical people just playing the role of “checkers” instead of teaching people how to do a better job
• Accumulating technical debt and not promoting pride for well crafted code
• No Product Vision or lack of understanding why to develop a certain feature

So, if anyone, who finds herself in a similar reality, names all the stuff above as Agile, maybe just because she’s using post-its and white boards, I cannot agree more with her: Agile is demotivating.

I would then like to hear less Agile talks and more lived up Agile values and principles (and more knowledge, and more practice).

I subscribe to what I heard James Grenning saying to managers in his closing keynote at Scrum Gathering London 2011: Stop motivating people, but stop demotivating them!

What is your thinking?

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.

What the hell is a Sprint Review?

This is the last post before New Year’s Eve: so it is time to “review” the year which is going to give us the gift of enjoying the last days in its last month. That’s why I decided to spend few lines about Sprint Review.

2013 has been for this blog quite an interesting journey of 22 articles: I learned a lot by publishing them and I hope the 9000 readers (R)Evolutionary Agility had in the last 2 years have learned something as well. I wish you all an exciting and joyful 2014!

Some weeks ago I delivered a 3-days course for Scrum Masters. I usually visualize the agenda as a backlog of subjects we prioritize together throughout the training.

During a coffee break a guy approached me and asked: “I recognize the different ceremonies in the agenda, but I never heard about Sprint Review. We normally do a Sprint Demo: is it the same thing?”

“It depends on what you do in your Sprint Demo. Can you tell me more?”, I answered.

“Well, at the end of the iteration our Program Manager calls for a Demo meeting. All Scrum Masters are attending and reporting what we have been doing during the past 3 weeks”.

“So what are you demoing then?, I asked.

“We’re presenting a powerpoint slide set, showing a detailed report of the different activities during the Sprint, who was doing what and how much time was spent given the people allocation”.

Again? Yet another manipulated buzzword!?

And yet another empirical evidence of how an organization can produce so powerful antibodies to resist and protect itself from cultural change bacteria.

So let’s see if we manage to inject some virus of learning and growing mindset: these are usually quite effective in spreading willingness for improvement.

Let’s start from some why: why is a Sprint Review important? What is the purpose it is meant to serve?

Scrum is grounded in empirical process control theory and therefore uses an iterative and incremental approach to optimize the path towards a certain business goal by means of fast feedback loops. 

As any other implementation of empirical process control, it is based on 3 pillars:

1. Transparency

All information necessary to handle the process must be available to those handling the process

2. Inspection

The different aspects of the work must be inspected frequently enough so that unacceptable variances can be detected. Of course the skill and diligence of the people inspecting the work resul matter.

3. Adaptation

If the inspector determines from the inspection that one or more aspects of the process and the resulting product are unacceptable, the inspector must adjust the process or the material being processed. The adjustment must be made as quickly as possible to minimize further deviation.

The Sprint Review meetings are used to inspect progress toward the Release Goal and to make adaptations that optimize the value of the next Sprint.

The Sprint Review is then an important learning point and a fundamental step in the empirical process control applied by Scrum. That’s why calling it just “demo” is mislabel, since this word does not capture the real intent of this ceremony. Let’s analyze what might be the learning points for the main actors:

• The Product Owner and key stake-holders learn what is going on with the product, what are the results of the Sprint and check whether those results are able to bring the whole Scrum Team closer to the Product Vision. The Sprint result will have anyway impact on the Product Backlog for the next Sprint Planning: new stories might be added, changed or removed and prioritization might change.

• The Development Team learns what is going on with the Product Owner and the market. They also learn whether the Sprint Result validated the assumptions they made during the Sprint Planning. For that reason it might be useful to review the estimates, to check whether they got confirmed after the story was actually built: in this way the team know how to estimate better and build a better baseline to relate further estimations. They’d better review also the different team metrics and the Sprint Burndown Chart to gather interesting data for the coming Sprint Retrospective. Review of Team Working Agreements and Definition of Done will indicate the team whether what they learned during the Sprint can affect the team’s rules or their quality criteria.

For these reasons, the most important element of the Review is the conversation and collaboration between the Team and Product Owner to learn the situation, to get advice, and so forth.

It is a public ceremony: the Product Owner, Team members, the ScrumMaster, plus customers, stakeholders, experts, managers and anyone else interested is allowed to attend and anyone present is free to ask questions and give input. The Scrum Master will work to maximize the learning of all participants.

Even though calling the Review just “demo” doesn’t really make the point, the demo is anyway an important part of it. But what does it make sense to demo?

Let’s have a look at some of the Principles in the Agile Manifesto:

1) Our highest priority is to satisfy the customer through early and continuous delivery of valuable software

3) Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

7) Working software is the primary measure of progress.

It doesn’t mention powerpoint slides, right? J

So the only demo which makes sense is showing an installation of an integrated potentially shippable product increment. BTW, the Product is the only language which everybody, from business to developers will understand the same way.

Remind: spend as little time as possible on preparing for the demo. If you need to spend a lot of time there must be something wrong somewhere.

If you read and liked this article, I have a question for you: 

How will you change your next Sprint Review?

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 Mango Tree

I found out that I like the “gardening” metaphor a lot (see also my latest article).

Last Friday I met a colleague during a coffee break.

We were sharing some views about what had happened during the week, when he said: ”You know, this transformation we are all undergoing is like a mango tree. Everybody seems to want mangos, but no one seems to care about how juicy they are and to know how to get juicy mangos”.

Nice way to put it: don’t you think so?

Then we started building upon this metaphor and having fun taking it to the extremes.

And I think that, what we got out of it at the end, was really good way to explain what does it take to get a team or an organization become Agile or more generally to make a change successfully happen.

So what will a good gardener do in order to get the juicy fruits she wants to harvest in her garden?

1.    Decide what fruits or vegetables you would like to collect

The first step is definitely to define what kind of garden you would like to build and what fruits or vegetables you expect to get. Then you can go and buy the corresponding seeds to plant: of course you need to plant mango trees if you want to get mangos. On the other hand you will never get mangos out of onion seeds (for instance have look at this article from Lyssa Adkins to check out what to seed to get a high performing team)

2.    Work a good piece of land

Quality of seeds is essential to get juicy fruits, but so is quality of land. So make sure to have the right environment for the plant to grow strong. Plants growing nearby can also affect the taste of fruits and vegetables: for instance if you grow lettuce close to artichokes, it will probably get bitter. A good gardener knows that, same as she knows how air pollution can also be very detrimental.

3.    Start growing small plants

So how do you think you can verify whether you bought the right seeds and you worked the land properly? Will talking about how the plant should look like help? Most probably not.

Instead a good gardener would start planting some seeds and grow some small plants. She would water the plant; she would ensure it gets enough sun (but not too much); she would fertilize it and protect it, so that it grows strong and can produce the first fruits.

4.   Taste the fruits and decide what to do

Finally she will happily pick the first fruits and taste them to check if they are sweet and juicy enough. Sometimes you will not even need to wait until the fruits are mature. It won’t be hard to see quite early if you’re getting the right fruits in the first place: you will pretty easily tell a mango and a pineapple apart. If you’re getting the right fruits with the expected quality, you can keep growing the same tree and maybe plant more of the same. Otherwise you can even remove the plant or adjust your gardening, trying a different type of fertilizer or dose the water differently. Until you get the wonderful garden you were looking for.

Does this remind you anything? Right, it looks like the Plan-Do-Check-Act cycle from W.E. Deming.

BTW, gardening follows just an empirical approach, the same as Lean and Agile. 

Both gardeners and agilists don’t spend time talking about how things should be done in the best way, but they start doing things, just enough just in time, and most important they learn by actually doing, one experiment at a time.

So, what about your Agile transformation?

Are you actually planting seeds and tasting the first fruits?
Or are you just talking about how a good mango tree should look like, maybe even without having ever seen one?