How to build a big product in a collaborative way - 1

What happens when you have a product too big to be built by one team within the timeframe needed by your business?

You might answer: Well, I allocate more teams and then create an organization structure where each team is accountable for their part and with a project staff, headed by an expert project manager, to coordinate everything.

I do not want to judge this answer. However let’s have a look at the Agile principles:

• Business people and developers must work together daily throughout the project.
• Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done
• The best architectures, requirements, and designs emerge from self-organizing teams.

What do I get out of this??

Well, first that SW development is a collaborative game by its nature: there’s no complex problem which can be solved by one person in a time which is compatible with modern business needs.

Secondly that self-organization and servant leadership are some how embedded in being Agile.

Furthermore, if you look at Scrum, you will find only 3 roles: Scrum Master, Product Owner and Development Team.

I'm sorry: no project manager whatsoever.

Beware! I’m not talking about people here: there are plenty of great project managers serving with passion and competence their organization. 

I’m rather referring to roles and their effectiveness in an Agile context, in terms of: What is the probability I might have success in an evolving reality?

Said that, what I would suggest to a Scrum organization is to setup a Product Owner Team.

Yes: a self-organized team formed by all development teams’ Product Owners collaboratively working together. And I’m suggesting that, because I’m currently coaching a PO Team and I would like to tell my experience through this and some other post I’m planning to write.

Of course a team does not make sense if they do not have a product to build: the PO Team’s job is to develop a unique Product Backlog to feed all development teams, so that the following is ensured:

1. the whole organization is focusing at any point in time on the most important items
2. the development teams are as much independent as possible so they can move fast with little need to coordinate each other
3. the overall architecture of the system is preserved 

Like any other Scrum team, a PO Team might better have a Scrum Master or Team coach (it’s just me in our case) and a Product Owner, who is in charge to give a final word on the overall priority in case of conflicts.

To tell you our story I will start from the beginning and that’s the team setup.

In a recent post I described how it is important for a team’s success to set the stage to high performance and that’s just the same crucial if we’re talking about a group of normally quite senior people who need to learn how to collaborate for serving the entire organization at best, instead of only cultivating the silos they felt responsible for.

And we really started from the foundation by writing together our team vision and the ground values we wanted to build our team upon, as you see in the pictures below. After few months I really recognize that this exercise had proved to be tremendously effective.

So we set the first draft of our working agreements.

Since I wanted to introduce the Scrum values in the team in an organic way, I let them decide completely how to organize in the first place and here come our ceremonies:

• Global Backlog grooming once a week
• Global Release planning once a week
• 15-min daily standup everyday
• Review of work done at least by another team member according to our Definition of Ready
• Team retrospective once a month

I will describe each of these ceremonies, make you see our awesome task board and tell you how we build our backlog starting from customer needs in a number of coming posts.

Talk to you soon!

Cultural transformation through deliberate practice of behaviors

This week I was at LESS2012 conference.

The conference overall was really interesting and I would like to start right away to share with you the 3 most inspiring things I brought home with me from the sessions I attended.

1. The first one is from Jurgen Appelo’s keynote.

The whole performance rocked as usual, but I'm sure you will agree that the following concept is really great. He said that the verb “Manage” come from Italian “Maneggiare” and from French “Menage” which originally meant “drive and take care of horses”.

So Management is actually driving and taking care of organizations as they were living beings and they are indeed. That’s why management is too important to be left to managers: we must all lead.

2. The second great quote is from Beyond Budgeting track hosted by Peter Bunce (Chairman of BBRT) and Bjarte Bogsnes.

They echoed Steve Jobs saying: I discovered that sometimes the best innovation is the company, the way you organize the company. 

We need a more self-regulating way of management. We all agree in principle with this, but the problem is bringing this to practical consequences.

Most companies say or write that, but the problem is what we do, not what we say.

There are most times gaps between what we say and what we do and this gap is poison for the organizations.

3. Last reflections come from the other 2 keynotes.

Christopher Avery pointed out that traditional managers are always looking for single point of accountability, but collaboration does not work with single points of accountability.

