As I was heading back home, I wondered – is coaching something we do or the way we are? So once I got home, I looked up the definition for both words (coach & coaching) and came across Visual Thesaurus (image below).

The reason I was wondering is that when I meet people who “do coaching”, they always say “I’m a coach”. I’m not actually disputing that they are (or aren’t) coaches, it’s just that I wonder if they have assimilated the coaching role so much as to BECOME coaches. Maybe it’s simply like someone who defines himself as being an accountant, an engineer or a clown when in reality it is because their day-job is accounting, engineering or clowning.

This leads me to wonder, if accountants stop doing accounting after 5 pm, does it mean coaches stop coaching after work hours? It seems to me, based on the many coaches I personally know that very few actually stop coaching – that’s almost a way of being – coaching the kids, sometime the spouse, some of the friends and so on.

Should we call ourselves coaches only when we are on duty or is there a better name to describe bipeds who provide coaching to people around them?

Personally, I have decided a while back that I do not define myself as a coach. Coaching is simply a tool for me – a very effective one, I would add – that I use to help people accomplish their objectives.

Imagine my surprise when a candidate for an agile organizational coach role within our organization shared with me his perspective on this topic.

“Can you share with me your reasoning?”, I asked him intrigued.

The candidate went on to explain that people need direction and that people cannot self-organized without clear objectives and direction.

Indeed, I thought to myself. Who said people and teams shouldn’t be given clear objectives. On the contrary, in my opinion, clear goals are necessary for teams to organize otherwise you end up with a bunch of people who will try to find a reason, a purpose why they are all together – and their self-created goal may very well be different from what you had in mind in the first place.

Where I have a problem is that people associate self-organized teams with “abandoned teams” meaning you simply let the team figure it out – whatever “it” is.

In order to reach the level of autonomy they need to demonstrate extra-ordinary performance, teams need to reach the right level of maturity. Consequently, the manager’s leadership style is critical to achieve that objective. Within Pyxis, we often rely on the combination of the situational leadership and the group development stages to determine the proper level of involvement from the manager.

(Tuckman’s stages of group development, Situational leadership theory)

One of the way to achieve the right level of maturity is for agile managers to determine WHAT must be accomplished and let the team determine HOW it will be done – I already shared my opinion on this topic. Granted, things are more complex that I make them sound in this post but self-organization is indeed possible when the right environment is created for the team – including clear objectives – and it is then given the latitude to operate and determine how best to achieve the given goal.

If only managers would be willing to let go some of their (need to) control and trust the teams, a higher level of performance can be attained.

As you may have guessed, the candidate wasn’t called back for a second interview…

I bumped into Steven last week. Steven is director of application development in a large organization and like most manager in his early forty’s, he looked tired and although he is usually a happy individual, his smile wasn’t radiant this time.

In agreement with his teams, Steven initiated an Agile transition a few months ago. I was part of the team who presented to Steven the benefits of a transition and the impact on the team members and their managers. I saw Steven again in a group training I was giving a few weeks after the beginning of the transition to managers and executives. That time again, Steven was very excited and motivated about what he was hearing, except that during the training I could see the light bulbs over his head and in the questions Steven was asking – how is this going to impact my role as a manager? Steven saw the obvious benefits and understood some of the changes he would need to make to his leadership style but I could tell, it hadn’t fully sinked in.

So here we were, less than 3 months in the transition and Steven wasn’t as chipper as he used to be…

• Me: “Hey, Steven. You look tired. How are you doing?”
• Steven: “I’m OK… I’m tired… [silence] The transition is killing me!”
• Me: “How so?” [I asked anticipating what he would tell me next]
• Steven: “The team is having a blast and I can see their performance has increased compared to the past but I don’t think I can cope with this new approach”
• Me: “You seemed so excited about the transition when we started. What changed?”
• Steven: “I now realize what you meant when you talked about changing my leadership style and my role. I’m still up to the challenge but my boss is totally clueless about all of this”
• Me: “What do you mean? Haven’t you brought him in the loop from the beginning?”
• Steven: “Yes. Yes, I have but that’s not the problem. The team’s performance increase is directly linked to the new approach they have been using and the fact that I leave them a lot of autonomy but my boss still asks me to behave like I used to – like he manages his team today. That’s where it hurts the most. I can pretty much deal with everything else but I feel like I’m stuck between a rock and a hard place”

