Analytical-Mind
A blog offering new paradigms to improve performance and quality of life at work.
  • Home
  • About Me
  • My Virtual Bookshelf
  • Contact Me

Category Archive for: ‘Communication and knowledge sharing’

The strength of a real team is under-estimated 1

Project kick-offs have been used for years as a way to launch a new project. It is assumed that bringing people together in a room where the project sponsor presents the project’s objectives and time-lines is a good way to get things going. To be sure that the newly formed team will perform well, some organizations even order sandwiches or sushi and add diet software drinks or beer, and so the project begins.

I really don’t have a strong opinion about project kick-offs but I do see a great opportunity to start building a real-high-performing-team from day one is often missed.

Having been part of great (and not so great) teams over the years, I’m obsessed about creating real teams – the ones we remember forever because we delivered outstanding results while being highly energized, and had a great time doing it. It is similar to the concept of Flow proposed by Mihály Csíkszentmihályi.

Flow is the mental state of operation in which a person in an activity is fully immersed in a feeling of energized focus, full involvement, and success in the process of the activity. [...]

According to Csíkszentmihályi, flow is completely focused motivation. It is a single-minded immersion and represents perhaps the ultimate in harnessing the emotions in the service of performing and learning. In flow, the emotions are not just contained and channeled, but positive, energized, and aligned with the task at hand. To be caught in the ennui of depression or the agitation of anxiety is to be barred from flow. The hallmark of flow is a feeling of spontaneous joy, even rapture, while performing a task[2] although flow is also described (below) as a deep focus on nothing but the activity – not even oneself or one’s emotions.

Colloquial terms for this or similar mental states include: to be on the ball, in the moment, present, in the zone, wired in, in the groove, or keeping your head in the game. Wikipedia.

So back to creating a real strong project team (The Wisdom of Teams: Creating the High-Performance Organization). Why not start with something simple, real simple? Establishing rules and protocols of operation for the team.

As a first step in launching a new team, I usually start with an initial meeting (the duration varies based on the size of the team and the project being undertaken) during which I ask the team members to establish their working protocol – how they wish to work together.

Here are some of the questions the team members need to answer prior to doing anything else – including actually starting the project:

  • What do we wish to accomplish together?
  • What ground rules will we play by?
  • How do we make decisions?
  • How long can discussions and debates go on for? Do we use time-boxes in meetings? For decision making?
  • How do we resolve disagreements?
  • How often do we need to meet? For how long?
  • How will we communicate with each other?
  • How do we keep track of our action items?
  • How do we deal with team members who do not live up to the team’s expectations?
  • What rules do we have to include new team members? To expel existing team members?
  • How will we know if we are successful as a team?

Some of these questions may appear to be trivial. While establishing a team protocol doesn’t need to take a lot of time (and can easily be combined with a team building activity), not establishing such a protocol will quickly lead to inefficiencies, waste of time, and increased frustration for the team members. Want a few examples?

  • Did you ever find out that some project team members’ personal objectives had nothing to do with the project? Trying to motivate those people will drain your energy and your focus.
  • Has a detailed technical decision ever been taken by a senior manager with weird consequences? Guidelines may have prevented the decision from being escalated in the first place.
  • Have you participated in meetings where key people didn’t show up or showed up late with the consequence of having some decisions over-ruled? Determining up front the rules around meeting attendance and decision making will greatly alleviate such frustrations.

These are only a handful of examples but time and again, I have had the privilege to launch teams on the right foot. The consequences are positive and the cost is minimal. It may not be as cheap as buying sandwiches for the team during the project kick-off but the investment will last much longer.

Posted on: 04-11-2011
Posted in: Collaboration and teamwork, Communication and knowledge sharing, Project Team

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

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

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

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…

Trust

  • 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…

Retrospection

  • 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…

Collaboration

  • 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?

Posted on: 04-21-2010
Posted in: Agile, Collaboration and teamwork, Communication and knowledge sharing, Environment, Learning, Management, Transition to Agile

Comments from the peanut gallery… 3

Let me start by affirming I am in favor of democratic structures in “for-profit” organizations. I believe people should have a say in decisions, no doubts about that. In my opinion, the concept of democracy is closely related to the wisdom of crowds where diverse opinions from a larger group of people systematically leads to better decisions and solutions.

Comments from the peanut gallery

Comments from the peanut gallery

Now that’s established, I want to make a distinction between democracy (participating in the selection of the decision) and the discussions leading to decisions – which I will call the debates.

The debate is not a democratic process. Let me use an example to explain why I have an issue with opening debates to crowds.

