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.

A conversation with the CIO community

Leadership quote by photosteve01 / CC BY 2.0

Last June I had the pleasure to get my interview published on Netweek, the biggest magazine for the Greek CIO Community (the Greek IT Managers are both readers and editors). 

I am thankful to George Fetokakis, Editor-In-Chief of Netweek to make it possible and for the interesting questions.

Since I realized that the interview was only published in Greek, I decided to post it here in English and share it with a bigger community.

Trust you will find value in it.

Looking forward to your feedback and comments.

1. How did you get started in the Agile world?

Interesting enough, I actually started my Agile journey in Greece. At the end of 2009 I got the chance to be part of kicking-off the Agile transformation in a big development organization of around 2000 people. So I got to spend 3 months in Patras, together with other 18 apprentice coaches from all over the world and 9 consultants among the most knowledgeable Agile coaches and trainers at that time. Every single day of those 3 months was an incredible learning experience and that still remains the most exciting and fun period in my professional career. Which better place to start a life-changing journey than the place which gave birth to the Western culture?

2. What does success mean for you in this world? 

In my opinion success in this context for a company or an organization means: effectively leveraging on Agile values and principles to achieve your specific goal sustainably in the fast changing world we are called to live right now.

For a development team success means delighting your customer with products that actually solve their problems. For me personally success means contributing to transforming our world of work in something more meaningful for human beings.

3. What are the top skills that an effective Agile coach should have?

The two coaching skills which helped me most in my 7-year experience as Agile coach are: empathy and situational awareness. Empathy is a crucial skill for coaches and leaders.

I learned that people want to feel themselves valued and appreciate when someone is truly listening and not judgmental. This doesn´t come easy: it is a skill to practice to be able to listen for potential, namely listening to people not for what they are, but for what they can become in the future and be committed to help them become the best they can be.

With situational awareness I mean the ability to be really present, observe carefully and understand what is going on around you: the ability of “reading the room” or “smelling the room” beyond what is said.

4. How Agile (and Scrum) has changed the way that the developers think and work?

Agile and Scrum are incredibly effective change engines: they trigger a paradigm shift in everything. Not only in how we develop products and services, but in how we lead, in the way we collaborate with each other, in the way we interact with customers, in how we consider ourselves as professionals. Embracing agility means embracing continuous change, which in turn simply means embracing reality. Someone said: life is what happens while we are making other plans. Believing that things will stay still just to please our plans is the ultimately insane wishful thinking.

5. Scrum is simple but not easy.  How difficult is to make a company Agile?

Being simple is definitely one of the strengths of Scrum but also one if its pitfalls: it is so simple that many managers fall into the trap of believing it can become a magic wand for the company´s problems. A famous quote from Ken Schwaber, co-inventor of Scrum, is: “Agile development will not solve any of your problems. It will just make them so painfully visible that ignoring them is harder”.

And that´s where the tough part starts! Scrum is not plug-and-play! It´s not just a SW methodology upgrade. It changes some of the basic assumptions about how products get developed! It´s like installing an iOS 9 app on an iOS 4: it won´t work! You need to upgrade the Operating System! Only courageous leaders, who are willing to make an impact, dare to start the journey to upgrade their company´s operating system.

6. What should companies do to achieve a successful transformation in the Agile world?

The first step is about asking “Why?” What is the problem we are trying to solve? There must be a clear need for any improvement change: imagine how crucial it is to start off such a dramatic change. So any successful Agile transformation implies a top-down approach, in terms of Company values, leadership culture, business goals and management support. However, there are aspects that need to emerge bottom-up, like practices to be selected by self-organized teams. It has to be a sandwich strategy! Given the importance of the top-down part in the enterprise change, one of the initial steps is to educate managers, for them to understand the why, be able to share and communicate the vision, embrace Agile values and be ready to support people with a new leadership style. Many times this critical step is down prioritized, if not even neglected.