Unfortunately, we (as consultants) do not do such a good job at highlighting this fact before we begin a transition. We work closely with the teams to help them adopt better methods and practices, to increase their overall performance by allowing them to be self-organized. We work on getting the teams to a highly performing level. Then we go get executive sponsorship to secure the initiative (and the budget) and make sure we get support to handle difficult issues but what about the people in the middle?

We develop training programs for Agile managers and we support them with organizational coaching but we don’t do such a good job at telling them upfront how much pressure they will be under once the transition begins. How much their role is likely to change and their leadership style needs to be adapted to the new reality.

For those who haven’t yet have felt the pressure, here are some examples of what to expect:

• You may be willing to trust your team and let them self-organize but is your boss in agreement with this new approach? Will he be as involved (micro-managing) in your activities as he used to be? And more importantly, will he be expecting you to be as involved with your team as you used to be?
• You may be willing to tolerate mistakes in order to increase your team’s learning and with a strategic perspective to increase long term performance but will you hear about your inabilities to control your team during your next performance review?
• You already produce status reports, dashboards, emails and others information to keep everyone (including your boss) informed of what is going on in your unit. Will you need to translate everything that the Agile team is producing to fit the traditional reporting mechanisms? Can you challenge what information is currently being produced to ensure it does bring value to people?
• You expect your team members to handle the details of their activities and you believe in actually seeing (touching, feeling) the end results while your management team expects you to assess progress using Gantt charts. Do you need to educate your entire organization to the new approach? Does the fact that you are adopting Agile make you the evangelist for the entire organization?

Obviously, I don’t mean to scare anyone – especially the managers – with regards to adopting Agile. The approach has a lot of merit and value for many organizations but in order to help with adoption, coaches and consultants need to pay attention to the people in the middle and help them find their new place, otherwise we are very likely to find serious resistance and potential failure of such initiatives – nobody likes to be stuck between a rock and a hard place…

My colleague François Perron launched a very interesting discussion on our private wiki – “As a coach, what to do when executives and upper management force the project team to do over time in order to meet deadlines?”.

As you can probably guess, this initiated very interesting discussions and an obvious reaction to such an approach.

Everyone agreed that due to the project visibility and the position of the organization within its market, the project launch date was critical. Everyone also understood that the organization had very few options so nobody debated the need to achieve results. The discussion was strictly around which measures to use in an Agile context.

I’ll admit up front that I am biased toward intrinsic motivation (I really loved Drive by Dan Pink) and the fact that it is well suited for an agile environment.

As such, my first impression to the conversation that was going on were:

• Does the organization wish that employees spend more hours at the office (attendance) or would they prefer more engagement (commitment)?
• If their choice is to increase the hours of attendance, imposing overtime will achieve this goal while giving them a false sense of increased performance. People will show they are working longer hours but the real throughput is unlikely to be much higher. In addition, software development is a brain intensive activity and reducing the amount of rest people get is likely to increase the number of mistakes they make.
• On the contrary, if the organization wanted more involvement, the inclusion of team members in determining the best way to achieve the results would probably come to a better decision – even possibly leading the willingness to do over time

It appears to me that by forcing overtime, the executives and senior managers will probably collect their bonus and congratulate each others in the short term only to realize in the longer term that they have simply pushed the problem forward for others to deal with – and possibly request more over time in the long run.