Following another disappointing loss of our local hockey team, a few colleagues gathered in the cafeteria were loudly debating their opinion on the cause of the team’s poor performance…

  • Paul: “Price [the goal tender] doesn’t deserve to play with the team, he lacks consistency…”
  • Mario: “What do you mean? Price did what he could but he can’t do everything. With Markov’s and Gill’s injury our defensive line is weak and Price is too often left to himself…”
  • Richard: “Did you guys watch the same game I did? We have no offensive line. We gave a lot of talent to bring Cammalleri to Montreal but he is just not the scorer we need and nobody actually has the right skills…”
  • Mary: “No, no. It’s the referee who influenced the game…”

I’ll stop here but that is enough to show my point. How many of these people do you believed played in the NHL? None.

How many of these people took coaching training or even played junior hockey? None.

How many of these opinions are actually useful to make the right decision? None. That’s right!

This is what my wife calls the “comments from the peanut gallery“.

Let me use another brief example to prove my point further.

Assume a skilled people manager joins his highly technical team for a brain storming session. The team is looking to improve performance of their Java application and the tension in the room is high.  The manager – for sake of clarity, doesn’t have a clue about computer programming except maybe for a 3 hours introduction to Microsoft Excel taken 5 years ago – suggests to replace the framework and maybe the sorting method. What are the chances that his suggestion will be accepted? None.

The same situation applies when people with no management experience or training jump into a discussion about people management or organizational strategies. To take part of the discussion there needs to be a few pre-requisites. It is not enough to want to participate in the discussion, to really contribute people need: knowledge of the topic being discussed, experience, and a willingness to move the debate forward.

What is not needed is a personal opinion without facts, knowledge or experience but this is exactly what happens when a debate is open to the general public. When these conditions are met (knowledge, experience, and willingness), people should be welcomed to join the discussion so to take advantage of the wisdom of crowds. When these conditions aren’t met, people should stay on the sideline waiting for the debate to end and propositions to be open for selection.

Just like in the Canadian Parliament, a selected (elected) number of people were selected to represent others in the discussion. Once options are selected, the democratic process can allow people to vote.

Posted on: 11-25-2009
Posted in: Agile Management, Collaboration and teamwork, Communication and knowledge sharing, Leadership, Meetings

Using silence as a communication tool 2

 

Using silence as a communication tool

Using silence as a communication tool

Have you ever heard the expression “You have two ears and only one mouth so you should listen twice as much as you speak”? What about “Silence is gold”? It doesn’t matter if you have never heard these expressions, you will still be able to take advantage of this under-utilized ability.

Chances are, you have participated in meetings or conversations where people talked, and talked, and talked for no apparent reason only to show-off in front of colleagues or their boss. When you sit back and listen, you often notice that despite the noise, the conversation isn’t moving forward. In these instances, people are concerned with demonstrating something (their knowledge, their communication ability, their decision-making power, etc.) rather than really communicating. Most of the time people talk too much. Way too much.

Over the years I have found that using silence is very useful. Contrary to what a former boss told me, being reserved in a meeting and participating when necessary is much better than talking all the time in order to get noticed. If the only way for you  to get noticed in your organization is by talking a lot during meetings, you are in trouble. I would think that conversations are probably as shallow as the level of competence of the management team – but I digress.

Many people assume that communicating is simply talking nonstop. They are not aware of how they are being received and perceived by others. Using silence on the other hand is very useful. As a communication tool, silence provides a few interesting benefits:

  • it allows you to actually listen to other people’s perspective;
  • it lets your colleagues complete their thoughts without rushing;
  • it provides space for people to express their opinions or feelings;
  • it makes people feel their perspective is valued;
  • it allows you to organize your thoughts and emphasize one point or another;
  • it builds anticipation in your audience and allows them to follow your message;
  • it leaves room in the conversation to allow people to share something they might want to tell you but weren’t quite ready to do so;
  • during negotiation, it adds a little pressure on the other person to possibly offer a better deal;
  • and as a bonus, it improves people perception of you – you no longer appear self-centered and in need of visibility.

When your ego and your need for power drive your conversation, you are certainly missing out on critical pieces of information. Humility and serenity will increase your communication ability. If you are able to develop the ability to remain silent for a certain amount of time in a conversation, you will quickly discover the benefits.

Posted on: 11-23-2009
Posted in: Communication and knowledge sharing, Meetings, Perception

It's a bad idea to hire super heros 3

 

Don't hire super heros

Sure, super heros are powerful. They have strengths and abilities that regular humans don’t possess. They can always be counted on to save the day and they wear cool suits! But…

Have you considered the damage a super hero can do to your team, to your department, and sometime to your organization?

