The 21st century´s paradigm to connect people and work to be done

Few days ago I had a phone call with a friend of mine. During our conversation she shared with me one of the challenges she is facing at work and wanted to check what I might think about.

Basically they have few issues when it comes to allocating people to work on a project they sold to a customer.

The challenges are multi-faceted:     

• Finding people with the competences which fit that specific project
• Finding people who are available to work on that project
• Finding people who are willing to work on that specific project

Now the sweet point would be: a reasonable amount of people with the right competences, who are available at that time and willing to take on the project.

Very hard! Almost impossible! So what is usually the second best option?
Right! Put together on the project just who is available at that moment in time and hope it will not turn out too bad until someone with the right expertise can join and save the boat.

Does it sound familiar? I am sure it does, if we live in the same world.

But I have a second question: any guess what my friend’s job is?

Well, if you are thinking about anything among Project Manager, Development Manager or SW developer, you got it wrong. 
She is an architect: not a SW architect, a “real” architect.

If the fact that an architecture office might have similar problems to any product development company sounds unexpected to you, you have not considered the fact that the nature of the work is substantially the same in both fields: solving new problems which have undefined boundaries and multiple possible solutions within a complex environment where multiple entities influence each other in unpredictable ways.

To me this is just another confirmation of a pattern that I have seen in all organizations coping with work of such a nature and trying to apply traditional patterns to solve this challenge in the current century.

Can the situation be slightly improved by applying those patterns more efficiently? Probably yes and the PMI might have few ideas around that.

However my experience tells me that the problem cannot be solved if we do not embrace the fact that a totally different paradigm is needed.

Why?

• Customer requests are more and more unclear: they do not know what they want. Problems are wicked: there is no pre-defined answer
• Market is becoming more volatile: new and unexpected needs are emerging which require flexibility in companies
• Professions are more and more specialized. Too many individuals I-shaped skills, which means they have deep knowledge and experience in just one area
• Work is done in silos: lack of holistic view by individuals, but also knowledge domain in many professions is so big that is impossible for a single person to know-it-all
• Having parallel projects competing for human resources is not sustainable anymore in the above context
• Having people working on multiple projects reduces their effectiveness and productivity: context switching makes people waste time and produces stress, which can reduce IQ by 20%

So what is this different paradigm all about?

• Understand the flow of value you create and setup stable, 100% focused, self-organized teams with a shared goal around your value flow
• Bring highest value work to teams instead of allocating (or multi-allocating) people to work
• Having the team as the atomic element simplifies allocation very much
• Focusing on getting the most important thing out as fast as possible instead of focusing on making people busy (flow efficiency over resource efficiency)
• Teams must be cross-functional: they must have all the competence needed to get work done
• The holistic view of the work is kept at team level
• It is too much to know for a single person. Individuals should better be  “learn-it-all”*
• They can act more effectively on new wicked problems to solve: diversity beats expertise in complex domains
• Move from I-shaped individuals to T-shaped or even X-shaped professional who can do more things, so that you can have smaller teams with all needed competences
• This can be partly achieved through synergies in teams, but also having the expert teaching to the others, to reduce the bus factor

Dare to take the journey? Do you have enough courage to address your own problems?

*In her book “Mindset”, Carol Dweck talks about the following concept: if you take two people, one of them is a learn-it-all and the other one is a know-it-all, the learn-it-all will always trump the know-it-all in the long run. See also what Microsoft CEO Satya Nadella said in an interview last year about his effort to overhaul the company culture.

The User Story Workshop

User Stories in Oxford by Jacopo Romei / CC BY 2.0

What can you do when you need to write a considerable number of User Stories in a very short timeframe?

Why a User Story workshop? 

It is a useful tool to achieve the goal of writing many stories fast, especially when the development team has a lot of technical knowledge, or there is a lot of knowledge outside the team to be used to complement Product Owner’s domain knowledge.

What is a User Story workshop? 

When starting a new Release, I suggest to run a a workshop with the Product Owner, the Development Team(s) which will build the specific product and all people who can contribute, regardless of their role. 
The goal of the workshop is to come out with as many User Stories as possible, which can solve the problem(s) represented by a given number of requirements.

How to run a User Story workshop? 

Here is the structure I usually propose:

1. The Product Owner presents the goal for the next Release and the most important requirements. This normally takes about 1 hour: participants normally ask clarification questions

2. Participants are split in groups of 4-5 people and we do a number of (usually 3) 1-hour iterations structured like that:

2a. Group brainstorming to elicit as many stories as possible (30 min)

2b. Group work integration, where groups review each other work, find similarities, remove some stories, etc. (30 min)

The next iteration might continue on the same requirement or on a different requirement. Sometimes I tried other creativity techniques besides simple brainstorming, like Lateral Thinking techniques, e.g. the anti-solution.

Especially if it is a newly formed team, not so used with writing stories, I provide a pattern to follow to brainstorm stories.
 I ask the team to look at the system from outside-in and ask themselves who, what and why:

- Who is the user who will benefit from the specific function?

- What is the function which might contribute to solve a certain problem?

- Why is that function needed (to solve which problem)?

My experience

Generally speaking I found the User Story workshop very effective: it helps the team focus on the goal and make an efficient use of all brains around. You can easily write 50 User Stories of different granularity in 4 hours: sometimes more time is needed to achieve the intended goal, but I always prefer to start with no more than 4 hours and have other sessions if needed.

Learning

In order to make the US workshop effective, the people involved should have been trained in what a User Story is and how to split the work in small slices which cut the system vertically and allows building an iteratively evolving product which continuously stays shippable. 
When needed, I propose and facilitate a very effective workshop to teach how and why splitting a product in small vertical slices: the Elephant Carpaccio exercise invented by Alistair Cockburn.  
I do recommend these 2 hours of learning, engagement and fun.

What is preventing you to try it out tomorrow? 

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!

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!

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!