Finally it is extremely important that teams are organized so that they can deliver value to customer as fast as possible, replacing functional teams organized around the system architecture. Effective teams are cross-functional and have all the competences needed to transform a backlog item in a product increment within one Sprint.

7. What words of advice would you give to people who are just getting started with Agile themselves?  

Every context is different: so simply copying from others will not work. Scrum is a good way to start, it is a great teacher: if you have never tried Agile development, Scrum can give you the framework to be able to start. At the same time, you need to know many things outside Scrum to make Scrum work effectively: having an experienced Agile coach to guide you through the first challenges can be a key differentiator between success and failure.

8. What are the biggest challenges that they have to confront, what are the biggest mistakes that they should avoid?

I have seen few recurrent failure patterns: Product Owners without authority, knowledge or time, superficial knowledge and lack of coaching on Agile practices and principles, complacency as opposite to a culture of continuous improvement. Well, avoiding these failure patterns is one of the biggest challenges to confront. One of the biggest mistakes is considering Agile as something to implement: Agile is rather something you are or can be. Agile is an adjective, not a noun.

9. What should people and teams do to make their workplaces and lives more productive with Agile and Lean?

There are few things that helped me become more productive and I have seen also helping individuals and teams I have coached:

• When you have a question to answer, spend time in understanding the question before jumping to the answer.
• Do not make assumptions: genuinely ask why. If you have to make assumptions, try to validate them as soon as possible.
• Challenge how things have always been done.
• Work on your strengths, more than your improvement areas.
• If you wish to succeed at anything, have a clear vision of what you want to achieve and consistently take baby steps in the right direction.

10. Where do you see things going to Agile in the future? What changes are coming?

I see contrasting things. From one side I see more and more “Agile” instances which have nothing to do with agility, where people and especially managers have lost or probably never got the original meaning of Agile manifesto: where, for instance, individuals and interactions are in service of processes and tools rather than the opposite. This can be also considered a normal evolution. When an innovation reaches the hype, it starts getting late majority or even laggards in the game: they probably accept Agile just to look fashionable or to please their boss. On the bright side I see a convergence of researches, theories, methods and practices coming from really different domains (Entrepreneurship, Neuroscience, Psychology, Finance, Management, Non-profits, even Military and Government) which are collectively creating a very visible red thread. And this red thread is all about coping effectively with fast change by using an empirical approach, embracing individuals as whole human beings not as resources to exploit, being mindful, decentralizing power, and creating meaningful relationships. That´s really exciting and resonates a lot with agility. On a broader scale, our generation is experiencing a growth in our consciousness as human race (let’s take for instance social responsibility) and that´s going to create benefits not only to our industry but to the entire world. 

Installing Scrum effectively: Upgrade your company´s Operating System!

Magic Wand by photophilde/CC BY 2.0

Scrum is simple but not easy!
I'm sure that those of you who had seriously tried Scrum can recognize what this sentence really means.
And being simple is definitely one of the strenghts of Scrum, but also one of its pitfalls: it is so straightforward to understand by managers than most fall into the trap of believing it can become a magic wand for the company problems.
Sometimes without even reflecting about what the company's problems really are!

Ken Schwaber, co-inventor of Scrum said once: “Agile development will not solve any of your problems – it will just make them so painfully visible that ignoring them is harder”.

Missing operating system_ {error message} by Karl-Ludwig Pogemann/CC BY 2.0

And that's where the tough part starts!
Scrum is not plug and play! It's not a simple upgrade of the SW methodology currently in use in the company! It changes some of the basic assumptions and thoughts about products get developed!
It's like installing an iOS 8 app on an IOS 4: it won't work! 


You need to upgrade the Operating System!

I would like to share with you what I learned to be three fundamental upgrades needed in the company´s Operating System to install Scrum effectively.

1. Cross functional teams self-organized around value delivered to customers

It is extremely important that development teams are organized so that they can deliver value to customer as fast as possible and not around technology or internal product structure.

