The top 2 skills for being an effective Agile coach (or an effective leader)

Being an Agile coach is fun and extremely rewarding, but it is a tough job. 

Like a sports coach, you're supposed to help your team and your players perform at the best they can, without playing yourself. You have to influence with no formal authority, so you'd better have a very well equipped toolbox (skills, knowledge, techniques, and experience) if you desire to be effective.

I'm not here today to create a generic list of what those tools might look like. I just want to share the two coaching skills which helped me most in my 5-years experience as an Agile coach: 

1. Empathy 
2. Situational awareness

rosita by schaaflicht/CC BY 2.0

1. Empathy 

Empathy is a very important skill for coaches as well as for leaders, even though I think not many people realize this. 

No coach can be effective without getting trust from clients; likewise no leader can be effective without trust from people she is supposed to achieve success with. 

I learned that one of the most effective ways to build trust is to demonstrate that you truly care about people and you are committed to their growth. 

I learned that people want to feel they are valued. People appreciate when someone is really listening to them, puts herself in their shoes, is not judgmental and really tries to understand their viewpoint. 

Then of course you have to show that you can really help them and bring some value, but being “there for them”. when talking to peopl.e is a necessary step. Otherwise they perceive you just as a sort of knowledgeable professor. 

One of the most rewarding feedback I have ever received was from a Product Owner I was coaching: “It’s really impressive - he said once -  you look like you’re truly listening when we talk, not just hearing what I’m saying!”. 

Of course it is not always easy and it doesn’t come easy for me either. 

It is a skill to practice (and deliberately practice) to reach what David Rock calls listening for potential: it means listening to people not as for what they are now, but by thinking at what they can become in the future and be committed to help them become the best they can be.

Mount Everest by NASA/CC BY 2.0

2.  Situational awareness

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

This skill always resulted to be very useful for me in many situations, especially when I meet a team for the first time or when I deliver training. 

You can understand for instance, who is with whom or against whom; who is more senior, or who the leader is; who embraces new ideas or who is skeptical. Of course I do not use it as my only source of information, but I learned to trust this sense, which I consider a mix of “gut feeling” and experience in observing human behaviors. 

I apply this skill continuously: for instance I use it to diagnose how a team is collaborating. I observe them during the day, at Daily Scrum and in other ceremonies and I try to understand what is “really” going on to understand what to do or not to do.


What are the skills which are most effective and helpful for you?

Scrum and XP: reconciliating Agile with its roots

I really encourage you to have a look at this awesome session from Robert C. Martin, called The land that Scrum forgot. 