At the Agile 2010 Conference this week, out of the two hundred or so sessions presented, a number of them talked about the role of the manager in an Agile team. A few people believe managers are no longer necessary once the team has self-organized while others say people managers are still required. Either group failed to provide compelling arguments for their position.

The notion of self-organized teams keeps gaining visibility and acceptance. Those who have adopted the approach can’t stop talking about the benefits. At the same time, people realize that managers are unlikely to disappear from the organizational landscape anytime soon. In this context, it is with a mixed-feeling that Agilists talk about the role of the people manager in an agile organization – mostly as something not so useful but that the team needs to keep around in order to maintain their autonomy – something similar to the appendix.

The most common explanation for the appendix’s existence in humans is that it’s a vestigial structure which has lost its original function – source wikipedia

Then a few things happened.

First, I got to attend Michael Spayd‘s session called “Blueprint for an Agile Enterprise: Plans, Tools & Tech to Build a Human Enterprise”.

Want your whole organization to be more like an Agile team? Starting teams is well understood; expanding Agile to the organization is definitely not. Using 8 years experience applying organization development to Agile, we’ll unfold a 7 layer organizational architecture for building a human enterprise. Each level has an overall perspective, specific tools and key practices. Part tutorial, part demo, we’ll create a change plan for one participant’s organization, exploring culture, leadership, change, team performance, and management’s role. You’ll leave with a plan template and many ideas – source Agile 2010 Program

Then, I went to Damon Poole’s session called “Getting Managers and Agile Teams Out of Each Other’s Hair”.

One of the most talked about and least well understood concepts in Agile is the “self-managing” team. This session will provide a new perspective on self-management by examining the external roots of the practice and by taking a bottom-up look at what it is, the benefits, and how it works. We’ll see how twelve widely adopted Agile practices contribute to self-management by reducing and/or redistributing traditional management activities. These practices provide a framework for delegation, communication and coordination; and encourage team ownership, commitment and accountability – source Agile 2010 Program

Finally, I also attended Jim Highsmith session called “What do Agile Executives and Leaders Do?”

In some circles agile executives and leaders are admonished to buy pizza and get out of the way. In others they are asked to be supportive of self-organizing teams. But leading agile organizations requires more. There are specific activities that help build agile organizations that can weather business turbulence. This session will explore those activities that an agile leader or executive must “do,” including: revising performance measurements; facilitating self-organizing teams; developing strategies for operational, portfolio, and strategic agility; and assessing how agile to be source Agile 2010 Program

After the sessions, I sat in the lobby of the conference and read some of the blog feeds I subscribe to and came across these…

• Esther Derby’s ONE-ON-ONES WITH SELF-ORGANIZING TEAMS
• VersionOne’s Self Organizing and the “M” word

Obviously, something’s up!

The role of a traditional people manager

In many organizations and depending on their level, people managers are expected to plan, direct, organize and control (Deming‘s Plan-Do-Check-Act) – more specifically, the role of the manager is to:

• Define the individual objectives
• Assign work to team members
• Determine priorities of the tasks
• Monitor progress of the activities
• Make decisions for the team
• Get visibility into the work of the team
• Mentor and train employees
• Protect the team’s financial and human resources
• Provide career development opportunities
• Build relationships with other departments and teams
• Motivate the team members
• Communicate information

What self-organization removes from the equation

Once the concept of self-organized team is implemented, there are a few things that were traditionally the responsibility of the people manager that now fall on the team. The activities are:

• Assigning work – team members now select their tasks instead of the manager
• Determine priorities – team members now determine the order in which they should to complete their work
• Monitor progress – team members track their own progress and make it visible and accessible to those who need to know
• Make decision for the team – within the team, team members get to make their decisions
• Get visibility into the work – team members track their own progress and make it visible and accessible to those who need to know
• Mentor and train employees – when possible, team members may decide to implement a mentoring program within the team
• Motivate – self-organized individuals are known to be more motivated than traditional teams, hence the reduced need for the people manager to retain this activity