You do not want to have unproductive teams overwhlemed by thousands of dependencies, right?
You do not want to create unnecessary coordination work and increase your overhead, do you?

So move away from micro-managed functional teams organized around your system architecture: you will heal your company!

Effective teams are cross-functional and have all the competences needed to transform a backlog item in a potentially shippable product increment within one Sprint.

They work together to remove waiting times and handovers, which represent waste of time and knowledge. 
This does not mean at all having a team of generalists. It means instead having a team of specialists with T-shaped competence, so that they can contribute in doing the work when necessary, even in knowledge areas different from the one they are specialized in. 
Cross-functional teams learn continuously from each other's skills and share knowledge inside the team and between different teams.

These teams must be self-organized: they are the ones who have the best knowledge and must be empowered to decide how to do the work and continuously adjust their process.
A cross-functional and self-organized team can have the possibility to look at the whole development process, find the weakest link or the bottleneck at hand and do whatever they see as necessary to fix it. They have enough visibility of the whole to avoid sub-optimizations typically happening in traditional environments.

2. Agile Leadership

In an environment where teams are empowered and self-organized, leaders stop taking project decisions or asking for review and status report.

They focus instead on removing impediments, aligning stakeholders, building a trust environment, coaching, providing feedback, developing people’s skills and building the capabilities of the organization: they basically create the conditions for the teams to perform at their best.
They cultivate skills of servant leadership, are empathetic and willing to help.

This is applicable with different flavors to managers, Scrum masters and Product Owners.

• Scrum is enabled by managers who build a culture of discipline and excellence, guide on principles and values instead of giving complex rules to follow, teach people not to cut corners, challenge people to high performance and lead by example. They empower people to choose how they want to work and give room for experiment and safe/fast failure. Good Agile managers stay close to the teams and Manage By Walking Around and Listening.
• Scrum is enabled by full time Scrum Masters who have a very good knowledge of Lean, Agile and Scrum and can coach the team to apply Agile values and principles. They teach and coach them to challenge the status quo and continuously improve, think and work as a team, collaborate and challenge each other to grow.
• Scrum is enabled by Product Owners who clarify the Why? and the What?, but not the How? Therefore they trust the team will work at their best. At the same time they challenge and support them to continuously improve. Good Product Owners paint the big picture for the team to take responsibility of the product as a whole and actively support the team to find ways to connect with the customer. They take the responsibility to act as a unique interface to the organization for any work request towards the development team and protect them from interferences.

It is a lot about being more than doing. See also 3 necessary management mindshifts in a fast changing world.

3. Well groomed backlog

People might be arguing about what a good Product Backlog is, but here is what definitely a good Product Backlog is not (but far too often seen around): a generic list of work items which are not user centric, not split end-to-end, not estimated, not even always prioritized.

A high quality Product Backlog is an enabler for iterative and incremental delivery of high quality potentially shippable product increments, which is the core of Scrum (Garbage In-Garbage Out theory applies in this case). It helps the team focus on the right things and build them faster.

A high quality Product Backlog is a manageable size, living artifact of Independent, Negotiable, Valuable, Estimable, Small, Testable (INVEST) User Stories.

Such stories are easier to understand for the team, easier to plan and easier to work, so that the team can be more productive.

INVEST stories allow:

• Minimize the risk that the team does not deliver anything at the end of a Sprint. 
• Faster learning and faster development because the team gets feedback and finds problems earlier. 
• Better prioritization and defer decision due to a shorter feedback loop. 
• Deliver value more often and therefore can make customers happier. 
• Teams to be more focused and more motivated, because they feel a sense of velocity and accomplishment.

Where do you think you should start first in your OS upgrade?

The metrics enigma - 2

Second part of guest post from Mauro Bagnato about organizational metrics. Enjoy!

