Skip to content

Posts from the ‘Learning’ Category

Agile teams – What people managers can learn from parents

image by candrewsBefore I explain what people managers can learn from parents, I feel the need to defuse what some readers may have in mind. I am not suggesting that employees and team members are children or act like babies [although, sometimes … – sorry, I’m digressing].

The Art of Parenting

If you have children, you should quickly relate to the fact that nothing really prepares us to be good parents. Sure, while growing up we assimilate patterns, behaviours, and skills from our environment – including and often to a large extent from our own parents. At a later stage in our children-free life, some of our friends start to have kids and we observe them – sometimes with curiosity, sometimes out of sheer voyeurism, and sometimes with envy – and that’s when we contemplate the idea of having kids of our own.

Then, one day out of the blue, the kind doctor tells your spouse that she is pregnant – in our case with twins! But that’s an entirely different story 😉

Then comes the next stage of learning to become a parent, we spent countless hours on previewing and ordering books, lot’s of books. Except for a few best sellers, the others titles vary based on our perceived areas of weakness and the bad pattern we noticed from our parents when they raised us.

And one day, a beautiful baby boy is born and/or a pretty baby girl – once again, in our case we got one of each.

Once the sleepless nights are over and the baby is capable of learning, parents slowly transfer increasingly complex tasks to their child: holding the milk-bottle, feeding themselves, walking without holding mommy’s hand, abandoning the diaper, selecting how much ketchup to put on their food, picking their own clothes, walking to school by themselves, deciding what time to go to bed, going to a movie without supervision, and so on up to the point when the child moves out of the house to start their own independent life.

What people managers can learn from parents

It is obvious that parenting is very different from managing people, no doubt about that. On the other hand, their are some similarities.

Nothing prepares people to become good managers. Sure, while growing up in our professional career we assimilate patterns, behaviours, and skills from our environment – including and often to a large extent from our own managers. Granted, some people had the opportunity to learn about management during their school years and that could be an added bonus.

As with parenting, once we decide to get into management we spend countless hours on previewing and ordering books, lot’s of books. Except for a few best sellers, the others titles vary based on our perceived areas of weakness and the bad pattern we noticed from our previous managers.

How that applies to Agile teams

Agile management is somewhat similar to the art of parenting with the manager transferring to its team increasingly complex tasks and responsibilities. Helping the team self-organize doesn’t mean to abandon the team to itself without help or some supervision. Along the same lines as parenting, there comes a time when the manager must determine how much responsibility to transfer and what level of support to provide.

Similar to the role of the parent, the agile manager is there to support the team’s development and make it successful and autonomous until one day – maybe – the team is highly performing and can become independent.

Adaptation, Anticipation, Exploration – guest post by Jurgen Appelo

(Thanks to Jurgen Appelo for this guest post – © 2010 Jurgen Appelo)

The business unit I was leading some months ago was a fine example of a complex adaptive system trying to survive. As a young start-up business, our prime objective was to find paying customers. We anticipated in which places we could find them, and we adapted when it turned out they weren’t there. (Regrettably, the second often follows the first. For many startup businesses survival is a long process of learning what doesn’t work.) And sometimes we simply experimented, not knowing whether the results would be good or bad, only to learn what worked and what didn’t.

In most agile methods, this learning takes place in the form of increments and reflections, both of which are done iteratively. An increment is a new release of a product into its intended environment, and its main purpose is to invite feedback that enables learning, adaptation (looking backward) and exploration (trying things out), while reducing the need for anticipation (looking forward) to a manageable level. The released product influences the environment, and the environment then responds to it in some (possibly unexpected) ways. The knowledge gained is used to adapt, to anticipate what will be needed in the next release, or to continue exploring when we still don’t know.

Reflections (often called retrospectives) are used to understand whether or not the project itself is operating in the right way, and how to improve parts of it in order to be more successful. The last team I worked on delivered many increments of our tools, some of which were successful, and some of which failed miserably. And we had plenty of reflections on how we ran our business, some of which were rather painful, and some of which hurt like hell.