So what is left for the people manager?

In order for the people managers to transform into Agile leaders and feel as part of the team, we already stated they need to modify their role. The agile manager will achieve higher level of performance and possibly increased personal job satisfaction by macro-managing – working with an increased perspective as opposed to getting into the details. As such, the activities the agile managers need to retain are to:

• Define high level objectives for their team and department instead of focusing on the tasks
• Determine priorities in the objectives of the team and department instead of the activities
• Monitor progress toward achieving the objectives
• Coach employees
• Continue to protect the team’s resources
• Support employees in their career development
• Build relationships with other departments and teams

I realize that this type of transition is easier said than done but with the willingness to recapture an important role as part of the team and with some external help, the traditional managers don’t have to became extinct professionals.

Last week, I attended the breakfast conference presented in Montreal by Ken Schwaber.

As always, Ken gave a great presentation focusing on the “definition of done” in Scrum and the impact of incorrectly defining what done really means.

As I was listening to the presentation, I looked outside the window overseeing René-Levesque boulevard and noticed an asphalt truck and city workers filling a pothole – then it hit me… As interesting and valuable Ken’s presentation was, we need a systemic approach if we want Scrum to succeed in organizations. Let me explain…

Nobody likes to drive on a street with potholes. So what do cities do? Obviously, they fix them! If you live in Montreal, you realize that every year, the city fills thousands of potholes in an attempt to keep their streets in a good driving conditions but no matter how much efforts (and money) the city invests, the potholes keep appearing.

Isn’t this like implementing Scrum within an organization?

As attendees to Ken’s presentation, weren’t we simply like city workers attending an asphalt conference? It is as if an asphalt guru was explaining to us the right mix of tar and rocks to make the most resistant asphalt when in reality, the problem isn’t really with the asphalt itself but with the city’s traffic management approach.

Same goes for Scrum.

The definition of done is critical. The right people in the right roles is important. Dedicated teams members is crucial. But what about the managers in the organization? Are they supporting Scrum? I mean, are they really supporting the use of Scrum within their organization?

Don’t get me wrong. I truly believe doing Scrum the right way is critical but it is not sufficient to be successful. If your managers aren’t on board, you can try to implement as many of the Scrum best practices as you want – including the right definition of “done” – your teams will never reach the highest level of performance they could. Get the managers on board and your Scrum implementation will be greatly improved.

I am very aware of the previous debates on the need for an Agile Maturity Model (see the Other Useful Links at the end of this post). I actually agree with Esther Derby’s recent post …

How agile you are doesn’t matter. Whether you are 50 per cent agile, 90 per cent agile or agile through and through (what ever that means), doesn’t matter. What does matter is that your company is satisfying its customers, stakeholders, and employees. (Achieving Agility: Means to an End, or End in Itself)

But let’s face it, people like to know where they stand compared to others. Starting at a very young age, we have been raised and trained to compare our results to others in an attempt to reach the next level – whatever the next level may be.

We get into such comparison as:

• Are my grades better than Tommy’s?
• Can I run faster than Carl?
• Am I stronger than black belt Anna?
• Did I earn more frequent flyer miles than Frank?

It’s the same thing with Agile. People – managers and executives mostly – really have the need to know they are headed for the top of the maturity model. It may not make much sense but they have been raised and trained to measure, to compare, and to brag when comparing favorably or to adapt when comparison isn’t positive for them.

As I already stated, I agree with Esther when she says that it doesn’t really matter how Agile you are. What matters are the results. So along those lines, I believe it is important to associate the level of maturity and the related results which I believe exist and can be demonstrated.

Unfortunately, there isn’t much hard data to demonstrate that achieving a certain level of maturity provides x% of improved performance or y% cost reductions but most of us who have been implementing Agile within organizations would agree that that higher the maturity, the better the results. So it is based on these observations that I decided to present yet another Agile Maturity Model.

