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?

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!

Product Backlog Gardening, with love!

Wikipedia (btw, the most successful example of an emergent product from a self-organizing team) provides the following definition:

Gardening is the practice of growing and cultivating plants. It involves an active participation and tends to be labor intensive, which differentiates it from farming or forestry.

I cannot find a better metaphor to describe the continuous work that a proficient Product Owner needs to do with the Product backlog.

1. First step is actually to plant a seed. That’s the purpose of defining the Product Vision together with the customer, answering the questions: What do we want to accomplish? And why? All gardeners know that quality of the seed is essential and of course you need to plant cherries if you want to get cherries and you cannot get roses if you plant onions.
2. After you plant the seed, you need to water and fertilize it. Then the first small sprout will come out of eliciting a set of SMART (Simple, Measurable, Achievable, Relevant, Traceable) requirements, focusing on customer needs, on the problems to solve or better on the problems worth solving.
3. The tender small plant now needs a good environment to strengthen and grow. Gather all needed people in a User Story workshop and collaboratively write down as much as stories as possible. You as a Product Owner, exactly like a good gardener, do not have to do all the work yourself: you need proper tools and a fertile land. So use the best land, i.e. the power of the diverse brains around you. Present your Goal for the next Release Cycle and the related Requirements. Make use of creativity techniques to elicit as many User Stories from the Team as possible. Try to identify top MMFs and break them down into User Stories, or cluster User Stories into MMFs.
4. Good User Stories should be INVEST
• Independent: Stories are easiest to work with if they are independent.
• Negotiable... and Negotiated: A good story is negotiable. It is not an explicit contract for features; rather, details will be co-created by Product Owner, programmers and testers during development.
• Valuable: A story needs to be valuable to the customer. Think of your Product as a multi-layer cake: a story is supposed to give the customer the essence of the whole cake, and the best way is to slice vertically through the layers. Developers often have an inclination to work on only one layer at a time (and get it "right"); but a full database layer (for example) has little value to the customer if there's no User Interface.
• Estimable: A good story can be estimated. We don't need an exact estimate, but just enough to help the customer rank and schedule the story's implementation. Being estimable is partly a function of being negotiated, as it's hard to estimate a story we don't understand. It is also a function of size: bigger stories are harder to estimate. Finally, it's a function of the team: what's easy to estimate will vary depending on the team's experience.
• Small: Good stories tend to be small, such that the team can do 6-10 stories in a Sprint as thumb rule. Above this size, it will be too hard to know what's in the story's scope, it will delay the feedback loop and increase the project risk.
• Testable: A good story is testable. Writing a story carries an implicit promise: "I understand what I want well enough that I could write a test for it." Teams are made more productive, by writing customer tests, in terms of Acceptance Criteria, before implementing a story.

INVEST is not only an acronym, but means the Product Owner needs to invest time, energy, skills and, why not , love, to make the plant flourish like all passionate gardeners do. And you cannot achieve it on your own: you can have a say on the "INV" part, but you will never get the "EST" without your team. Remember: Gardening involves an active participation and tends to be labor intensive, which differentiates it from farming or forestry.

5. A good Product Backlog is of manageable size, more granular on the top and more general towards the bottom, so that you do just enough, just in time work. Continuously trim useless leaves to give more space and lymph to the buds going to bear fruit soon: the User Stories being developed in the coming iteration and transformed in a potentially shippable product increment. Nevertheless continue watering and fertilizing the plant, looking a bit ahead to set the stage for later buds and fruits.
6. If you want to collect many fruits after each Sprint and thus maximize the Return on Investment, you might need to split User Stories in smaller chunks. But beware: splitting by architecture or by implementation details is a common mistake. It creates smaller stories, but fails several of the other INVEST criteria and then does not bear fruit. There is no too small story, unless it fails delivering value to customer. You can find a suggestion of possible good patterns to follow when splitting stories and still keep them INVEST here. An awesome and useful mindmap guiding you through the different patterns can be found here.

GIGO theory