Esko Kilpi added that from a social business standpoint, the individualistic view is fundamentally misleading: there's co-creation. So is the sense of personal responsibility. The new competitive edge will come from openness, transparent information and collaboration.

Awesome, isn’t it?

On the last day I held my workshop Learning to be a manager in the age of Agile.

The question I put was just the following.

If all the changes above are needed in 21^st century management, compared to current mainstream management (still focusing on the very same practices invented more than 100 years ago with totally a different goal than making our companies responsive, adaptable and innovative), what is a feasible path to get there?

The proposal I made is based on 3 steps:

1. Challenging current management beliefs
2. Challenging your actions in the light of Agile and Lean principles
3. Deliberate practice of functional behaviors in line with the principles

The idea is to break the maps wired so far in our brain by all experiences and beliefs in our life and which we follow naturally like a river bed to interpret the reality. Then build instead, drop by drop, new side river beds, which could allow us to see the reality with new eyes and act accordingly.

After the conference I had the pleasure to discuss this approach with Dawna Jones, who very well pointed out how just focusing on behaviors allows to achieve only short term and not permanent cultural changes.

I agree this is very true and indeed in line with the approach I suggested. Deliberate practice of behaviors (like deliberate practice of technical skills) and continuous self reflection are just ways to understand the values behind. This will allow behaviors to become habits and enter deeper in our brain and heart to create new beliefs, new assumptions, new structures and ultimately a new culture to provide different responses to our evolving reality.

It’s the management Shu-Ha-Ri!

Wearing the right glasses

Last night I made a strange dream.

I was tiny small, while very big words were flying around me and suddenly thrown in a gigantic mixer, which put them out in a changed order, building completely new sentences.

Different kinds of sentences and words were undergoing the mixer and came out changed.

Among the others I saw the 7 Lean Disciplines: they came out of the mixer like this.

- Eliminate quality

- Build Waste In

- Create Knowledge

- Decide as early as possible

- Deliver as late as possible

- Respect the whole

- Optimize people

One of those sounded familiar to me, but the rest? 

Am I seeing right? Am I wearing my glasses?
Were they changed to the "The Fat Disciplines" instead? Was it a dream or a nightmare?

I woke up sweat in the early morning and started reflecting with myself.

I got to compare the Fat versus the Lean Disciplines to evaluate, not which are the most effective, but simply which are the most sensible to really manage the business we're in.

The life would be great if I could give a specification to my team and ask them to commit as early as possible that the project will cost 96.356,55 EUR and will be delivered exactly on October 20th, 2013 at 12.45. Why can't I do that?

Well, just because that's the life.
Most of us might have experienced a certain degree of comfort in having a detailed plan in place and believing to have everything under control...
...no matter if the plan turned out to be no longer valid maybe just the day after.

Yes, but that would be developers' fault who were not precise enough with the planning or want to cheat me. And by the way, they are tremendously lazy.

No, it's just because building SW is a complex system made by teams of people which are a complex system as well: you do not know your final destination and the system is non linear, so how can you predict the exact steps to reach it or when exactly you will land there?
Complex systems have their laws (smell some flavour at here) the same as we are subject to the law of physics.

So why can't I simply decide a plan and stick to it?

Well, because complex systems are not deterministic: things change, there's not full visibility of the whole path, knowledge of the system increases on the way and new things emerge. Having quick feedback loops is the only way for you to learn as fast as possible.

Mike Cohn tells how Trond Pedersen very well describes this subject: "Complaining about requirement change is like complaining about the weather. You can't really change how the world is, but you can find ways to deal with it. Don't make an offering to Thor (the Viking god of thunder) to make the rain stop: get an umbrella".

So it's only your risk if you get an umbrella or not.
It might sound a bit less comfortable, since we must learn to live with some level of uncertainty, but isn't it just more sensible?
And maybe a bit more scientific...

Reflecting around, it was finally time to get ready and go to office. I made sure I get on my glasses.

We might not talk about Agile and Lean in 10 years any more, but they are definitely the glasses to wear to see and understand our business now.