Increments and reflections are an example of double-loop learning, a concept proposed by business theorists Chris Argyris and Donald Schön. An often cited example of double-loop learning is the simple thermostat combined with a human operator (which I will repeat here, for lack of inspiration). The thermostat adjusts itself frequently based on the information about room temperatures that it gets from the environment (the first loop, using a model of the environment). But the thermostat is operated by a human being who modifies its settings based on her earlier experiences with comfortable temperatures and anticipated changes like holidays or weather forecasts (the second loop, refining the model of the environment) [Augustine 2005:170].

I think that continuous improvement in a business environment takes place in two loops, and involves adaptation, exploration, and anticipation (see Figure 1).

Figure 1 – Double-loop learning versus improvement

Though adaptation is often mentioned as a key component in agile software development, we shouldn’t forget the role of exploration and anticipation in our businesses. We not only need to solve problems. We also must try new things just to see what happens, and innovate by developing solutions to issues that we think will be important (in the next release, or shortly thereafter).

We expect uncertainty and manage for it through iterations, anticipation, and adaptation. (Declaration of Interdependence)

Doesn’t Anticipation Violate Agile?

Anticipation is like alcohol. It is healthy when used in a small dose. But it is addictive, and most people use far too much of it.

Agile software development does not reject anticipation. But it tries to reduce it to the smallest possible amount, where it is still beneficial instead of harmful.

In my former little startup business, we did plenty of adaptation, exploration, and anticipation. Frankly, I did so much double-loop learning with my team that my brain thought it was a roller coaster.

Are you adapting, exploring, and anticipating too?

This article is an adaptation from a text out of the book “Management 3.0: Leading Agile Developers, Developing Agile Leaders,” by Jurgen Appelo. The book will be published by Addison-Wesley, in Mike Cohn’s Signature Series, and will be available in book stores near the end of 2010.


Augustine, Sanjiv. Managing Agile Projects. Upper Saddle River: Prentice Hall Professional Technical Reference, 2005.

Silence is worth $600,000 per hour

Picture by CRASH:candyI already talked about silence as a communication tool but I can now estimate the value of silence at nearly $600,000 per hour. I recently came to this surprising conclusion when I bought my new car a few weeks ago.

Before I tell you my surprising story, I need to explain a few things about silence. During my coaching development program, we were explained that leaving room for silence allows the other person to clearly express their thoughts and feelings. Without silence, those thoughts and feelings would be unspoken and hence, unknown.

Keeping silence in a conversation also puts an uncomfortable pressure on the person spoken to – to speak. Try it for yourself and see how strange the situation becomes when no one is speaking.

To help us as coaches, we were told to keep our mouth shut and mind focused by counting in our head. You leave room for silence and start counting (in your head, otherwise there is no silence!). 1, 2, 3, 4… While you are counting, the other person feels some pressure and most probably will start talking – usually what follows the silence is very useful information.

So back to my story.

After seeing a few dealers and selecting the car I was going to buy, I entered into the typical negotiation scheme with the car salesman.

  • Salesman: “$xx,xxx. This is my final price”
  • Me: “Sorry, that’s too high. I did research on the Internet and I have a pretty good idea what the markup is on this car”
  • Salesman, looking shocked: “Let me see what my supervisor can do for you”
  • Salesman, coming back after a few minutes: “It’s your lucky day, my supervisor says that he wants us to reach our quota, so we’ll take out another $1,500”
  • Me: “That’s nice but it’s still higher than what I’m willing to pay for this car”
  • (…) a few more rounds of negotiation (…)
  • Salesman, somewhat surprised: “You know, (blah, blah, blah)…”
  • Me: “I understand. Listen, thank you for your time. I’m not in a hurry so I’ll keep shopping”
  • Salesman, getting anoid: “Listen, if you are that serious. I’ll take out another $1,000 but that’s really the best I can do!”
  • Me, pulling out my credit card to make a deposit: “I don’t believe this is the best price you can make. What else can you do…”
  • Me (counting in my head): “1, 2, 3, 4, 5, 6…
  • Salesman: “I’ll take out another $1,000 but I can’t and won’t go down anymore”
  • Me: “Deal!”