One of the biggest causes of poor Product quality is a poor Product backlog, exactly like a sick plant cannot bear juicy fruits: GIGO theory applies J

So are you constantly gardening your Product Backlog with love?

Or are you expecting to harvest without hard work and passion?

I’m sorry to say that you will only collect invaluable fruits, my friend!

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

The myth of “Scrum of Scrums”

There are a lot of myths about Scrum and Agile in general.

The most commonly found both by googling and in reality are:

• Agile Teams do not plan
• There’s no documentation in Agile development
• Agile development is not predictable
• Agile Teams do whatever they want
• BTW, Agile Teams do not work hard, but just play around
• Agile is only for small companies developing web applications

Ever heard anyone saying that?

I bet you have.

However having the discussion about scaling Agile (and Scrum in particular) got more and more attention, yet another myth emerged:

• When you scale Scrum to more teams, you handle dependencies and coordination among teams with Scrum of Scrums

I think there’s hardly anything more dangerous and harming for both Scrum and large companies willing to adopt Agile SW development.

Actually dependencies are handled in Scrum by actually eliminating or at least minimizing them. That is done in many dimensions and here are 5 key things you cannot miss:

1. First of all development teams must be cross-functional, meaning that they have all needed competencies to transform a product backlog item in a potentially shippable product increment. This is complemented by adopting a collective code ownership, where anybody is allowed to touch any line of code needed to deliver a product increment at the end of the sprint: otherwise you constrain your team with a lot of dependencies from outside
2. Backlog items shall be in the form of end-to-end User Stories, cutting the system through all layers from front-end to the back-end to produce a potentially shippable piece of function: a component based development produces instead a hell of dependencies
3. User Stories shall be INVEST, where the I stands Independent, so that they are easier to work
4. In a scaled Scrum approach the Product Owner Team develops a unique Product Backlog to feed all development teams and ensure that they are as much independent as possible so that they can move fast with little need to coordinate with each other
5. Scrum teams plan together so that residual dependencies are detected as early as possible

If all that is implemented and being impossible to foresee everything in advance, you will use the Scrum of Scrum as a mechanism to manage coordination needs which pop up during the sprint.

It’s not a meeting of Scrum Masters to report some kind of status, but a possibility for a person who got a problem to rise up her hand and get fast help and support from other teams.

BTW, if you think about, the acronym is SOS.

So it is not meant as the umpteenth coordination structure, but more as an emergency procedure to adopt when some team has put or is going to put something on some other team’s feet.

Otherwise, if any possible effort to minimize or at least reduce dependencies in advance is not taken, you will put so much overhead on your teams, that will basically kill their velocity and productivity.

On the other hand, if you’re not able to implement real Scrum with only one team, how can you succeed in scaling it?

You’d better run your projects in a traditional way!

An Agile Conference in the Heart of Europe

Last week I went to Agile Prague 2013 conference.

The conference was great and again I would like to share with you the most interesting take-aways I brought home from the sessions I attended.

1. The first one is from Scott Barber’s keynote.

He had a point that, regardless the fact that we talk about SW engineering, we are not very much learning from other more “classic” engineering fields. For instance in SW industry many still doubt about the value vs. cost of testing and there’s a spread tendency of considering SW development like manufacturing instead of R&D. That’s different in Classic Engineering, which is by the way a far more mature industry:

- No one questions the value of testing: how could you put a bridge in production without producing a prototype and testing it thoroughly?

- The Team is both responsible and legally accountable for quality/safety

- “Go Live” decisions are (relatively) easy

So we would be well served to study “other” fields of Engineering, consider real R&D practices for new software development and forget titles, but be responsible and accountable as a Team.

2. The second great insight was from Kevlin Henney’s keynote.

He started from the consideration that you’d better concentrate on what you can complete, because you learn by finishing things (as btw we are all taught by the Lean SW principle “Deliver as fast as possible”). So he introduced a theory from 1990, called Worse Is Better, of why software would be more likely to succeed if it was developed with minimal invention.

And yet we have not learnt this lesson in 2013!

