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.

Roadmap planning

As you might know, different levels of planning apply to an Agile SW development (actually, beyond what you can see in the picture, you have also the Sprint Planning and the Daily Planning).

It’s continuous planning with the different levels influencing each other by feedback both between levels and across levels in order to respond to changes. 

It’s a Rolling Wave Planning approach, where upfront planning is reduced to the minimum indispensable, to what is “just enough, just in time”.

As one can see, despite the myth about Agile meaning “coding with no planning”, there’s probably much more planning in Agile than in a waterfall approach.

In preparing for battle, I have always found that plans are useless but planning is indispensable.         

-Dwight D. Eisenhower

Last week we experimented a new way of Roadmap planning, aiming at understanding what will probably be contained in the coming releases.

So far this kind of planning had always been done mainly by the business guys, based on their level of understanding of customer requirements, their perception of the possible solutions and partly on wishful thinking.

This time we decided to do it differently, trying to take decisions or at least draw possible scenarios based on facts as much as possible. Once again the best recipe turned out to be a collaborative approach.

The decision was to call for a 4-hours workshop (it was actually 2 slots of 2 hours each) attended by the Product Managers, the Product Owner Team and a bunch of system architects.

The Product Managers brought to the workshop a list of prioritized requirements to analyze.

We decided to dedicate no more than a defined time-box to each requirement in priority order, so that we did not spend more time than strictly necessary at this very early stage of understanding.

The time-box was divided in 3 parts:

1.      1/3^rd to explain the requirement and clarify background and business value

2.      1/3^rd to sketch possible MMFs or epics

3.      1/3^rd to estimate the MMF or epics, a relative estimation using as a baseline the actual story points spent by our teams to deliver the MMFs in the last 2 releases

Everything was done collectively. After the workshop, given the number of sprints contained in the coming releases, the PO team did a date first planning, by considering the actual velocity statistics of our organization.

Based on that, we determined scope scenarios for the coming releases, considering the worst and the best cases in our recent history.

The feedback from participants and stakeholders both on the approach and the outcome was pretty good and I must say it looks very promising to me as an Agile coach.

At least it meant providing “just enough, just in time” information (even if rough) based on the current knowledge and understanding of requirements and above all on real data coming from our actual historical performances.

Daily Scrum or not Daily Scrum, that is the question!

A couple of weeks ago, back from Christmas vacation, I had an interesting view exchange with some Scrum Masters about what to do when the team is not motivated to have the Daily Standup. 

What I experienced is that, when the team argue the value of the Daily Scrum, most time it's because they misunderstood it.

Credit: Playmakers! Theatre School

They normally say: Why do we need a meeting to share what we're doing if we're sitting together all the time and know it already?
I would say that, from this perspective, they are totally right!

The point is that the Daily Scrum is not for the sake of sharing, but it has a totally different goal: stand back for 15 minutes and collectively assess where we are compared to our Sprint goal and collaboratively decide what is the next most important task each team member have to complete to move forward towards our goal.

So what I did in those case is to re-discuss with the team what is the real purpose of the Daily standup. That normally worked! I prefer to call the Daily Scrum as Daily Planning to make the real purpose more clear.

If that didn't work, I would name this as a good chance for the Scrum Master to wear his/her teacher hat and re-affirm the fact that the Daily Standup is a fundamental part of Scrum.

Here the Shu-Ha-Ri metaphor works perfectly.

BTW, are you familiar with martial arts?

If yes, you might know the Japanese concept of the 3 levels a martial artist goes through on his way to get mastery in his discipline.

In the first place, the Shu student goes to the master and simply observes and replicates the master's moves, even if he doesn't fully understand the concepts behind.

When he becomes a Ha, he starts to understand the principles behind the moves well enough that he can stop imitating the master rigidly and start trying different moves.

Finally, when he reaches the Ri state, he finally becomes a master himself: he has understood the principles of the discipline so well that he can shape new moves himself to adapt to new situations and can teach others.

So, it's essential for the Scrum Master to openly share with the team his/her feedback/advice that, since they're probably still in the initial (Shu) phase of the learning curve towards Agile, they'd better follow the practices suggested by Scrum and give them a try for a certain amount of period, even though they do not understand them completely. 

When they fully understand the underlying Agile principles, they can dare and break the rules.

A good compromise here is to suggest to keep the Daily Scrum and stand-up anyway at the agreed time: if they are happy about the daily planning for every team member and do not have anything to add, they can sit down after 1 minute. 

You will see they normally take the whole 15 minutes instead 

A final option could be a healthy safe failure approach, which normally works with kids as well as with teams   

How to build a big product in a collaborative way – 2

In the last post we said that the PO Team’s job is to collaboratively develop a unique Product Backlog to feed all development teams.

So: how do we do that?

Look at this picture.

We basically do it iteratively, so that at each step we do the cheapest possible amount of work to verify our assumptions, get fast feedback and take a business decision together with our stakeholders: whether continue more or less on the assumed path or rather pivot (or even drop the development).

Given a customer request or a business opportunity, we start writing a Vision of what we’re going to develop (a pitch to explain what we’re going to do and why) and eliciting requirements in terms of needs and problems to solve.

We do it together with all involved stakeholders to be sure everyone is aligned. The requirements are then prioritized and basically divided in 4 categories: must have, should have, nice to have and must not have.

So far we stay on purpose in the problem domain and not consider the solution yet: in order to find the right answer, it’s better to spend time finding the right question.

And whether the question is worth being answered indeed.

The next step is to make a quick architectural analysis and try to identify a possible structure of MMFs (Minimum Marketable Features), which makes sense for the highest priority requirements. This requires again a collaborative approach with stakeholders and, if the team does not have all the needed domain competence, a PO pairs up with a system architect to get some help in the high level solution sketch which will inform the coming backlog preparation.

At this stage, a first cost estimation is provided: a relative cost estimation in story points, having actual efforts of already developed features as baseline.

MMFs, for which business opportunity is still considered valid at this point in time, become part of our global Product Backlog and represent items which can be pulled by any PO in the team to be worked upon and produce more detailed items in a hierarchy from epics to really INVEST User Stories. Pairing within the PO team and involvement of development teams, as well as collaboration with people from QA and Customer Support, help build high quality backlog items as a necessary condition to be able to build a high quality product.

The cost estimation is refined iteratively, leveraging on estimation from development teams actually doing the work.

A release plan is also provided, either as scope first planning, leading to provide a possible lead time interval, or a date first planning, leading to a scope scenario interval. The release plan is updated at the end of each Sprint taking into account historical data on team velocity and possible re-estimate, give the newly built knowledge in the iteration.

Daily work on the different global backlog items is followed up during a 15-min standup and work planning for the coming day is collaboratively agreed, considering which are the most important tasks to be accomplished to come closer to the project goal.

Next time we will have a look at how we groom and we order the global Product Backlog, so that the whole organization, including the PO team, is focusing at any point in time on the most important items.