As recently reported by Forrester, Scrum being the most adopted Agile approach these days, the proposed maturity model heavily relies on the adoption of Scrum practices with a lesser consideration to other practices such as: Agile Modeling, Feature-driven development – FDD, Test-driven development – TDD, eXtreme Programming – XP, etc. By no mean I am rejecting or considering those other approaches non-important. I built this model mostly on Scrum because this is the comparison organizations are asking us to be evaluated on at this time.

The Agile Maturity Model

Level 1 – Team Level Maturity

At this level, team members have decided to adopt Scrum and/or software engineering practices without asking for approval from their manager. Some of the well known practices are used but without consistency.

Team

• A Scrum Master is in place
• The Team has adopted some of the Scrum practices and artifacts but may not use them consistently
• The process isn’t documented and tends to vary by project
• Agile practices have been self-taught
• Process is limited to the solution team
• The team doesn’t understanding the language used by the business representatives

Department

• Outside the team, almost nobody has heard or understand what Agile means
• Other teams are unaware or not interested in the approach used by the Agile team
• Mostly business as usual

Business

• Unaware or not interested in the approach used by the team
• Business as usual
• Complains that what the information technologies team delivers is not what is needed or asked for
• Misunderstanding of the language used for the development team

Project Managers

• Unaware or not interested in the approach used by the team
• Follow the traditional project management approach

Managers

• Unaware or not interested in the approach used by the team
• Business as usual

Results

• Team is slightly more productive
• Moral is slightly improved
• Much friction with project managers, people managers and the business as the team members try to teach people outside the team what Agile is and what it can do for them

Level 2 – Department Level Maturity

At this level, the practices adopted by the team members have started to be imitated by other teams within the software development department. Some of the managers have noticed the positive results of adopting the Agile approach and are tempted to replicate what they observed.

Team

• A Scrum Master is in place
• Some of the teams have adopted some of the Scrum practices and artifacts and are starting to use them consistently
• Consistency across the teams is uneven and mostly depends on the leadership and perseverance of a few individuals
• Some of the process is documented but it tends to vary by team
• Agile practices have been self-taught or a coach was hired to help the team launch their initiative
• Process is limited to the department

Department

• Mostly business as usual
• Agile is sometime discussed in departmental meetings with some interest from people outside the team immediately impacted
• An increasing number of teams are adopting Agile practices

Business

• A business analyst acts as the proxy for the business representative
• Unaware or not interested in the approach used by the team
• Collaboration between the development team and the business side remains mostly unchanged except maybe for increased interaction between the 2 groups
• Business decision are still mostly made by business analysts or architects

Project Managers

• Starting to be aware of the new practices used by some of the teams
• Mostly resistant to change since they are lacking information about the new process
• Follow the traditional project management approach
• Do not consider the Agile approach to be very solid for large scale projects

Managers

• Unaware or not interested in the approach used by the team
• Business as usual

Results

• Teams that have adopted the Agile approach are slightly more productive
• Moral is improving
• Productivity varies from one team to the next
• Some teams’ productivity is decreasing since they have hit important hurdles
• Some teams have abandoned the new approach and have gone back to their traditional approach
• Some friction between the development and the business teams in light of the new approach

Level 3 – Business Level Maturity

At this level, the solution teams have integrated the business people in the model. Collaboration (and trust) has increased and a partnership relationship is increasing.

Team

• Scrum Masters are in place
• The 3 Scrum roles are well understood and respected
• If there is more than 1 Scrum team, a Scrum of Scrum has been put in place
• External help has been used to achieve this level of maturity
• Team members are attending Agile conferences

Department

• There is confusion around the roles of: business analyst, architect, database administrators and project managers
• The process is documented and tends to be consistent across projects
• External help has been used to properly implement the Agile practices

Business

• A Product Owner is clearly identified and may be dedicated to their project
• The concept of incremental and iterative development is gaining more acceptance from the business representatives
• Process is slowly expanding within the business side
• Product Owners bring some of their colleagues to end-of-sprint demonstrations