$1,000 off the final price for 6 seconds of silence. Isn’t that a nice hourly rate!

Asking Powerful Questions – Agile Coaching

Picture by Eneas

As Agile Coaches, we aim to be efficient. We analyze the situation around us, we ask questions, we experiment, we share our thoughts and observations, we make suggestions and recommendations. We try to be helpful.

Are we always efficient in the way we ask our questions? Could we ask our questions differently for better impact?

Below is a list of qualities associated with Powerful Questions taken from the reading material of the certification program I’m currently undertaking.

  • Clarity
  • Brevity
  • Relevance
  • Direct
  • Single Subject
  • Positive expression
  • Allow silence for the response

To be powerful, the questions should also have an impact. To be impactful, the question should aim at:

  • Personal issues and remain contextual;
  • Motivation behind the actions;
  • Consequences of the actions.

And include the question “what else?”.

    What we are looking for in the levels of information provided is:

    • Facts
    • Emotions
    • Opinions

    Finally, to be truly powerful, the questions should take the person out of his comfort zone in order to explore new horizons. Questions such as the following are usually very helpful:

    • What would happen if …?
    • With hindsight, what can you see?
    • If you were an expert in this field, what would you do?
    • If you had a magic wand, what would you do?

    Formulating a question isn’t always easy but to be an impactful coach, properly asking the question is critical. Hopefully, these few tips can help you become a better coach.

    Sir, please step away from the team

    Picture by AndyWilsonIn conversations with upper management, I often hear that they wish to start using an Agile approach to increase their return on investment (ROI) and the employee motivation – which is great! They have read or have been told that changing their approach should lead to:

    • Delivering solutions that meet the business needs…
    • …without exceeding time lines or costs and…
    • …increase efficiency and productivity.

    Many people manager (although not all) understand that people are more motivated when they are self organized and as such, take their commitments more seriously than if the commitments were made by others on their behalf (i.e. their manager).

    What is news to many of these managers is the impact an Agile transition will have on them – and their management style. I like to point out that to them that:

    • Teams and individuals are more productive when they are not interrupted;
    • Team performance improves greatly when people settle their own issues;
    • Changes in the composition of the team affect the team’s productivity.

    As such, people manager need to learn to:

    • Transfer the authority and the responsibility to the team members to allow them to do their job properly;
    • Avoid interference and micromanagement;
    • Promote collaboration and teamwork;
    • Support learning without systematically penalizing failures;
    • Establish a culture conducive to Agile projects;
    • Adapt their management style to the context of team.

    Overall, they must learn to change their management style from a command-and-control approach to a servant leadership style.

    Easier said than done – that’s where the Agile Organizational Coach steps in.

    Clueless – 7 hints you’re probably not on the Agile track

    Are you sure you want to be Agile?As an Agile coach and working for a consulting organization that specializes in Agile Software Development, I get to meet people who have decided to adopt or are thinking of adopting Agility within their organization.

    I have to say, most people understand what an Agile transition means for them and their organization and are willing to make the changes required to make their transition a success.

    And then, there are others who are most likely adopting Agile for the wrong reasons and as such, aren’t really interested or even aware of what it means for them.

    I’ve put together a short list of 7 (real life!) conversations that made me wonder if common sense had left the building. Feel free to share your conversations…

    Time estimates

    • Client: I don’t understand. Since we’ve adopted Agile, our developers consistently exceed the time estimates for their tasks.
    • Me: Interesting. Who provides the time estimates?
    • Client: The project manager…

    Change Management

    • Client: We are really serious about implementing Agile within our organization.
    • Me: Great! You realize Agile is not a silver bullet that will magically eliminate all your issues?
    • Client: Of course, we are fully aware. We would like to start with a new project that is scheduled to start shortly.
    • Me: Good. Following our earlier conversation, you realize you will have to make changes to the way your team is currently working and that might impact their productivity in the short term.
    • Client: We can’t impact the team’s productivity. The project budget, scope and time lines have already been defined and the project is already 2 months behind schedule…


    • Client: We have identified a list of issues that we need help with. Here’s the list. Can you help us?
    • Me: Possibly. Let me look at your list. Who came up with the items on this list?
    • Client: Me and my direct reports.
    • Me: Has the team been involved in putting this list of issues together?
    • Client: Absolutely not. We asked them to put together a list of issues they were facing and most of the items were related to lack of trust, micro-management, and bad communication so we threw out their list and put this one together for them…


    • Client: We are just about to begin a new iteration but our last iteration was a disaster. We missed our time lines, the product owner is upset at the development team and morale is very low.
    • Me: Have you done a retrospection at the end of your iteration?
    • Client: No. We need to start development on the new project immediately.
    • Me: Wouldn’t there we be value in evaluating what went wrong in order not the repeat the same mistakes?
    • Client: We don’t have time for that and quite honestly, we don’t want the team’s morale to get worst once they realize how bad the situation is…

    Management Support

    • Client: This Agile thing is great! I’m going to impress the management team with our success.
    • Me: How so?
    • Client: The development team asked me if they could use Agile for their next project and from what I read, Agile can help them improve their performance and reduce the time to market.
    • Me: Yes, if it’s done right you may get those benefits.
    • Client: Wonderful! After I gave them the go ahead to start immediately, I told them I now expected to project to be delivered in 9 months (instead of 18 months) and cut their budget by half…


    • Client: Agile has done good things for our development team but we keep facing issues with project members that don’t report into our department.
    • Me: Who are those external contributors?
    • Client: The architects and the DBAs.
    • Me: Do you keep them informed of your project progress? Do they get involved in defining the stories? Do they estimate their work?
    • Client: Hell, no. We simply assign them the work they need to do and complain to their boss if they fall behind…

    Scrum Master

    • Client: I don’t understand why things aren’t working well.
    • Me: What is the issue?
    • Client: We took the Certified Scrum Master training you offer, we read a few books, and we’ve started implementing Scrum but nothing seems to be working.
    • Me: What do you mean?
    • Client: The only thing we didn’t do is take a natural leader to be the Scrum Master. Robert was available so we asked him to be the Scrum Master.
    • Me: Who is Robert?
    • Client: Robert has been with the company for 22 years. He’s one of the few Mainframe project managers who preferred not to learn the new web technologies and since he didn’t have any assignments, we thought he could do the job…

    Do you have any hints you would like to share?

    How do you react to bad news? Assess your management skills

    Picture by dsevilla Have a few minutes? Want to quickly assess your ability to react to bad news? Try this short exercise.


    Working for a large multi-national organization, you are the head of a 40 people software development team. Your team’s ability to deliver on their commitment continues to decrease despite implementing new measures to help boost productivity.

    During a recent lunch meeting, you were informed that things on the floor are really bad by one of your external partner. In an attempt to help you, the partner offers to present some key findings about your team – their processes, their tools, their skills, their environment, etc.

    In order to share the suggestions of your external partner with your team, you invite your direct reports (managers) to the presentation. It’s a sunny day outside and despite some technical glitches, the consultants begin the presentation by stating the objective of the meeting and inform you they intend to be very candid. After a few introductory slides, the real content of the presentation begins…

    Slide 6

    Lack of Team work

    • No ownership of the project by the team members
    • No shared commitment by the team members
    • Team members not working with a common goal in mind
    • Seperation of responsabilities leads to a silo work environment


    • Lack of efficiency
    • No sharing of knowledge
    • Team members have no common focus

    Slide 7

    Lack of Technical Skills

    • Testing (Unit, Functional, Acceptance) non existant
    • No knowledge of Object Oriented Programming
    • No knowledge of Web Development Skills
    • Sound engineering practices absent
    • No time for learning


    • High and increasing number of bugs
    • Quality is constantly low
    • Maintenance costs are increasing
    • Will have a negative impact on future projects

    Slide 8

    Difficult Work Environment

    • Micro management and interference by management
    • Lack of communications and transparency
    • Maintain a culture of fear and blame
    • Dictates the ways of working
    • No time for learning


    • Overall unpleasant work environment
    • Team members want to quit the project
    • Overall quality is suffering

    How would you react?

    Enter your answer below. I will publish the results shortly.

    Why most managers need a leadership coach

    If at any point while you read this post, you disagree with any of my statements, go ahead and click the “Leave a Comment” link. Express yourself!

    Image provided by Dunechaser

    While the original title of my post was “Why most software development managers need a leadership coach”, I changed it to “Why most managers need a leadership coach” because the situation I have witnessed in the software development industry is also present in many others specialized fields of expertise – at least that’s what many of the people I speak with confirm. Nonetheless, in order not to generalize my assumptions (yet!), I will share my assessment of the people management and leadership capabilities within the software development industry. Let’s begin…

    Are you familiar with such problems?

    These are only a handful of typical problems encountered by a manager and for most experienced managers, they may sound trivial. Considering that new leaders are not born with management abilities, how can we expect them to be successful in their role?

    People managers lack the basic skills

    Here’s why I believe most software development managers (and many others) need coaching to become successful in their role (and apparently, I am not the only one who believes this is a valid suggestion). My logic goes as follows:

    • Managers – including software development managers – are people;
    • There are 2 ways to become successful at something. Either you learn through education or you possess above average intuition and intelligence and can figure out how things need to be done;
    • Most software development managers have a technical training /education (examples can be seen here, here, here, and here);
    • In addition to their education background, most software development managers mostly played technical roles (software developers, business analysts, application architect, etc.) in their career prior to getting promoted to a management position;
    • Most people management positions are complex and require knowledge and experience outside of technology such as Business, Leadership, People Management, Organizational Development, or Psychology;
    • Very few people in people management positions have all the requirements (see previous bullet);
    • Without prior education and experience outside the software development sector, most managers are ill-equipped to successfully perform in their role.

    Coaching is a solution

    With an average salary1 of $85,000 to $125,000 depending on the number of years of experience and location, why wouldn’t an organization invest a few thousands of dollars to hire a coach in order to help develop the people management and leadership abilities? Despite the economic downturn, I still see organizations spend thousands of dollars on training or conferences. Although I don’t argue the value of such events, I doubt they support the development of people management and leadership abilities.

    It seems to me that we need to help those in management position succeed. Otherwise, the performance of the entire team will suffer.

    Not convinced?

    Others seem to agree with this new trend…

    1.- Sources:

    Timmy’s story: Is it better to be right or to be helpful?

    Timmy's story

    Would you rather be right or be helpful?

    This is the story of Timmy, a highly talented university graduate. After spending 4 years completing a university degree in Computer Science at a well-recognized school and over a year working on internal projects within his firm, Timmy was sent off as a consultant to help an organization in need.

    Timmy quickly realized that he was more knowledgeable, more competent, more skilled, and harder working than most software developers on his new team. Whenever an issue would come up, Timmy knew the answer much before everyone else.

    After a few days, Timmy realized the sad state of affairs within his client’s software development organization and in trying to help his new colleagues, he started dispensing recommendations as if they were candies on Halloween night.

    Every time Timmy noticed something that wasn’t done properly or as per the theory he had mastered, he would immediately point it out. Every time a colleague would run into an issue, Timmy would quickly point out the source of the issue and the solution to fix it. Every time Timmy noticed a team-mate slack off, he would tell others on the team. Timmy knew he was right – pretty much all the time.

    Needless to say, Timmy was not well liked by his team mates. On the other hand, Timmy didn’t like his consulting mandate either and within a few days, Timmy asked his firm to pull him off the mandate.

    Despite Timmy’s capabilities and the obvious need of his new team, the conflicts between him and his colleagues grew quickly every day. After a few weeks Timmy had enough. He couldn’t understand why nobody saw that he was right, that he had the answer to all their questions, and that they wouldn’t have any problem if only they would listen to him.

    Feeling so frustrated by the situation, Timmy showed up at his firm’s office one morning asking for help. “Can someone tell me what is going on?” he cried out.

    A senior consultant who immediately saw the distress on Timmy’s face, gladly offered to help. He explained to Timmy that although he was a competent technical resource, Timmy failed to realize a few key elements of consulting:

    • Timmy hadn’t made sure to clarify the reason he was hired. Clarifying the expectations was necessary to avoid possible confusion around the role he was to play;
    • Nobody likes to feel they are inferior to others – especially not to consultants. If Timmy wanted his suggestions to be accepted, he would need to use a softer approach, some humility, and a lot of patience;
    • People do not accept suggestions – let alone recommendations – from others unless they have established their credibility;
    • Team mates are not likely to accept input unless they actually ask for it;
    • Timmy needs to ask himself if he believes it is better for him and for his client to be right.

    Do you know anyone who is like Timmy?

    Would you have the courage to kill your “puppy”?

    Cute puppy

    Few people have the courage to kill their "puppy"

    Before you call animal protection agencies, I need to warn you upfront that this blog post is not about taking the life of man’s best friend. This post is about making difficult decisions – very difficult decisions when it comes to ending your own initiatives. For the record, I love animals but I found the analogy so powerful that I decided to use it to support my perspective [thanks to AndrĂ© for the analogy].

    I wrote about an organization’s ability to create, select and grow new ideas in an earlier blog post. I already highlighted 2 very different methods of launching new initiatives and in this post, I want to write about a leader’s ability to kill an initiative before it reaches full potential. No sane person launches an initiative or a project with the objective of not being successful.

    Too many organizations lack the ability to innovate so when an organization has the amazing ability to generate new ideas, it is a wonderful thing. In such organizations, employees are motivated and the company makes sure it will continue to grow by bringing innovations to the market. Such organizations typically have a healthy pipeline of ideas that help them re-invent themselves. Some large organizations even have the goal to generate more than 30% of their revenues from products created in the last 24 months. That’s an aggressive but worthwhile strategy.

    The challenge I have seen is with smaller organizations where the initiator of the idea is also typically its leader. In such circumstances, the leader no longer has the ability to take a step back and see things as they are – not as he wants them to be. After investing money and personal energy and imagining such high potential, making the right decision about pursuing the project (or not) when the results aren’t there is nearly impossible. The emotional ties to the project are so strong, it requires a lot of courage to make the decision to kill the project.

    What do you do when the initiative doesn’t deliver on its expectation? Do you keep moving forward or do you put an end to the project? When do you know when enough is enough? How do you know you didn’t kill the idea too soon?

    Unfortunately, there are no easy answers to these questions except it depends… It is obvious that the decision to end an initiative is much easier to make when you are not emotionally associated with the initiative. Not having taken part of the initiative makes it easier to use clear-cut criteria and apply them. If the project didn’t generate the expected revenue or doesn’t meet which ever other criteria used to evaluate it, it is much easier to decide to cancel it – to make a rational decision instead of an emotional one.

    As with every thing in life, no one can ever be certain that the decision was the right one but I firmly believe that making no decision (or maintaining the status quo) is worst than making a decision. Isn’t insanity the behavior of repeating the same actions and expecting a different outcome?

    As for your initiatives, stop seeing them as puppies. Take a step back and if you must kill your project, see the experience as an opportunity to develop new skills that you will need further down the line. As Agile people keep saying “Inspect and Adapt” which is a clever way of saying “Learn from your mistakes, and move on”. Very few large success happened on the first attempt. See your failed initiatives as a pre requisite for your next success.

    I’ll tell you about some of my “puppies” in an upcoming post…