The theory claims that it is far better to have an under-featured product that is rock solid, fast, and small than one that covers what an expert would consider the complete requirements.

This is all at the heart of Agile SW development, in contrast with the classical “The right thing” design philosophy and the failing ambition to define everything from the beginning. Ralph Jonson said: “Architecture is the decisions that you wish you could get right early in a project, but that you are not necessarily more likely to get them right than any other”. An empirical process control is what works best in SW development: properly gaining control of the design process tends to feel like one is losing control of the design process.

3. David Hussman in his provocative talk “Renaissance, Reformation and NonBan” urged the need for a Renaissance and Reformation of Agile back to its original spirit and practices from what sometimes now became only yet another process. We should learn again from masters like Ward Cunningham, Alan Cooper or Jeff Patton. What’s old is new again and very much necessary: storytelling, pairing, test driven. We need for instance better discussions, not better documents. What other reforms are needed today? He proposed NonBan: the least amount of process adopted by very skilled persons with the most real and measurable value. Interesting perspective, isn’t it?

4. Finally I found inspiring Andrea Provaglio talking about Dreams. He presented an organizational model based on 3 pillars: Dream, Order and Action. The Dream is about intent or vision, Order is about rules, functions and procedures, while Action is about production and skills. He mapped very nicely this model into Scrum: the Dream is the Product backlog, the Order are the Scrum ceremonies, while the Action is the Sprint, where a Dream-bit (a User Story) is actually transformed in a potentially shippable product increment. As counterpart of Dreams there are Needs, stuff that we need to do, like defects to fix. They fall into the backlog as well and it would be interesting to measure the Dreambits/Needs ration in our Product Backlog.

I gave my contribution to the Conference by delivering a session called “12 ingredients for a successful Agile transformation” which had quite a big audience and which is based on a series of posts I published on this blog (see Part 1, Part 2 and Part 3).

You can find all presentations stored at this link.

Videos from all sessions will be soon available at this link.

If you like to get info on the progress, follow @Agileprague on Twitter.

After my presentation I got an interesting question: "Do you think that signatories of the Agile Manifesto had foreseen that all in 2001?"
I answered: " I do not know if they had envisioned this when signing the Agile Manifesto, but I challenge anyone to demonstrate me that you can really implement Agile values and principles without all that is needed to transform the paradigma of an organization".

Does anyone feel like accepting the challenge? :)
What's your opinion?

What I learned from being a Scout leader

Summer has definitely come! July is time of vacation, but for many of the 40 million Boy and Girl scouts in the world is also time for summer camp, the culminating and final event of the year.

Next Tuesday we’re also leaving for our summer camp: 10 days in the mountains, 200 km far from home. Thus for me as a Scout leader this is basically working time, busy with all needed preparation activities.

I have always found many similarities and common approaches between being an Agile coach and being a Scout leader: I learned a lot from both worlds, lived many resonating values and principles and re-used successfully experiences from working time in my volunteer cause and vice versa.

In particular you know that I’m interested in training and how people learn: I’ve been actually interested in that for more than 20 years, just because educating boy scouts is basically giving them the opportunity to learn and become the best they can be.

Our founder Sir Robert Baden Powell said there is always at least 5% good in any person, so a Scout chief’s goal is to pull that 5% out and make it bear fruit. BTW, “to educate” comes from the Latin “ex ducere”, which literally means “to lead out” what a person already potentially is.

Therefore I understood a lot about how kids and people in general learn out of scout educational model.

Basically it is an experiential model and one of the pillars is represented by the triplet Experience-Symbol-Concept.

1. Experience

The person is offered a meaningful experience, which is different depending on the context, not just for the sake of the experience, but to let her elaborate it by means of a symbolic language. It is generally a concrete experience lived at level of feelings or physical emotion.

2. Symbol

The symbol joins the experience with its meaning, i.e. the learning point. It is a concrete object or fact which is used for reminding the emotions lived during the experience and mediating its conceptualization.

3. Concept