In my last post The metrics enigma I tried to look at the metrics from a different perspective, starting from the method proposed by D. Hubbard in his fantastic book How to measure anything. In order to turn these insights into practice, I arranged a four-hours workshop with the whole leadership team. Main goal was to share knowledge and to come up with a bunch of brand new organization metrics.

This “clarification workshop” was arranged in the following way:

Step 1. Learning&sharing. 1 hour.
Goal of the first timeslot was to introduce a new way of looking at metrics and share insights and reflections. Definition, purpose, risks and incentives were on the agenda.

Step 2. Understanding why. 30 minutes
The second timeslot was dedicated to the WHY. We tried to answer the question: “Why do we need metrics?” After a very interesting and intense brainstorming session, the leadership team came up with this answer: “We need metrics because we want to understand if we’re improving”. Good start, clarifying the purpose helps tracing the direction to get the metrics we really need.

Step 3. Undestanding what. 30 minutes
The third timeslot was focused on the OBJECT OF MEASUREMENT. Now the question was:” What are we going to measure?” Well, starting from the why found in the previous step, we just needed to measure the improvement. Unfortunately the word improvement was definitely something too vague and hard to measure, unless we had been able to turn it into something tangible. “What does improvement mean for us?” or better “Let’s suppose to be able to clone our organization and instill in the cloned one a massive dose of improvement, while holding the amount constant in the original one. What change do you imagine you would actually observe in the cloned organization?”. Those questions triggered an interesting discussion ended up with the statement: if we want to understand whether our organization is improving or not, we need to observe certain dimensions: delivered value, external perception, learning, innovation and climate. Now we had five objects of measurement even if they still needed further clarification to be measured.

Step 4. Metrics definition. Two one-hour iterations
The fourth timeslot was focused on turning each dimension into metric. In order to facilitate the discussion and to work on more items in parallel, I split the leadership team into two groups and asked them to go through a four phases discussion. The following picture describes the proposed logical path.

If we are able to turn each dimension into something really tangible, it should be easy to directly derive the metric…basically this was the main idea. For example, if innovation meant generating ideas only, we could assume that measuring the number of ideas would tell us how innovative we are. Thus we must understand the meaning of innovation first. In other words the further clarification phase (see the picture) means keep repeating the actions in the step 3 till the vague concept of innovation becomes tangible.

A deep clarification of the object of measurement should lead us to the metrics but… how can we check if those metrics are really good? Did we consider all the aspects? Did we miss something? Next “control” phases in the path help answering those questions. Before going deeper into those phases, we need to make some reflections first. Let’s start from the assumption that measuring means getting information and that getting information requires a certain investment. The amount of this investment should be tied to the importance of the information. Since the reason why we collect information is that we want to reduce the uncertainty related to a certain decision, then the importance of the information is directly related to the relevance of the decision we need to take. (in the financial context reducing the uncertainty related to an investment decision could save a lot of money). Starting from these considerations, the phase 3 requires to answer the question: “which decision does this measure inform?” or in a different way “do we really need this measure?”.

The last “control” phase comes at the end of the chain. Setting a metric in itself inevitably influences people behavior in ways that may or may not be the intended outcome. Here is an example of possible side effects or incentives a metric may produce. Let’s assume that the metric used to monitor a help-desk performance is the number of handled calls. This metric may generate the side effect that help-desk workers are encouraged to conclude the call as soon as possible without solving the problem. In this case the real outcome (side effect) of the metric is far from the expected benefit. On the other hand if the metric was the customer feedback collected at the end of the call, then help-desk workers would be encouraged to give the best service possible to their customers.

It was interesting to see that only few of the metrics found at the beginning of the path, passed the final control phases!

The outcome of this intense, tiring, but interesting workshop was a bunch of metrics related to two dimensions only. Yes…we didn’t manage to complete all the work, but we learnt together how to tackle the metric problem in a different and structured way. We found out how to solve the metrics enigma!
It was a collaborative work of the whole leadership team that gained the fundamental result of building a shared vision around the metrics.

The metrics enigma

