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?