By debriefing and recapping the experience, you get an understanding. And just because you live again the experience through the glasses of the symbol, you are able to make it kind of universal and conceptualize the learning.

Of course this is the path followed by the trainees. A trainer has to go the other way around: she must start from the concept, from the learning she wants her scouts to achieve, in order to build a suitable experience which can exactly lead to the concept she started from.

This method, supported by other concepts like self-development and co-education (basically a concept of collaboration in helping each other grow), proved to be very much effective over more than 100 years, especially in teaching and learning skills like self-organization, leadership, ability to plan, collaboration, imagination, improvisation, dealing with uncertainties and the unknown, which ended up in being so crucial in the 21^st century industry.

What’s your opinion about that? Feel free to comment.

If you want to know or discuss more about this subject contact me on Linkedin, Twitter or Google+.

Gamification, Defer Commitment and Real Options

Last week we had a Scrum Master Gathering: 60 people from 8 countries and 5 different companies meeting to discuss and share thoughts about Agile coaching, one of the most challenging and yet the most exciting jobs in the world, during 2 days of learning, sharing and fun.

The first day was a full collaborative and self-organizing day, where everybody could contribute to the emerging agenda by proposing an Open Space about burning topics to share or issues they wanted help about from a fellow coach.

The second day was instead about Gamification and Learning Lean: a day of creative sessions to bring back home a number of brand new games to teach the Lean Discplines from Mary and Tom Poppendieck’s book. In fact true Lean Software Development requires that coaches help their teams achieve the necessary mind shift and find new ways of doing things. There is scientific evidence that one of the best ways to learn is by playing: that’s how kids learn and learn fast. And gamification is just the process of using game thinking and game mechanics to solve problems and engage audiences.

But creating a game is not easy; it requires a number of steps to define the main elements:

• What is the Goal of the game?
• Which Mechanics do you like to use? (e.g. levels, points, badges, mission)
• What are the Rules of the game? Are they clear and not ambiguous?
• How many Players does the game require?
• How much Time is necessary? 

A couple of us decided to pick a Lean discipline nobody had selected, being one of our favorites instead: Defer Commitment aka Decide as Late as Possible.

Inventing a game to teach this subject didn’t look so straightforward in the first place, but, being this discipline all around ability to keep your options open until the Last Responsible Moment and live with uncertainty, we decided to take inspiration from Real Options.

What are Real Options? I suggest you to have a look at this article to start understanding a bit more.

The authors explain that in the SW development world, we can learn the following from the Financial Option maths:

1. Options have value.
2. Options expire.
3. Never commit early unless you know why. 

Starting from these considerations, we created a game based on “Guess who?”

You know? The famous game where you must figure out the name of a mysterious character based on the information you manage to get by means of Yes/No questions.

Let me share how it works and the different components:

• Goal

The Goal is the same as the original game “Guess who?” except for having to reach it within a time box of 1 minute

• Mechanics

The game mechanics is based on Points: you start a round from a total of 40 points; each question is costing 5 points. If your answer is wrong you get no point. Who gets more points in 2 rounds wins.

• Rules
• Each rounds is time-boxed to 1 minute, which represents the Last Responsible Moment to take the decision and guess who is the character chosen by the other party
• You start from an amount of 40 points and can give your guess at any time before the 1 minute timer expires
• You can guess right away without asking any question: if you’re right you get 40 points
• Or you can ask how many Yes/No questions you want to get information about the mystery man within the 1 minute time-box. Each question costs 5 points, so if you ask only one question and you’re right with your guess, you get 35 points
• If you’re wrong, you get no point, so asking questions has a cost, but reduces the risk of failure
• All questions have the same cost, so it’s up to the asker find the proper question to maximize the amount of information and knowledge you can get

• Number of players

At least two: either individuals or teams

• Time

2 rounds of 1 minute for each player + 10 minutes debriefing at the end

The final debriefing is meant to let the players reflect on the game, conceptualize the experience and get all learning out of the proposed metaphor, i.e.:

• Exactly as “Guess who?” SW development is a discovery process based on the scientific method: make an hypothesis and verify it through empirical learning
• Options have an expiry date: the Last Responsible Moment
• Keeping your options open until that moment has a cost, but minimizes dramatically the risk of failure
• Since each experiment (like each iteration in Scrum) has the same cost, the key to get faster to success is always to run the most valuable experiment, the one which gives you more information 

Hope now you got curious to try it out. Let me know how it works.

Applying Agility to training and education

You know: I strongly believe that Agile values and principles apply and work very well whenever you have a complex problem to solve, something that you have never done before.

So, if you have a vision of what to reach, but do not know where exactly you’re going and your domain is not deterministic, there’s no chance you can define your path upfront: the most sensible approach you can try is to do one step at a time and strive for fast feedback to verify your assumptions and adjust consequently.

Therefore an Agile approach suit very well many different fields, even outside IT, given that people involved in solving the problem have the right domain knowledge. 

For instance, as a trainer, I use an Agile approach for designing and delivering my Agile and Lean courses to Product Owners, Scrum Masters, Teams and managers.

Last week I got interviewed by 4 students from a Human Resources Master (a psychologist, a sociologist and two economists) about my thoughts and experience on applying agility to training and education, which is actually a complex domain. The interviewers resulted to be very passionate about the subject and it was really an interesting 3 hours long discussion about many aspects.

I will try to summarize the outcomes here by using the same pattern we followed during the session: going through the values in the Agile Manifesto and try to understand how they can be concretely implemented in the domain of training development and delivery.

1. Individuals and interactions over processes and tools

We normally use a collaborative team approach (2-4 people) when designing a new course. We try to understand the learning needs of the client and ideate possible solutions that are pulled from the backlog and implemented incrementally by leveraging on pair working as much as possible. We use a task board to visualize the work and understand the progress.

We apply pair training for delivery and try to foster a collaborative approach in the class, where the trainers are mainly facilitators of people learning using different teaching techniques.

We use tools like working agreements to set a stage of ground rules for the class. Understanding is prioritized over delivery of a pre-determined content and physical tools and face-to-face conversation are preferred over other ways like web-based training.

2. Working software over comprehensive documentation

We try to get feedback as fast as possible as we proceed with the training design, by showing concrete examples of what we have in mind (slides, activities, other material) in order to validate our assumption and verify whether they match clients’ learning needs. That’s in contrast with detailing the training contents up front in a document and hoping to get feedback on that, where clients do not have necessarily the domain competence to understand and to map it with their needs.

We also think that learning is achieved by means of a complex recipe, where magic happens during live training delivery due to a combination of good material, inspiring activities, group collaboration and teachers’ skills. That’s why we do not aim at producing documentary or even self-explanatory material, which often gets the result of having neither good training material nor good documentation. Training should inspire, provide a vocabulary, create curiosity and new questions, which can best be satisfied on the web or by reading books.

3. Customer collaboration over contract negotiation

As I said, fast feedback is crucial. For that reason you need to get your client involved in designing the training with you. That’s why we engage an early collaboration which happens face-to-face when possible or remotely (via mail, chat or phone/video calls).

When our contact person is not the primary customer of the training, we try to get in touch as soon as possible with a number of training participants (when they are available) to interview and get a better understanding of their learning needs or even help to get themselves understand their needs.

4. Responding to change over following a plan

We try to keep our options open until the last responsible moment, both during course design and delivery.

We’re open to late requirement changes as much as possible, stated that they fit the allocated timing for the training and propose other items to down prioritize if we think it adds too much to allocate in the given time frame.

We divide the course in modules and monitor the progress of the delivery by means of tools like task board or burn-down chart, so that we’re ready to adapt. We follow a time-first planning approach: we always finish on time and if the timing doesn’t go as planned, we decide which modules to cut together with the class.

Looking forward to your comments, if you’re interested or have experiences in the field of agility applied to training.

P.S. Thanks Valentina, Lydia, Patrizia and Francesco for the awesome chat and all the best for your work.