Over the years, I have had the opportunity (?) to work with super heros. Every time, the initial reaction is always the same – wow, this individual is amazing! Eventually, after I analyze the accomplishments, look at the situation and the impact on others around the super hero I am less than impressed. Here’s why:

  • Having a super hero hides the real underlying problems because the super hero will always save the day – no matter what caused the situation to start with. Unless you have a retrospective or a post-mortem following the resolution of the problem, you will not be able to assess if the problem is likely to happen again in the future;
  • A super hero causes resentment within a team since he is typically the one rewarded for the efforts. In addition, a super hero loves the spotlight and will seldom share it with other people who helped resolve the crisis;
  • A super hero thrives on solving problems and some have been known to spark an explosive situation so they can jump in later on to resolve it.

Everything is not lost if you have a super hero on your team. Next time he saves the day, simply thank him for his action and then reward the individual who suggests and implements a way to prevent the situation moving forward.

 

 

Posted on: 11-4-2009
Posted in: Collaboration and teamwork, Communication and knowledge sharing, Leadership, Management, People Management

Happy 1st anniversary Analytical-Mind 3

1 year of blogging

1 year of blogging

It has already been 1 year since I published my first blog post. As I quickly figured out, Blogging is like training! It requires time, energy, and commitment and when it is done regularly, it is a great exercise for the mind.

In the 154 posts published since the beginning, my blog has evolved – a lot. I admit, I originally had no real focus and mostly expressed personal opinions.

  • Since I like to read, in the beginning I was publishing book reviews which eventually led me to share my virtual bookshelf.
  • After joining Pyxis, I naturally started discussing Scrum and Agile principles.
  • I then moved on to Agile Business Intelligence which was more technical in nature and attempted to launch a collaborative book.
  • Until I discovered something I was much more passionate about – Leadership and Strategy.
  • Once in a while, I would point out Other interesting blog posts.
  • For several months now, I have been focusing mostly on new organizational structures, communities and agile management.

I realize my style is a mix of situational analysis (analytical-mind), philosophical perspective, suggestions and advices sometime using humour to convey my message.

Finally, my most popular posts were:

  1. How I failed as a Product Owner and the lessons I learnt in the process
  2. The Prisoner’s Dilemma: Applying Game Theory to Agile Contracting
  3. My Virtual Bookshelf
  4. Less projects were reported to be successful in 2008
  5. Scrum Artifact: Burn Down Chart

In order to improve my blog moving forward, I did a 1-year retrospective and I asked myself 3 simple questions.

What do I feel I did well?

Although there were times when I didn’t publish for a few weeks, I remained committed to maintaining the blog. Not all posts have the same depth but I try to share my perspective and discuss a different way of doing things with the objective of improving people’s quality of life at the office and improving the return on organizational investments.

What do I feel I didn’t do well?

Until I decided which track to follow, I wasn’t focused. It was difficult to retain readers since they didn’t know what to expect.

What do I need to start doing?

Increase collaboration with other bloggers and stay focused on the topics of innovative management, new organizational structures, and leadership.

Posted on: 10-27-2009
Posted in: Communication and knowledge sharing, Leadership, Management

Why didn't my plant tell me it was drowning? 3


The problem with slow feedback loop

The problem with slow feedback loop

I recently re-read The Fifth Discipline: The Art & Practice of The Learning Organization. Peter Senge talks about the impact of feedback loops in individuals and organizations’ learning process. Feedback loops (aka retrospection) are also critical in Scrum and the Agile approach.

What does this have to do with my plant you ask? Simple. I was the victim of a slow feedback loop myself and it almost killed my wife’s beautiful Azalea.

A few weeks ago, I bought my wife a beautiful Azalea for our anniversary. It was in full bloom. It was simply beautiful!

In addition to looking very nice, the salesperson at the flower shop told me it was low maintenance. This is a key feature for us since we usually don’t do very well with house plants. I bought the plant and took it home.

Following the instructions, we would add water every few days and made sure the plant didn’t have too much direct sun light. One morning, we noticed some of the beautiful flowers were starting to dry out. Experience tells us that when something is dry, you add water – so we did. We increased the frequency of the watering ritual from once every 4-5 days to once every 2-3 days.

Much to our surprise, the situation didn’t improve. Actually, it was even worst, more flowers were drying out – so we thought, let’s add more water. We moved the plant next to the kitchen sink so we would remember to add water every morning when preparing coffee. A week passed by and the results got worst. In addition to dry flowers, the plant was loosing all its leaves. It started to look pretty bad.

While I was preparing coffee this morning, I went to add water to the plant only to discover that the plant was immersed in water. There was so much water that it covered the earth in the pot! S*%t! We are drowning the plant!!

