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