This is the third post I host from Mauro Bagnato: my friend, if you keep producing at this rate in 2014, I will be gladly forced to open a special column for you!

A hot issue is touched this time: organizational metrics. The ones among you who are constantly reading (R)Evolutionary Agility know that I wrote already an article about this subject and I have plans to write more about it. 

Whether you celebrate Christmas or not, I wish you all restful and peaceful season’s holidays!

I’ve been struggling against organizational metrics for almost two years.

I must say that it’s a bit frustrating to look for a reasonable answer to the question: “which are the right metrics that an Agile organization should have?” and get the feeling to be very close to the goal, but without being able to hit the target!

These days I recalled a famous quote from Charles Kettering saying: “A problem well stated is a problem half solved”. It made me reflecting. 

Couldn’t it be that it’s so hard to find the solution of the metric enigma just because of the wrong question? Got convinced about it, I decided to start from scratch and to ask myself: Why do we need metrics?

Here you are the answers which came up in my mind.

We might need metrics because we want to:

•  find the evidence that the Agile transformation is worth the investment
• understand if we’re improving
• understand if we’re getting closer to our vision
• show our stakeholders we’re a fantastic organization
•  etc. (I could go on…)

This approach looked promising. Clarifying the purpose traces the direction and helps identifying the metric we really need, the ones linked to our goal. So far so good I’d say!

And now? How to move further? How to turn this goal into metrics? How to measure something so vague and undefined like stakeholders’ perception, improvement, ROI of the agile transformation etc.? In other words, how to measure intangibles?

The answer, or better, the method to measure this kind of things is described in the book “How to measure anything” from Douglas Hubbard. This very interesting book proposes a three steps way to measure intangibles:

1. Concept of measurement. What does measurement means?

Usually measurement is thought as the process aiming at quantifying something or giving something an exact value. This common conception implies that measurement means reaching a sort of certainty (numbers or values are expression of certainty).

This idea fits very well with the measurement of lengths, widths, etc. but when it comes to the intangibles (like happiness, empowerment or motivation) it doesn’t help a lot.

Scientists use a different definition: A measurement is a quantitatively expressed reduction of uncertainty based on one or more observations.

This definition introduces two interesting points:

·     Measurement is no more connected to the idea of certainty but is defined as reduction of uncertainty.

·     It’s possible to measure anything (intangible or not) observing the impacts, the effects, the results.     

2. Object of measurement. What do we have to measure?

Even using the new definition, something could still seem immeasurable simply because the object of measurement is not clear or is not clear enough. Very often clarifying the meaning of what we want to measure makes the problem much easier. What does it mean? That’s the fundamental question to answer.

How to measure happiness? One million dollar if someone is able to find the answer!
Let’s try to change perspective and decompose the problem by answering the question: What does happiness mean? For me happiness means having enough time to dedicate to my family and to my hobbies. Measuring the time spent that way gives me an indication of how happy I am!

I found something measurable to observe reducing the uncertainty related to the measurement of happiness!

It might happen that the answer to the fundamental question is still something intangible. In this case the trick is to repeat the question till the answer is become something measurable.

D. Hubbard suggests also a different way to clarify the object looking at the effect or the consequences: Let’s suppose to be able to clone someone and to be able to instill a massive dose of happiness in the cloned guy, holding the amount constant in the original one. What do you imagine you would actually observe that would change for the cloned guy?

Whatever the method, once the object of measurement is clear, it’s possible to find the way to measure it.    

3. Methods of measurement. How do we measure?

I’ll not dig too much into this point but D. Hubbard suggests to make use of whatever methods of measurement based on:

·     Sampling. It simplifies a lot the process of measurement. We need much less data than we think to get a valid measurement.

·       Experiment. Anyone can develop an intuitive method for measurement and the best approach is to try it and learn from it.

