Monthly Archive for: ‘December, 2010’

Which stance should I take? The 4 quadrants of Agile Managers 11

I completed my 360 degree year end performance evaluation last week but this post is not about performance reviews. This post is the mental model I developed following a comment I received during the 360 degree discussions.

Martin, we recognize you are a good coach but as the president of the organization, we still expect you to act as a manager and take a position or make decisions instead of simply asking us questions.

As any other coach out there ever received similar feedback from the team they work with? In my opinion, this is recurring question asked to coaches.

Since defining what my role should be as the leader of a self-organized team, I’ve adapted my leadership style from traditional to coaching, with apparently good impact. Unfortunately, I may have pushed the coaching stance a little too much and need to adjust in order to meet the expectation of a leader.

The above statement and questions that followed in my head, led me to develop a mental model to determine which stance I could take in a conversation. The model also aims to help others who wish to be agile managers, and determine the right stance to take in different circumstances.

Two perspectives and two dimensions

Below is my mental model which takes into considerations both participants’ perspective on a specific situation – the other person’s (to the left) and yours (at the bottom).

Each of the two people either has a complete and immediate answer or solution to the situation at hand or an incomplete and/or untimely answer (which means the person is likely to find the complete answer after thinking about it for a while but the time frame is shorter than the allowed time. These two dimensions offer four possibilities or four quadrants.

Debating

In this situation, the other person already has the answer (or solution) to a specific situation while your knowledge of the topic is incomplete (or absent). Consequently, the only way you can actually contribute to the discussion is by improving the solution and by challenging the other person’s answer in an attempt to improve the answer or the outcome.

Coaching

In a situation when neither of the two participants know the answer to a specific situation, you can take a coaching stance. As such, asking clear questions in an attempt to help the other person come up by themselves with the answer to the situation. This stance allows the development of the individual as opposed to the improvement of the solution.

Educating

In the situation where you already know the answer but the other person doesn’t, you share the answer to the situation and explain how you got to the solution. The objective is to develop the skills of the other person so they may come up with their answer next time they are faced with a similar challenge. As with the coaching stance, acting as the educator focuses on the development of the individual which will eventually take you to the exploring stance.

Exploring

In this situation both parties already clearly know the answer to the situation and as such, a discussion takes place to explore all perspectives in an attempt to make sure the best options have been properly covered. As with the debating stance, the exploration aims at improving the quality of the idea since the individual already came up with the solution.

Using these four quadrants makes it easier to determine up front which position I will be taking in the conversation and allows me to be fully coherent from one discussion to the next.

Posted on: 12-20-2010
Posted in: Communication and knowledge sharing, Management and leadership style

Adaptation, Anticipation, Exploration – guest post by Jurgen Appelo 4

(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) [

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.

http://management30.com

http://mikecohnsignatureseries.com

References

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

Posted on: 12-16-2010
Posted in: Agile, Agile Leadership Model, Learning, Management and leadership style

Why did Santa deliver the gifts 2 weeks early this year? 3

Imagine my surprise as we were having dinner last night around 6:40 pm (fettuccine alfredo was on the menu) when I heard a huge “bang” coming from the chimney. The twins, my wife and I quickly got up and went to the living room to discover a dusty Santa Claus putting gifts under the Christmas tree.

“What the heck?”, I said out loud. “Santa, it’s 6:40 pm on December 12th! What are you doing?”, I asked.

“Ho, Ho Ho!” said the old man. “What do you mean? I’m delivering your Christmas gifts. Can’t you see?” said Santa.

“I can clearly see that you are bringing gifts but my question is why on the evening of December 12th? You are 2 weeks early!” I said looking at the various gifts on the floor. All of a sudden I noticed one gift wasn’t even wrapped.

Santa noticed I saw the un-wrapped gift and said “Sorry about this one, there are a few little issues but it should do the job for now anyway – especially considering I am 1 year late!”, he added “… and I apologize since these gifts are for 2009. I’ve really busted my timelines this year”. Whipping his forehead, Santa said, “I don’t have much time to explain but I prepared this document for you to explain everything. I am sure you will find it very useful. My elves spent the last 9 weeks writing the document”.

“They elves wrote a document instead of working on preparing the gifts? Really!”, I said.

Before I could say anything else Santa turned around, moved up the chimney and disappeared. My wife and kids looked at me stuned.

“Daddy, what’s wrong with Santa?” asked Alessia.

“Sweety, daddy doesn’t quit know but I’m sure I will find the answer in the huge manual Santa left us”, I said pointing toward the document.

“Daddy, look! This box is wrapped with toilet paper and it looks like it was open. What’s in there?” asked Giordano. Before I could even speak, he had ripped the paper and opened the gift. “Daddy, these are the pokemon cards I asked for last year. I’m too old to play with these. I don’t need them anymore” said my son angrily.

“Dear Mister. With the greatest magnitude of our sorrows and an unexplainable reason ask for your forgiveness in the event of the delay for the gifts of Christmas and to your honorable family…” I read from the document. ”Honey, this looks like it was translated into bad English. “Do you think Santa outsourced the elves’ work this year?” asked my wife.

Flipping true the book, “It looks like Santa claims that as part of the implicit agreement and based on our list of last year wish list, he delivered what we asked for”, I explained. “As I can see from the documentation, Santa no longer accepts changes in people’s request which is way he delivered what we asked for – even if it is no longer required”, I told my wife.

“Mommy, looks like Santa dropped an envelop on the floor before leaving”, said my daughter as she gave the envelop to my wife.

“Well, I can’t believe it. Santa is asking for a bigger budget and claims he will deliver the remaining gifts around March 14th!”, said my wife clearly upset.

“Wait a minute” I shouted. “It seems to me that Santa should be using Scrum next year. I’ll give him a call on Monday to explain how it could help him deliver on the expectations…”, I concluded before we all went back to a cold dinner.

Posted on: 12-13-2010
Posted in: Scrum

Status reporting in an Agile context – Introducing the SunSet Graph 3

You have implemented Scrum with some of your teams and get the following question – “How do we report project status to management?“.

If your organization is like most organizations, your choices are:

  1. You ask someone (the Scrum Master or the Project Manager) to convert (translate?) the information the team uses into the traditional management reports;
  2. You present the information exactly the same way the team is using it;
  3. You find a way to bridge the new reporting to the old reporting in order to reduce re-work.

If you have selected option #1, this post won’t help you much since there is no way for me to know what the traditional information reporting mechanism is within your organization.

If you selected option #2, you don’t need to read this post since you only need to show the information you already have compiled on its current form.

But if you went with option #3, you’re in luck. Well, kinda. My colleagues Mathieu and Elsa have come up with what they call, the SunSet graph [French] – because of its colorful presentation.

The Sprint Burn Down Chart

At the team level, many Scrum teams rely on the Sprint Burn Down chart. The Burn Down is very useful to present the amount of work remaining within the sprint in light of the time remaining. In addition, the Sprint Burn Down has the benefit of presenting true progress by comparison to a baseline in order to determine the team’s ability to meet the sprint timeline.

The Release Burn Down Chart

At a project level, a Release Burn Down chart can be used and is very useful for managers and people around the project to appreciate project progress as it presents actual progress in light of a project baseline. Just like the sprint burn down, the project burn down is a very visual way to present the amount of work remaining with regards to the amount of time left.


The SunSet Graph

The SunSet graph is a great complement to the other “Scrum” reports and is also geared toward management – although the team also benefits from producing it and having visibility to the information.

Just like the burn down charts, the Sunset graph gives visibility to the progress of the project – what is scheduled to be completed with regards to a baseline taking into consideration the estimated efforts by the team. With the associated product backlog, the sunset graph gives complete visibility to the content of the project. In addition to the Sunset graph, a financial graph can be added to give a one-view perspective of the project to managers interested in following the progress of the project.

The SunSet graph divides the user stories into 3 categories: Optional, Important, Mandatory. In a quick look, managers can easily follow the progress of the team in light of their commitment to deliver the stories based on the team’s velocity. Before the first Sprint, the team plots the number of sprints planned for the project (x-axis), the number of points to be delivered (y-axis), and the forecasted velocity.

At the end of each sprint, the team plots its progress by entering the number of stories completed and by adjusting their velocity based on actual numbers. The SunSet Graph Template can be downloaded.

The content of the template is updated at the end of each Sprint. Below, the SunSet graph after 6 sprints.

The content of the template is updated at the end of each Sprint. Below, the SunSet graph after 9 sprints.

The content of the template is updated at the end of each Sprint. Below, the SunSet graph after 12 sprints.

The content of the template is updated at the end of each Sprint. Below, the SunSet graph after 15 sprints.

By using a visual presentation of the project progress. It becomes easier for managers to understand at a high level the issues encountered by the team. Managers can then focus on anticipating potential budget excess or non-delivery of mandatory stories as opposed to focusing on the content of the project. In addition the keeping managers informed, the Sunset graph supports the concept of the self-organized team.

Posted on: 12-7-2010
Posted in: Communication and knowledge sharing, Processes and Tools, Tools

The Role of the Manager in Agile / Scrum – Some of the Best Blog Posts of 2010 3

For those who have been reading this blog for a while, it will come as no surprise that I’m very interested in helping organizations transition to Agile. My contribution is to focus mainly on the managers and leaders, and how they need to modify their leadership style to take advantage of the benefits agility brings to their organization.

Since writing I don’t feel so good – I’m a people manager in an Agile organization, I’ve been on the look-out for good posts on the role of the manager in an agile organization. Below are my 10 favorite articles for 2010.

Drop me a line if you feel I’ve missed something.

Posted on: 12-2-2010
Posted in: Agile, Management and leadership style, Scrum