Project Managers

• Starting to be aware of the new practices used by some of the teams
• Mostly resistant to change since they are lacking information about the new process
• Follow the traditional project management approach
• Do not consider the Agile approach to be very solid for large scale projects

Managers

• Awareness is increasing at the director level within IT and Business of the new Agile approach
• Many assumptions and misunderstanding remain
• A strong evangelist is in place to promote the new approach and bring together the IT and business side of the organization

Results

• Project teams using the Agile approach are more productive
• Moral of the people using Agile is much higher than those outside the Agile teams
• Some friction with project managers and people managers remain where most people tend to fall back to their traditional paradigms

Level 4 – Project Management Level Maturity

At this level, the project management approach is modified to include some of the Scrum practices. Although the department still mostly relies on the traditional PMBOK recommendations, Scrum has been integrated in the project management approach.

Team

• There is a clear segmentation between the role of the Scrum Master and that of the project manager
• If there is more than 1 Scrum team, a Scrum of Scrum has been put in place
• Interference with the team’s activities is almost eliminated
• The team is autonomous and the Scrum rituals and artifacts are respected and standardized

Department

• The department has adopted many of the Scrum practices and artifacts and are using them consistently
• Much of the confusion around the roles of: business analyst, architect, database administrators and project managers have been eliminated
• The process is documented and is consistent across projects
• External help has been used to properly implement the Agile practices

Business

• Product Owners are clearly identified and are dedicated to their project
• The project manager is well accepted and is part of the Product Owner team
• The concept of incremental and iterative development is fully accepted from the business representatives
• Process is expanding to the business side

Project Managers

• Projects managers are fully aware of the new practices used by the teams
• Resistance to change has been replaced with adaptation of the traditional approach to include a more Agile approach
• Agile is accepted as a solid approach for large scale projects

Managers

• Awareness of the new Agile approach is increasing at director level and above within the IT, Business, and Project Management organizations
• Some assumptions and misunderstanding remain for managers
• Training initiatives have begun for management and attendance is high
• A strong evangelist is in place at the management / executive level to promote the new approach

Results

• Project teams using the Agile approach are more productive
• Moral of the people using Agile is much higher than those outside the Agile teams
• Friction between traditional roles are being handled

Level 5 – Management Level Maturity

At this level, managers have adapted their management style to support an Agile organization. Organizational structures and reporting mechanisms are better adapted for collaboration and improved for increased performance.

Team

• Scrum Masters are in place
• The 3 Scrum roles are well understood and respected
• If there is more than 1 Scrum team, a Scrum of Scrum has been put in place
• External help has been used to achieve this level of maturity
• Team members are attending Agile conferences

Department

• The department has adopted many of the Scrum practices and artifacts and are using them consistently
• There is no confusion around the various roles surrounding the projects
• The process is documented and is consistent across projects

Business

• Product Owners are clearly identified and are dedicated to their project
• The project manager is well accepted and is part of the Product Owner team
• The concept of incremental and iterative development is fully accepted from the business representatives
• Process is expanding to the management level of the organization

Project Managers

• Projects managers are fully aware of the new practices used by the teams
• The traditional project management approach has been adapted to include a more Agile approach
• Agile is accepted as a solid approach for large scale projects
• Review the best practices to adapt to changing realities

Managers

• Have fully transferred the authority and responsibility to the teams to allow them to do their job properly
• Avoid interference and micromanagement
• Promote collaboration and teamwork
• Support continuous learning and do not systematically penalize failures
• Adapt their management style to the context of their team

Results

• The various projects using Scrum are more productive than those using a traditional approach
• Moral is high all around
• Friction around the new approach has disappeared
• Strong collaboration between all parties involved
• Organization is able to quickly react to changes in its environment
• Management is considering implementing Agile to projects that do not require software development