Besides the usual pleasure to listen to Uncle Bob, it is an impressive overview of the history of Agile, admirably told by an eyewitness and one of the main actors: you can really see in action the giants (on whose shoulders we're all standing) and feel them like closer friends, more than myths.
Among the different enlightning reflections, Bob Martin draws a clear and interesting perpective of the last decade (and more) about why Agile is somehow  not completely fulfilling the original expectations: Agile was originated by developers (all Agile signatories were basically developers), then it got conquered by project managers and lost part of its original intent.
Scrum unintentionally contributed to this, being seemingly so simple to be understood from managers, but so generic about how to build a potentially shippable product increment every sprint to be incredibly hard to adopt. Thus Scrum was actually the way people with project management background used to enter the Agile world either with good intent or opportunism.
On the other side XP was THE Agile method of developers.

I will try to analyze and compare Scrum and XP here to show how they're aiming at the same purpose and how both effective Scrum and effective XP embody the same genuine Agile principles and values.

Scrum and XP have actually a lot in common, more than one might think. 

They are both based on iterations and have some practices in common:

• the Planning Game in XP overlaps with the Sprint Planning in Scrum
• both produce a working SW increment of the most valuable functionalities at the end of each iteration
• the team is self-organized and decide how to build a certain function
• business and developers work together on daily basis
• the system metaphor in XP overlaps with the concept of User Story which is basically used in every Scrum Team I know, even though it is not explicitly requested by Scrum which basically only mention generically a backlog item as input to the Sprint
• both encourage similar values, and actually share two values: Courage and Respect

One might also claim they have some slight differences:

• Scrum prescribes Sprints which can be 1 to 4 weeks long, while the length of an iteration in XP is 1-3 weeks long
• the customer works together with developers in XP, while Scrum proposes the role of Product Owner as customer representative to suit the cases where the customer cannot physically work with the team (btw that’s one of the reasons why Scrum scales and XP doesn’t)
• strictly speaking, Scrum teams do not allow changes to their Sprint Backlog. XP teams instead can allow changes within their iterations: as long as the team hasn’t started working on a particular feature, a new feature of equivalent size can enter the iteration in exchange for the not yet started feature (however many times I teach the same approach to the Scrum teams I coach, especially when the environment allows and it does not become the norm).

However the biggest difference between Scrum and XP is that Scrum is basically focusing on how to organize the work, but it does not say anything about how to do the work, XP instead is more focusing on practices to develop high quality software effectively.

At the same time I learned (and thus agree with Dave Rooney) that Scrum is not enough to sustain an effective Agile SW development. Scrum is a great starting point if you want to learn how to be Agile, but I saw many Scrum teams, getting more mature with Scrum and not improving their performance overtime without using proper technical practices, because they accumulated a too big technical debt. Instead they have to learn to build the product in a different way.

Scrum explicitly avoids prescribing technical practices, but a Scrum team will hardly succeed without using certain XP engineering practices, like Test Driven Development, Continuous Integration, Pair Programming, Collective Ownership, Coding standards and Refactoring.

Effective Scrum and XP together can really unleash the full potential of a team, allow delivering effectively high quality products that customers love and stay true to the original spirit of the Agile manifesto.

Scrum is Lean

I believe that Scrum is the most Lean among all Agile methods. 

scrum by David / CC BY 2.0

And not only because the word "scrum" was first used in 1986 by two professors at Hitotsubashi Univeristy in Japan, Hirotaka Takehuchi and Ikujiro Nonaka, in their famous HBR-published article             "The new new product development game".

In 2003 Mary and Tom Poppendieck coined the term Lean Software Development by publishing a book with the same name and proposing a translation of Lean thinking and practices to the software development domain. Lean Sofware development is based on 7 principles, which may be implemented by means of a number of tools:

1. Eliminate waste
2. Amplify learning
3. Decide as late as possible
4. Deliver as fast as possible
5. Empower the team
6. Build integrity in
7. See the whole

If you want to know more, Mary and Tom published two more books:

• Implementing Lean Software Development: From Concept to Cash
• Leading Lean Software Development: Results Are not the Point

Now, even though Scrum and Lean Sofware development might seem to have formally nothing in common (different principles and different practices),  I will try to explain why and how I think the seven Lean SW Development principles are somehow mapped (or at least found) in Scrum.

1. Eliminate waste

The book reports seven wastes in SW development: partially done work, extra features, extra processes, task switching, waiting, motion, defects.

I think that the Scrum framework as such contributes to eliminate those sources of waste:

- the iteration-based approach, through the use of the Sprint Backlog, and the focus on doing whatever it takes to get things done and transform the items in the Sprint Backlog into a Potentially Shippable Product Increment, contributes the eliminate partially done work

- the Product Backlog handling, by building first the features which are more valuable for the customer and not spend too much time on the ones that are coming later, contributes to minimize partially done work and not needed features

- self-organized teams, who have the best knowledge, who are empowered to decide how to do the work and who continuously adjust their process through Sprint retrospectives, contributes to remove extra processes

- teams focusing on the Sprint goal minimize task switching

- cross-functional development teams working together side by side and daily with the Product Owner can remove waiting and handover of work items

- high skilled development teams, feeling responsibility for product quality, minimize defects

2. Amplify learning

Scrum is all about seeing SW development as a learning process. The Sprint will help create knowledge both on the product and on the process: the Sprint Review and the Sprint Retrospective are the main points in time where the knowledge on the product and the process are built respectively via feedback loops. The Daily Scrum also creates knowledge about how far the team is from the Sprint goal

Cross-functional teams learn continuously from each other skills and share knowledge inside the team and between different teams.

3. Decide as late as possible

A Product Backlog which is more fine grained on the top and more coarse on the bottom and “just enough just in time” planning via a Sprint based approach, allow a Scrum Team to reduce complexity and defer decisions which are not necessary at a certain point in time.

They can keep instead options open up to the last responsible moment: they can use time to collect more information and learn more about the product and the context in order to take better decision later, based on facts. They will of course learn fast by means of quick feedback loops provided by the Sprints.

This allows a Scrum team to be more flexible to react to the changes that will surely happen in the market and in the technology: they can truly embrace change inside their process of developing SW.

4. Deliver as fast as possible

Short delivery cycles represented by Sprints allow deliver quickly to maximize return on investment, get feedback from real customers and users and reduce risk that you won’t deliver a product that meets customers’ needs, due to misunderstanding or any changes in markets and technology.

A team focusing only on delivering the Sprint backlog will produce potentially shippable SW increments faster.

5. Empower the team

Scrum is all about empowering self-organized teams to find the best way to accomplish work. Self-organized teams can leverage all members’ talents and intelligence in the best possible way to achieve their goal as fast as possible.

Real empowerment is achieved by having the Product Owner to decide the “What” and the “Why” and explicit it by means of Product Backlog items in the form of User Stories: the development team will then decide the “How” and find the fastest possible way to get a User Story done.

6. Build integrity in

In a waterfall approach, piling up code without testing often result in a very expensive re-factoring effort, due to bugs, but especially to requirement change or misinterpretation.

Quality in a complex environment like SW development can be built only via iterative and fast feedback loops. A Sprint provides the main feedback loop mechanism in Scrum. Inside the Sprint there might be other even quicker feedback loops:

- the Product Owner (customer representative) works together with development: they are part of the same Scrum teams and work daily together: they collaborate on the Product Backlog and the real Product and this ensures a continuous feedback loop on requirements and system behavior

- Scrum teams adopting XP practices perform continuous refactoring, continuous testing, and continuous integration, which are Agile ways to build quality in.

7. See the whole

End-to-end Product Backlog items (slicing the product end-to-end vertically and explaining why) and cross-functional teams allow looking at the whole system: they can adapt the work items and the process to maximize the value delivered and achieve the Product Vision in the fastest possible way.

An empowered and self-organized team, working closely and daily with a customer representative (the Product Owner), 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 which typically, in traditional environments, try to optimize some small part of the system, which may not help the whole system.

If you want to implement a Lean thinking in your organization, try to practice effective Scrum first and you will get an extraordinary teacher. Scrum is Agile and Lean.

What do you think? 

How to teach Scrum to your boss (and why)

One of the biggest challenges I usually faced in my experience as Scrum coach is not really related to Scrum as such, but more to the consequences that Scrum creates in the organization by exposing the real problems.

So it often happens that some people (especially among managers and senior technical experts), afraid of losing their position, start to get alarmed by the serious challenge of the status quo and do their best to slow down the change.

Ever seen that? I'm sure you have. 

And if you want to have any probability of success with Scrum, you'd better do something to address the natural resistance of middle management to move away from a command and control leadership style.

Where to start? Don't look too far: Start with your boss. 

Help her become a professional 21^st century manager capable to build a trust environment where people can develop and team can flourish at their best potential. If she becomes knowledgeable enough, she will understand and consequently start dismissing traditional management practices, which make no sense and are even detrimental in a knowledge working environment.

That's what I normally do with the managers I work with.

In two of his inspiring articles, Steve Denning, author of the best selling book The Leader's Guide to Radical Management - Re-inventing the Workplace for the 21st Century, says that Agile is The Best-Kept Management Secret on the Planet and that Scrum is a Major Management Discovery. 

Bingo! If you want your boss to support your company Agile transformation and introduction of Scrum, you just have to teach her... Agile and Scrum.

How can you do that?

1. Training and self-education

I dedicate a consistent amount of time in delivering training to managers, in individual coaching as well as in team coaching with the Leadership team. 

The Management learning program I propose has the following structure:

- Kick-off with 2-days Scrum training

- 2-days Lean and Agile Leadership training

- Individual and team assessment to identify strengths, improvement areas and further learning needs (I described a bit the content of the assessment tool in a previous blog post).

- Training program (monthly sessions) based on assessment outcomes, which is usually self-led by managers pairing up with a coach and leveraging on a Learning by Teaching approach

- Weekly self-learning activities (Lunch and learn or Lunch and share, Book club)

2. Gemba

Respect is one of five Scrum core values. Getting bit deeper than its generic surface, it means giving people the environment and support they need to do a great job and trust they will do their best to accomplish their goal. It’s about staying close to the teams, where "real" things happen and you can identify ways to improve the system .

Gemba is the Japanese word which means "the real place" (for instance Japanese detectives call the crime scene gemba). So if you want to help your boss to learn Scrum, encourage her to walk where work happens and Scrum actually comes to life.

In all teams I coach, I try to introduce managers into this “go and see” culture, not only with the goal of getting them to understand teams’ problems and ready to support, but also for making them learn Scrum by interacting with a real Scrum team.

Advertise Sprint reviews (maybe posting catchy flipcharts) or encourage your team to forward invitation even to top managers: for some of them it might be a culture hack, because they might think it is a development team’s stuff.

Pass by your boss' desk and invite her to join for the Daily Scrum. She might claim that she does not want to disturb the team: challenge her to stop asking weekly reports and join the Daily standup instead.

3. Deliberate Practice

Scrum is founded on an empirical process control: the biggest amount of knowledge is created by experience and feedback.

I usually coach the Leadership Team to use Scrum for their work, so that they can learn Scrum by actually practicing it.

Have your boss feel the pain as well as the excitement of working in short iterations.

Additional suggestion  

Have a look at the book Teaching smart people how to learn by professor Chris Argyris, Harvard Business School. 
He talks about avoidance of learning and how discrepancy between espoused and actual theories of action harms people’s learning: these are actually the biggest problems I found with people and especially with managers which you would not classify as innovators or ealry adopters in the Rogers’ Bell curve on diffusion of innovation.

So try to keep an empiricist approach: you will lower down your boss' defends and have her more open to new things, because she would feel less in danger.

Address concrete and painful problems and show how Scrum can help her with them. Avoid to fall into the trap of: "this is Scrum, this is not Scrum", or "this is right, this is wrong". Escape discussions based on personal opinions, but try to build a we-are-together- against-the-problem atmosphere. At least you will save a lot of talks and useless discussions.

Warning 

I learned not to waste too much time with laggards and cynics. So if you classify your boss like that, just spend enough time to make sure she does not pull others and the organization to old behavioral patterns. 

Or better, quit your job!

Agile is demotivating

A few weeks ago I happened to talk to a couple of University students who were conducting a survey in different companies about the impacts on people motivation from moving to Agile SW development. What they told me could appear surprising to many of you: a consistent percentage of people answering their survey claimed that they feel extremely frustrated and demotivated with Agile. Are you hit by this? I want to elaborate in this post why I was not.

What is motivating for knowledge workers in 21^st century?

In his extraordinary book “Drive: The Surprising Truth About What Motivates Us”, Dan Pink sketches what he calls Motivation 3.0. 

Based on scientific evidence over decades of research, he explains that, once basic living needs (like food or safety) are satisfied (Motivation 1.0), the factors that are still nowadays commonly considered as motivating (carrot and stick, e.g, money and punishment) are actually working only for simple and repetitive tasks. 

These “extrinsic” motivators (Motivation 2.0) are not only useless, but even counterproductive, as soon as tasks require cognitive effort: in that case “intrinsic” motivators are the only ones which really work. Motivation 3.0 is based on three pillars:

• Autonomy - over
• Time – when to do the work
• Technique – how to do the work
• Team – whom to do the work with
• Task – what work to do
• Mastery – ability to become better at something that matters for you
• Purpose – natural desire to contribute to something greater than yourself

You might want to have a look at Dan Pink’s TED talk, The puzzle of motivation or to a nice visual depiction of the 3^rd Drive theory on YouTube to get some more insights. Or simply read the bookJ.

After having reflected around what is motivating, let’s touch a bit what Agile is. 

Well, if we want to explore the subject from the perspective of the relationship with motivation, the first thing that comes to my mind is the 5^th Agile principle: 

Build projects around motivated individual. Give them the environment and support they need, and trust them to get the job done.

Motivation looks like being somehow embedded in Agile: so how can we explain the result from the survey? 

Well I will not give an answer based on a well-defined and exposed theory of what Agile is.

On the other hand, if I look at the three intrinsic factors in Motivation 3.0, I can say from empirical evidence what Agile is definitely not.

Agile is not:

• Artificial deadlines pushed on teams for lack of trust
• Commitments taken by people not actually doing the work or, alternatively, commitment games (people pushed to commit and then it’s their business to keep the commitment)
• Processes pushed from the top (sometimes by people with not enough understanding of the work at hand)  
• Developers not allowed to choose what they consider the best tools for them to work
• A lot of gate checks before being allowed to change any line of code
• Teams with not enough skills or support to succeed
• Bossy team leaders called Scrum Masters who do the planning and assign tasks to developers
• Senior technical people just playing the role of “checkers” instead of teaching people how to do a better job
• Accumulating technical debt and not promoting pride for well crafted code
• No Product Vision or lack of understanding why to develop a certain feature

So, if anyone, who finds herself in a similar reality, names all the stuff above as Agile, maybe just because she’s using post-its and white boards, I cannot agree more with her: Agile is demotivating.

I would then like to hear less Agile talks and more lived up Agile values and principles (and more knowledge, and more practice).

I subscribe to what I heard James Grenning saying to managers in his closing keynote at Scrum Gathering London 2011: Stop motivating people, but stop demotivating them!

What is your thinking?

Being a manager in the age of Agile

I was reading back the post I wrote about one year ago, where I talked about what a manager can do to build and operate effectively a 21^st century organization rooted into Lean thinking.

To take a long story short, if you are a manager who was told not to take decisions your team would be able to take themselves, ask for reviews and reports or push activities onto your people, you’d better not to. But there are plenty of things indeed you can do (and should do) instead.

I tried to summarize them in the mind map below (click on the image to enlarge).

And well, I also re-used the title of the workshop I held at LESS 2012 J (see http://www.slideshare.net/giusdesimone/learning-to-be-a-manager-in-the-age-of-agile)

So, what do you think? Does this visualization support a clearer picture?

What thoughts did it trigger?

What else will you add as necessary or valuable?

What would you like to see changed in your organization?

What would you start doing differently from tomorrow?

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.