Let’s come back to the starting problem and see if the method works. Assuming that we need metrics because we want to know if we are improving, next step is understanding what improvement means. Assuming that improvement means delivering more value, now we need to understand what delivering more value means. Assuming that delivering more value means delivering what customers really need, what happens when customer have what they need? Assuming that when customers have what they need, they simply use it, we could start observing how many customers really use what we deliver.
We got the object of measurement! Now the point is how to measure it? How many data are we going to collect? Making a sampling of the customers could simplify a lot the measurement itself without compromising the results (see “The rule of five” proposed by D. Hubbard).

It seems we got the point but…could we get there without wasting our time with all this stuff?

Before answering the question, we should consider that the outcome of this method is not only metric itself, but mainly the path to get there. Questioning the need (what we want to achieve), decomposing it reflecting on its meaning/effect and then finding what to measure, builds a sort of picture communicating:

• what we want to achieve
• how we want to achieve it
• What we consider important, what we care of.

Then metric becomes the logic consequence of this journey.

In the next post I’ll tell you how I applied this method in a 4-hours workshop for defining the metric of the organization I work with.

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!

A Lean manager is not a coach!

Or is not only a coach.

Or, even better, is not primarily a coach.

Many times I heard people saying that traditional management style do not apply in an Agile and Lean context and therefore it must be replaced by coaching as THE way to help people develop.

I think this is wrong or at least shows a narrow, easy and fluffy view of what a manager is supposed to do for an organization in the 21^st century who wants to run its operation inspired by Lean thinking.

But let’s have a look at the different Lean disciplines one by one and try to understand better what is the essential contribution needed from you as a manager.

1. Eliminate waste

First step to eliminate waste is to see the waste. So you should know (and know very well) the Value Stream of the product(s) you’re working with and continuously challenge the current practice to identify waste. 

But this is not enough: a Lean manager should help teams remove impediments they are not able to resolve by themselves and systemize solutions in the organizations to prevent the same impediment from coming back again (see more about this in my previous post 3 things we can learn from TPS)

2. Build quality in

This means for a manager working to build a culture of discipline and excellence, that is guide on principles and values instead of giving complex rules, teach people not to cut corners, challenge people to high performance and lead by example. And yes, that implies true leadership.

3. Amplify learning

Most managers face competition with other managers trying to meet locally optimized goals and maybe look good to the next level up. But this wastes a lot of organizational learning, which can be effectively used by pairing up with peers. So building and maintaining a network of peers is essential as well as continuously challenge own management style in the light of Agile and Lean principles (see also Cultural transformation through deliberate practice of behaviors). But amplifying learning also means:

·         concretely encouraging experiments, fast feedback loops and safe/fast failure

·         providing and being open to feedback

·         striving for a radical transparency (as Steve Denning calls it) as the unique way to control the complex system your organization represents

4. Defer commitment

Keep your options open up to the last responsible moment and be capable to live with uncertainty: there’s no other way around (have a look here). Furthermore early commitment could mean discard too early real options which might have provided more value, just not to afford the cost of deferring a decision.

5. Deliver as fast as possible

The fastest way of achieving a goal is to let a diverse team of skilled people self-organize to better judge how to solve the problem. And the best way to have them self-organize is to define what the goal is, make it compelling and clarify what constraint the environment around puts to the direction. Then if you want to help your team or organization to deliver as fast as possible, set a clear vision, explain clearly where to go and why, align all stakeholders around that vision and get fast feedback. Then set specific goals derived from the vision: in that sense you’re the PO of your organization, so write a backlog of stories aligned with what you think is the ultimate goal to reach. And finally give space to your teams to reflect on what they are doing to find ways how to go even faster.

If you're not a front line engineer, there's only one reason for you to exist: help your team move faster - Jan Bosch

6. Respect people

Who dare disagree with this? Actually this apparently generic statement hides a deeper meaning. It stands for: give people the environment and support they need to do a great job and trust they will do their best to accomplish their goal. So it’s not simply saying to a team: Now you’re empowered to do what you want, but putting them into the conditions to succeed. So it’s about staying close to the teams, Managing By Walking Around and Listening (MBWAL instead of MBSR – Managing By Status Report), energizing people around you, assisting on personal development. And yes: that might be teaching, mentoring and coaching as well.