Level 6 – Corporate-wide Level Maturity

Utopia or the nirvana? At this level, the entire organization – the people, the processes and the tools are aligned with the Agile principles and values. As I haven’t had the opportunity to witness such an organization (yet), I am unable to describe the criteria to be used to qualify for this level.

Other useful Links

• The Agile Maturity Model (AMM) posted on April 1, 2010.
• Does Agile Need Its Own Process Maturity Model? posted on June 1, 2009.
• Scott Ambler Revisits Agile Process Maturity Models posted on April 27, 2009.
• Agile CMMI: Complimentary or Oxymoronic? posted on December 19, 2008.
• The Agile Maturity Model posted on August 2, 2008.
• Does the Agile Community Need a Maturity Model? posted on October 16, 2007.
• An “Agile Maturity Model? posted on June 7, 2006.

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.

A few weeks ago, I wrote about The Nine Dimensions of Agile Leadership. As a follow up to that post, I came up with a preliminary Agile Leadership Assessment Questionnaire. Without being scientific and statistically representative, this assessment highlights the strengths (and weaknesses) of the leadership supporting the agile initiatives.

Simply download the questionnaire and select your answers (column D) to each question. The second tab of the spreadsheet presents a graphical representation of the results (as shown below).

You can download and try the Agile Leadership Assessment Questionnaire for your projects. This work is licensed under a Creative Commons Attribution-Noncommercial 2.5 Canada License.

Share your thoughts with me on this tool.

Following an earlier post on this topic and based on the increasing popularity of Agile Leadership, I have revisited my previous model with the experience we are gaining with the transitioning a large Canadian financial institution. Although the transition is still underway, our increasing experience is allowing us to improve the model.

The fundamental objective of this model remains to increase return on investment (ROI) and employee satisfaction / motivation within the project teams while applying the 4 Agile values and 12 underlying principles.

LEADERSHIP

Leadership is stated as the “process of social influence in which one person can enlist the aid and support of others in the accomplishment of a common task” – Wikipedia.

Objectives setting and performance management

Goal setting involves establishing specific, measurable and time-targeted objectives - Wikipedia.

Performance management includes activities to ensure that goals are consistently being met in an effective and efficient manner - Wikipedia.

This dimension of the model focuses on:

• Using a clearly defined vision, identifying and communicating clear objectives so that people know what to do;
• Aligning the goals of the team members amongst themselves and with the focus on delivering business value to the organization;
• Providing frequent feedback to employees so they can adapt their performance accordingly;
• Evaluating the performance level of the project team, in addition to individual performance.

Management and leadership style

Management in all business areas and organizational activities are the acts of getting people together to accomplish desired goals and objectives - Wikipedia.

Leadership style refers to a leader’s behaviour. It is the result of the philosophy, personality and experience of the leader - Wikipedia.

This dimension of the model focuses on:

• Switching from a traditional “command and control” to a “servant leadership” style;
• Abandoning an autocratic and prescriptive style to make room for autonomy and emergence;
• Allowing space for teams to become autonomous;
• Adopting a situational leadership style based on the maturity level of the team;
• Evaluating the end results rather than the means used to implement the plan;
• Assisting the team in addressing its needs;
• Providing the necessary support to develop individuals;
• Giving people the right to make mistakes;
• Facilitating collaboration.

ENVIRONMENT

Surroundings are the area around a given physical or geographical point or place - Wikipedia.

Work environment and organizational culture

Organizational culture is an idea in the field of Organizational studies and management which describes the psychology, attitudes, experiences, beliefs and values (personal and cultural values) of an organization - Wikipedia.

This dimension of the model focuses on:

• Establishing a favorable work environment to support the success of an Agile project;
• Providing open and collaborative spaces;
• Providing simple tools such as whiteboards;
• Reserving small enclosed meeting rooms;
• Using furniture that can easily be moved;
• Providing hardware and software that reduces the costs and initial delays to start-up projects.