Then it hit me. Because we weren’t getting any obvious feedback, we assumed what we were doing was good and we continued until it was almost too late. Had we had indications sooner that our actions weren’t the right ones, we could have changed them and possibly address the right issue.

This is exactly what we teach our customers and what Peter Senge was explaining. Without rapid feedback loop, it may take a while for people to realize they have been doing something wrong.

Posted on: 10-13-2009
Posted in: Agile, Communication and knowledge sharing, Learning

The new employee has an opinion 0

You are the head (vice-president, director or manager) of your business unit and you recently hired a new employee*. This new recruit is filling in a key role and he/she is expected to deliver on his/her objectives.

You have translated the corporate vision and mission into SMART objectives (Specific, Measurable, Achievable, Realistic, Timely) and you think of yourself as an innovative leader and believe your team members need to be empowered. Obviously, this senior employee is not simply filling an execution role where he/she needs to do what he/she is told.

After a few weeks, the new employee comes to you with a different way of managing the team. His/her suggestion would most probably (in his/her mind at least) increase productivity and improve employee moral. Which of the following answers better reflect your reaction?

  1. Listen to the idea, politely smile and let the employee know he/she needs to wait 6 months before he/she is entitled to an opinion.
  2. Kindly listen to the proposal and let the employee know that he/she has it all wrong. Things don’t really work the way he/she perceives it.
  3. Thank the employee for volunteering the information and ask him/her to prepare a lengthy SWOT analysis (strength, weakness, opportunity, threat) in the hopes he/she abandons the idea.
  4. Ask the employee to join you for lunch in order to better understand his/her perspective.

These weren’t trick answers. I have personally seen these 4 answers being given to new employees in various contexts. The point here is not to criticize the answers or the approach used but to highlight a key issue behind the answers.

Answer #4 is obviously the only one opening up a dialogue where the employee and the manager talk about perceptions, culture and work environment. Assuming the feedback was brought forward in constructive manner, even if the employee’s observations were not accurate, it has the amazing benefits of making the employee feel good – someone wants to hear his/her perception – in addition to establishing a relationship between the employee and his/her manager.

Answers #1, #2, and #3 immediately show that the person in charge either feels they can’t learn anything useful from a new employee or don’t care to know what the new employee has to say. Once again, assuming the employee brought the feedback in a constructive fashion and even if the supervisor doesn’t have anything to learn, wouldn’t there be benefit in maintaining an open channel of communication between the manager and his/her team? Unfortunately, it seems many people do not think so.

* This exercise also works for external consultants.

Posted on: 12-30-2008
Posted in: Communication and knowledge sharing, Leadership

Popular Posts

  • Agile self-organized teams - is the team self-organized or not?
    01-25-2011
  • Agile transitions are hard. I wonder why people feel the need to control?
    10-5-2010
  • Which stance should I take? The 4 quadrants of Agile Managers
    12-20-2010
  • My Virtual Bookshelf
    01-24-2011
  • What is the job of the president in a self-organized company?
    10-18-2010

Blogroll

  • Agile Gardener – Gardening Agile Knowledge
  • Great Leadership – Opinions and information on leadership and leadership development by Dan McCarthy
  • John Baldoni On: Leadership, Leadership development, Managing people
  • Management 3.0 – Leading Agile Developers, Developing Agile Leaders
  • Management, Development, Complexity, and Me
  • Marshall Goldsmith On: Leadership, Managing people, Coaching
  • Pyxis Technologies
  • Umuntu – It's all about people and humans, anyone at all …
Avatars by Sterling Adventures
Recent Posts
  • Analytical-Mind has moved
    08-10-2011
  • Adapting your leadership style to the maturity level of your self-organizing team
    08-9-2011
  • Agile managers do not act like cowboys
    08-1-2011
  • 12 tips to be a better coach
    06-20-2011
  • Gartner's Enterprise-Class Agile Development Defined
    06-6-2011
Recent Comments
  • links for 2011-08-14 « Dan Creswell’s Linkblog on Adapting your leadership style to the maturity level of your self-organizing team
  • Michael cardus on Analytical-Mind has moved
  • Making The Entire Organization Agile | Pyxis blog on The myths of self-organized teams
  • Making The Entire Organization Agile | Pyxis blog on Yet Another Agile Maturity Model (AMM) – The 5 Levels of Maturity
  • Adapting your leadership style to the maturity level of your self-organizing team | Analytical-Mind on Seven wrong reasons to adopt Agile
About Me

Meta
  • Log in
  • Entries RSS
  • Comments RSS
  • WordPress.org
© 2008-2011 Martin Proulx