7. Optimize the whole

Optimizing the whole means having an e2e view of your system, product or organization and consequently as a manager selecting the right metrics which can help you improve, measures only what adds value (less is more) and whatever you want to measure, measure it one level up.

Of course, being a Lean manager does not mean taking decisions your team would be able to take themselves, asking for reviews and reports or pushing activities on your people.

On the other hand coaching is all about the coachee agenda, but improving theValue Stream, build the organizational culture, set the direction or define proper metrics cannot be other than about your agenda as a manager.

So were you one of those who thought that managing an Agile and Lean organization meant just coaching?   

What’s your thinking now?

12 secrets of a successful Agile transformation – Part2

Following the blog post from last week, here is the continuation of the list of 12 tips for a successful transformation towards enterprise agility. We mentioned already the first 3:

1. Why?
2. The approach
3. Training managers 

Let’s move on with 5 more:

4. The pilot project

Since we’re talking about applying an empirical process, the starting point is to setup an experiment in terms of a pilot project. Scrum can help out with its framework to give some guidance and some practices which help understand the agile principles behind. A pilot project can provide objective information on the feasibility of rolling out Agile to all the organization. Craig Larman says that if an organization is not able to implement real Scrum with only one team, how can they succeed in scaling it in the whole enterprise? But be aware of choosing a proper pilot project. It needs to be important and critical enough so that people will consider it a serious try and a valuable success (it should be used to gain even more management support for the change), but not too critical to create a safe environment for possible failure. It should be end-to-end and therefore include all the stages that are needed to bring an idea into a product and it needs to be closely monitored and supported by senior management, ready to fix possible impediments.

5. Scaling up

Leveraging on the feedback from your pilot project and acting on the findings, you can start scaling up incrementally. This will allow better control and will enable the organization to build internal capabilities to help the teams that start later.

If you don’t know what you’re doing, don’t do it on a large scale – Tom Gilb

However beware not to be too slow, to avoid the organization finding them in the ford for too long and losing momentum, sense of urgency and a clear direction about the change to make.

6. The Transition Team

Creating a successful Agile organization does not simply mean make a number of Scrum teams work: it means creating all the conditions around to enable those teams to succeed and get astonishing results. The Transition Team is an operative team, with the goal of helping and supporting the organization in implementing the Agile Transformation, by supporting teams, removing organizational impediments, training and coaching people, spreading the Agile values and Lean thinking. The team works as an agile team, driven by the so-called Transition Backlog populated top-down by the organizational transformation strategy and bottom-up by impediments from the team.

7. Create the new roles

In order to scale up you need to build new skills and behaviors for people to fill the new roles of Scrum Master, Product Owner and Scrum Developer. This is best done by means of a mix of training, mentoring and coaching and is a typical item in the Transition backlog. Understanding that we’re talking about new roles, you cannot find in the existing organization, is a critical success factor. One of the worst (and yet easy and most common mistakes) is to create a mapping between existing and new roles, like System ArchitectàProduct Owner or Project ManageràScrum Master. They are totally different jobs and you need to realize this and prepare to help individuals who are willing to learn and challenge themselves to fill the gaps needed to move to the new roles.

8. Cross-functional teams

Cross-functional teams who can deliver potentially shippable product increments at each iteration are a key element in a successful Agile enterprise. So one needed step is to change your organization, remove functional silos and have self-organized teams of 5-9 people with all needed competences working together permanently. And this might imply changes in the office logistics as well, to create the right environment to enable team collaboration.

The most efficient and effective method of conveying information to and within a development  team is face-to-face conversation – 6^th Agile principle

It’s probably enough for today: any comment?

Let’s have a date for the next blog post to talk about the remaining secrets for a successful Agile transformation. 