PROJECT TEAM

A project team is a team whose members usually belong to different groups, functions and are assigned to activities for the same project - Wikipedia.

Autonomy and accountability

Autonomy is a concept found in moral, political, and bioethical philosophy. Within these contexts, it refers to the capacity of a rational individual to make an informed, un-coerced decision - Wikipedia.

Accountability is a concept in ethics and governance with several meanings. It is often used synonymously with such concepts as responsibility,answerability, blameworthiness, liability, and other terms associated with the expectation of account-giving - Wikipedia.

This dimension of the model focuses on:

• Giving authority to the team to allow it to do its job properly;
• Transferring the authority and responsibility to the team:
  • The way to do things and organize work (the HOW?)
  • On the allocation of tasks and ideally on the composition of the team (the WHO?)
  • On the estimation of effort required to complete tasks (the HOW MUCH?)
  • It can even be the place (the WHERE?) and the work hours (the WHEN?)
• Avoiding interference and micro-management;
• Giving autonomy to individuals to make them accountable;
• Creating teams of reasonable size to facilitate collaboration and communication;
• Letting people who are closest to the action make the final decisions;
• Providing the necessary support when the team requests it.

Collaboration and teamwork

Collaboration is a recursive process where two or more people or organizations work together in an intersection of common goals - Wikipedia.

Teamwork is work performed by a team - Wikipedia.

This dimension of the model focuses on:

• Promoting collaboration and teamwork;
• Maintaining a climate of trust and respect within the team;
• Developing the concept of compromise;
• Taking a position of cooperation and negotiation rather than honoring contracts;
• Encouraging discussion and debate of ideas in order to bring out the best decisions.

Communication and knowledge sharing

Communication is a process of transferring information from one entity to another - Wikipedia.

Knowledge sharing is an activity through which knowledge (i.e. information, skills, or expertise) is exchanged among people, friends, or members of a family, a community or an organization - Wikipedia.

This dimension of the model focuses on:

• Encouraging the use of face-to-face communication;
• Providing opportunities for people to share information and knowledge;
• Establishing communities of practice to promote the exchange of knowledge;
• Making relevant information visible to all participants.

Skills and Professional Development

A skill is the learned capacity to carry out pre-determined results often with the minimum outlay of time, energy, or both - Wikipedia.

Professional development refers to skills and knowledge attained for both personal development and career advancement - Wikipedia.

This dimension of the model focuses on:

• Ensuring that participants have the skills required to successfully execute their tasks;
• Promoting training and development when the skills are not adequate.

Continuous improvement and organizational learning

Continuous Improvement Process is an ongoing effort to improve products, services or processes. These efforts can seek “incremental” improvement over time or “breakthrough” improvement all at once - Wikipedia.

Organizational learning is an area of knowledge within organizational theory that studies models and theories about the way an organization learns and adapts - Wikipedia.

This dimension of the model focuses on:

• Allowing the team to question frequently its good (and bad) actions in order to improve;
• Not systematically penalizing failures;
• Addressing recurrent problems;
• Documenting and make visible the organizational barriers;
• Reviewing the best practices to adapt to changing realities.

Processes and Tools

Process or processing typically describes the act of taking something through an established and usually routine set of procedures to convert it from one form to another, as a manufacturing or administrative procedure, such as processing milk into cheese, or processing paperwork to grant a mortgage loan, or converting computer data from one form to another - Wikipedia.

A tool is a device that is necessary to, or expedites, a task - Wikipedia.

This dimension of the model focuses on:

• Letting the best processes and tools emerging from the team members;
• Allowing the team to choose its tools and adapting its processes to maximize performance;
• Disseminating best practices to other groups;
• Ensuring that the team has set its own rules of operation.

I am building and using this framework to help dissect the key components of Agile Leadership in order to help explain it to people managers and team members. Based on your experience, are there any dimensions missing?