Are you an Agile coach?

In the last 3 months, I met an incredibly high number of people, who call themselves Agile coaches: it looks like it is a fast growing family. For some reason when introducing each other, every time it is like a dejavu and it seems to me to hear the very same words: “My name is xxx, I am an Agile coach. And you?”

And this makes me smile every time, because it reminds me a tale from a friend of mine. 

When her sister was a child, they met a Great Dane: you know the huge dog, which size is more comparable to a horse than a dog?  

So her sister approached the dog and said: “My name is Carmen. I am a 6-years old girl. And you?

There’s a lot of misuderstanding about Agile coaching (as well as a lot of mystification around Agile, I hope I can write something about in the near future), but still in my view it is one of the most challenging and yet exciting jobs in the world, even if honestly or on purpose misled.

I will try to share what it is in my view.

Let’s start with the word “coaching”. It comes from the English word “coach” and gives the sense of taking a person from a point A to a point B. Myles Downey in Effective Coaching defines it as “The art of facilitating the performance, learning, and development of another”.

But an Agile coach (likewise as I said some weeks ago for an Agile manager) is not only a coach.

First of all in coaching it's the coachee to define the direction, like a “coach” doesn’t take the lead itself in defining where to go: it’s all about the coachee's agenda then.

On the other side, if you’re an Agile coach is not only about your coachee's agenda, it’s also about your agenda of teaching about Agile values, principles and practices, because you know by experience that they can improve their performances as individuals and teams by being and living Agile.

So an Agile coach is not just a coach (and even less just a facilitator), but he’s able to be a teacher and a mentor, when it is time help people who do not have enough tools to perform a certain task or solve a certain problem in the complex world of SW development or in the art of working as a performing team.

Then, while it is enough for a professional coach or a facilitator to master only coaching skills or facilitation tools, without necessarily knowing anything about their clients’ or team’s context, only first-hand experience and hands-on practice can give an Agile coach enough tools and credibility to give some direction when it is needed by the circumstances: you want your team to be off their comfort zone to be able to learn, but not too much to fall into chaos or panic.

And being a teacher is even a different job, where you need specific skills and practice different tools: that’s why you could have heard about “allied disciplines” as the tool set for an Agile coach.

But what should you exactly be able to teach, mentor and coach about? 

Let’s see what we can derive from the Agile manifesto.

1. Individuals and interactions over processes and tools

Encourage self-organization and collaboration: they are keys to success. Help them learn how to work effectively by means of experiment, fast feedback loops and safe failure. Help them see their conflicts and to choose what to do about them.

2. Working software over comprehensive documentation

Help people to get things done. Teach, mentor and coach on Agile technical practices, both individuals and teams. Stimulate a culture of SW craftsmanship in your company, based on mastery and apprenticeship, excellence and deliberate practice, ability to find solutions to always new problems.

3. Customer collaboration over contract negotiation

Teach and coach your company on Agile values and Lean principles, so that they can be more effective on the market. Have business and development like one team: teach them not to play the contract game inside the same company. Promote a culture of continuously creating learning, by means of close collaboration with the customer on the product.

4. Responding to change over following a plan

Train your team and organization to be able to keep as many options open as possible until the very last responsible moment and make informed decisions. Enable cross-functionality and e2e approaches to be more flexible to change. Coach your organization to always look at the big picture to focus on the most important stuff, validate hypoteses instead of blindly follow plans and change direction when needed.

And you should live yourself and role model the values and principles you would like your team or your coachee to learn: you cannot just be on stage.

For instance, challenge yourself the status quo and continuously improve: be soft with people and tough with processes, as Toyota teaches, starting with your own way of working.

So be the first to experiment, look for fast feedback loops on what you’re doing and reflect on the results. Continuously learn and practice new coaching and teaching techniques, be passionate and energize others. Be ready to share what you learned and contribute to local and global communities. 

Empower, be always there to protect your team and have the courage to stand for what you believe in.

You don’t work as an Agile coach: you ARE an Agile coach. Aren’t you?

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?