5 things you should know about Organizational Coaching

Some days ago I was having a coffee with one of my colleagues.

While answering to his request of feedback about his work as a Scrum Master, we ended up in talking about what organizational coaching means in practical terms, what it is really and what it takes to be effective.

I cannot report the whole interesting discussion, but here are some takeaways as summary for you: 5 things you should definitely take into account, if you want to become an organization coach.

1. Use a system approach

An organization is a complex network of people, who are complex beings. If you really want to leverage on all potentials to affect it, either to make it better or simply to help your team, you must look at it as a whole system. Try to sketch a strategy of the possible options you have ahead, possible impediments and way to overcome them to reach your goal: you might realize that a single isolated step is not enough, but you need to take many steps, in order to get any progress.

2. Know your organization

Try to understand your organization very well. Learn not only about the official and visible structure. Learn much more 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 decisive on certain tables, whether he has a formal power or only a subtle influential leadership. You cannot imagine what competitive advantage this will give to your effectiveness.

3. Act on different levels

Challenge the status quo and don’t limit yourself to the most obvious actions. Prefer actions who affect the environment around or the process to do things, instead of addressing directly a specific problem: they will have more and lasting impact.

Talk to people, with a preference for informal chats - coffee machines are a perfect place sometimes :). Try to find initiators and innovators to help you and sponsors to support you in difficult situations. And, whatever level you want to affect, consider acting also one level up.

4. Understand the effect of your actions

Before taking any steps in your strategy, 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. Find even people who to share your thoughts to and get feedback. The sooner you know if your strategy can work well or not, the better it is: you will then be able to adjust it if necessary and speed up the achievement of your goal.

5. Try things out

Finally organizational coaching is not mathematics and the system to act upon is many times far too complex to draft a strategy since the beginning, indentify any viable action or understand the effects of possible actions. That’s why sometimes you must simply try things out. And that's not wrong, stated that you try to fail fast and reflect on what you learned to find a different path.

That’s my experience. What did you learn in yours?

When we will get rid of Agile!

A short break within the Product Owners team posts thread.

It’s December 2012. Finally!

It has been since the beginning of the year that dozens of TV channels and magazines are filling up shows and pages with THE expected event this month.

Yes, exactly: next week December 21^st will mark the completion of the Great Mayan Cycle and the beginning of a New World Age.

I’ve been told by some people recently: “We’re not going to hear about Agile any more in 3 years from now!”

I tend to agree with this. We’re definitely not gonna use the scientific approach anymore and then will not be Agile any more.

The question is: When?

Once a New World Age will come. 

At that time major and maybe catastrophic events will have happened and the following 3 things will have changed profoundly:

1. The nature of SW development
2. The nature of human beings
3. The nature of organizations

1. SW development will not be a dynamic complex system anymore. Software will not be an intangible artifact and developing SW will not be a collaborative activity anymore, because only one person will be able to solve tough problems fast. Finally SW development will not be heuristic, because we will repeat solving the same problems over and over and build same programs the same way.
2. Human beings will change and our brain will become a simple linear processor. People will stop being driven by feelings, thoughts, emotions and beliefs and become perfectly predictable and rational beings.
3. Organizations will stop working as living systems and being complex dynamic networks of brains. BTW, brains will be flat and simple by that time and managers will be able to model their organizations like simple machines, where everything goes exactly as planned and no change in business or environment can ever happen.

This dreaming new era will definitely carry sheltered days, where all complexities are removed and future can be forecast.

I do not have a prophecy about when this will happen exactly, but until then I’m afraid we have no chance.

Complexity calls for complexity: we all would like things to be easier and schedulable. Meanwhile an empirical process control is the only way I know to handle creative work and dominate the chaos coming from a continuously changing environment.

Sorry!

Let’s see what happens with Mayan Prophecy in the meantime.

And if we will still be here, have a restful Christmas holiday and a great New Year!

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.