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.

In a large scale transition similar to the one we have undertaken a few months ago, it is difficult (and maybe impossible) to transition all the teams / departments at once. Similar to the prioritization of the product backlog, we have selected a handful of projects to launch immediately. Unfortunately, this means that many (many more) projects will not begin their transition for a while since the organization we work with has decided that coaches are required to help them succeed.

As such, we have decided to implement a strategy for those “out of transition” teams. Below is the approach we selected in order to make the transition successful without negatively impacting the performance (and the workload) of those directly involved in the transition. Based on our experience, we felt it was important to have a strategy (albeit minimal) to support other projects to be implemented using an Agile approach.

The reasons why it is important to have a strategy for those “out of transition” projects are as follows:

• To maintain a unifying vision of what we are trying to accomplish with Agile;
• To maximize our efforts in the development and selection of tools supporting Agile;
• Not to ‘abandon’ the projects that were not deemed highest priority;
• For other projects to be executed successfully in an Agile mode even if they are not part of the intial selection.

Therefore, we suggested having a reduced service catalog for the “out of transition” projects. Examples of services that can be offered are:

• Training courses offered to the selected projects could also be attended by “out of transition” participants;
• A simple audit of the “out of transition” projects’ practices and high level recommendations for improvement;
• Limited support;
• Access to the corporate wiki for information, knowledge sharing and best practices.

So far, the recommendation has been well received by the “out of transition” projects. In the months to come, we will be able to determine if we made the right decision.

In conversation with potential clients, I almost always ask them the following question: “Why do you want to move to Agile?” and in most circumstances their answer makes sense. I would get answers such as:

• We are hoping to improve productivity;
• We aim to decrease time to market;
• Turn over has been high and we wish to implement an approach that will increase employee morale;
• We need to reduce costs;
• Etc.

And then, I get what I would call “wrong answers”. Those answers address my question at face value but also show that the decision has not been evaluated for more than thirty seconds. Here are 7 “wrong reasons” to adopt Agile. Go ahead – share yours!

1. We recently attended a conference and Agile is becoming more popular. If others are doing it, so should we.

2. Because Gartner and Forrester say so.

3. Because employees asked us to do so.

4. Some of our people are available to experiment with a new approach.

5. Our competitor is gaining market share and they are using Agile. We need to use the same approach if we want to be able to compete.

6. We produce too much documentation.

7. Because our boss told us to do so.

Other interesting articles:

Destination: Agile Top Eight Reasons Why Organizations Are Making the Switch

3 Reasons Why I Would Not Do Agile Project Management

Introducing Agile Methods: Mistakes to Avoid

Why Agile doesn’t sell with Management ?

11 Ways Agile Adoptions Fail

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?

Following my posts on delivering results in an agile context, the 7 dimensions of an agile project team and their agile work environment, this fifth and final post on Agile Leadership presents the “Leadership” level of the model. I’m hoping to help managers, leaders, and stakeholders better understand which behaviors to modify in order to obtain better performance and improve employee satisfaction within their organization. I came up with five dimensions associated with Leadership in an Agile context.

Before I begin, I want to make a distinction between management and leadership. Over the years, the terms “leadership” and “management” have often been used as synonyms. To distinguish the two words I would specify that leadership is “transformational” in nature while management is more “transactional”.

Leadership

Leadership has been described 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)

Servant Leadership

Servant-leaders achieve results for their organizations by giving priority attention to the needs of their colleagues and those they serve. Servant-leaders are often seen as humble stewards of their organization’s resources (wikipedia)

Management

Management in all business areas and human organization activity is the act of getting people together to accomplish desired goals and objectives. Management comprises planning, organizing, staffing, leading or directing, and controlling an organization (a group of one or more people or entities) or effort for the purpose of accomplishing a goal (wikipedia)

Goal Setting

Goal-setting ideally involves establishing specific, measurable, attainable, realistic and time-targeted objectives. Work on the goal-setting theory suggests that it can serve as an effective tool for making progress by ensuring that participants have a clear awareness of what they must do to achieve or help achieve an objective (wikipedia)

A few questions to assess the Goal Setting dimension of the Leadership model:

• Are the team members objectives aligned with one another?
• Are the suggestions coming from the retrospection of the team taken into consideration in the objective settings?

Performance Management

Performance management includes activities to ensure that goals are consistently being met in an effective and efficient manner (wikipedia)

A few questions to assess the Performance Management dimension of the Leadership model:

• Does the leader clearly define the objectives of his people?
• Does the organization measure its progress toward its goals?
• Is the performance measured at the team level in addition to the individual level?
• Does the company evaluate both the individual’s work behaviours and outcomes against the defined objectives?
• Do the team members receive timely and frequent feedback?

Remuneration

Remuneration is pay or salary, typically a monetary payment for services rendered, as in an employment (wikipedia)

A few questions to assess the Remuneration dimension of the Leadership model:

• Do managers mostly rely on intrinsic (rather than extrinsic) motivation?
• Does the remuneration model reflect the individual’s contribution to the team or is it based on seniority?
• Is the compensation model clearly understood by all team members?
• Is the leader rewarded for the development of his members?
• Do team members participate in the definition of the compensation of their colleagues?
• Is the compensation model strictly based on individual performance?

Coaching

Coaching refers to the activity of a coach in developing the abilities of coachees. Coaching tends to focus on the achievement by coachees of a goal or specific skill (wikipedia)

A few questions to assess the Coaching dimension of the Leadership model:

• Does the leader support its members in their skills and competences development?
• Does the leader take the time to teach his team members on how to increase their skills and better themselves?
• Is the leader selected by the team members?
• Is the leader evaluated by his team members?

Change Management

Change management is a structured approach to transitioning individuals, teams, and organizations from a current state to a desired future state (wikipedia)

A few questions to assess the Change Management dimension of the Leadership model:

• Does the leader work with the team members to establish a clear change management strategy?
• Does the leader acknowledge that the pace of change is different for all team members?
• Does the leader deal constructively for team members’ resistance to change?

Leader’s Qualities

Finally, in order to assess if the leader has the right qualities to be successful in an agile environment, I have selected a handful of qualities the leader should clearly demonstrate.

Does the Leader display the following qualities?

• Making decision when necessary
• Enthusiasm / Optimism
• Humility
• Respect
• Trust
• Integrity
• Confidence

In my quest to better define what Agile Leadership is and in an attempt to help managers, leaders, and stakeholders understand which behavior to modify in order to achieve a successful Agile transition within their organization, I broke down the key dimensions associated with an Agile Project team - an upcoming post will present the Agile Leadership dimensions. Based on experience and relying on numerous books and blogs published on the topic, I have extracted seven key dimensions in an attempt to generalize the concept.

My goal is to help teams and organizations going through an Agile transition understand which dimensions to modify to change the status quo. I will define at length and provide reference material in an upcoming post.

The 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. A team can be divided into sub-teams according to need. Usually project teams are only used for a defined period of time. They are disbanded after the project is deemed complete. Due to the nature of the specific formation and disbandment, project teams are usually in organisations. A team is defined as “an interdependent collection of individuals who work together towards a common goal and who share responsibility for specific outcomes of their organisations”. An additional requirement to the original definition is that “the team is identified as such by those within and outside of the team” – wikipedia

Out of the roles defined in Scrum, the project team is a key area impacted by an Agile transition. Many changes are required in order to take full advantage of the transition – from a motivational and a performance perspective. In this context, the project team encompasses the members of the core project team that are working toward the same end goal, which is to deliver results.

The 7 Dimensions of an Agile Project Team

There are tens of variables that have been identified as key success factors for a successful agile transition. My objective is to group them under 7 dimensions. This does not mean that other dimensions aren’t important or that I offer an exhaustive list. My goal is simply to summarize the success factors under a handful of dimensions.

Autonomy

Autonomy refers to the capacity of a rational individual to make an informed, un-coerced decision – wikipedia

The concept of self-organised team is one of the pillars of Scrum. In his recent book Drive: The Surprising Truth About What Motivates Us, Dan Pink presents the differences between empowerment and autonomy (more on his book in an upcoming post) with such compelling arguments that I felt “autonomy” is a much better description of what we aim to achieve with the implementation of Scrum. As such, the team needs to have the ability to determine the sequence of the tasks to be executed, the assignment of each task, the method used to complete their work and other rules required to allow the team to achieve performance while enjoying their work.

A few questions to assess the Autonomy dimension of the project team:

• Are people on the team able to make decisions themselves and accordingly adapt to changing situations?
• Does the team determine “how” to solve their issues?
• Can the teams select the standards and practices that better allow them to produce the right solution?
• Can the team divide the work as it chooses?
• Do training, holiday, and vacation time get cancelled when the project falls behind schedule?
• Can the team members determine who is on or off the team?
• Does the team maintain a high rate of productivity without being overworked?

Competences

Competence is a standardized requirement for an individual to properly perform a specific job. It encompasses a combination of knowledge, skills and behavior utilized to improve performance. More generally, competence is the state or quality of being adequately or well qualified, having the ability to perform a specific role – wikipedia

As with other expertise, project team members must possess and/or develop certain competences in order to take advantage of the new approach. Although some of the new skills are technical in nature, many are softer interpersonal skills.

A few questions to assess the Competences dimension of the project team:

• Does the product owner possess the right skills and abilities to successfully execute his role?
• Are the employees always in an optimal role (matching the requirements with the capabilities and interest of the individual)?
• Do the team members have the required knowledge and expertise to successfully deliver the expected solution?

Accountability

Accountability is the acknowledgment and assumption of responsibility for actions, products, decisions, and policies including the administration, governance, and implementation within the scope of the role or employment position and encompassing the obligation to report explain and be answerable for resulting consequences – wikipedia

As an Agile team relies on its autonomy to complete its work, the concept of accountability becomes even more critical than it is in a traditional team structure. The lines between the responsibilities of each of the team members become more blurry as tasks and timelines get re-assigned in order to meet the expected results.

A few questions to assess the Accountability dimension of the project team:

• Do the team members clearly understand their responsibilities?
• Are the team members committed to the delivery dates?
• Are all the delivery dates clearly communicated and known by all team members?
• Does the team successfully deliver functional software at the end of each iteration?
• Does the team know its velocity?

Collaboration

Collaboration is a recursive process where two or more people or organizations work together in an intersection of common goals by sharing knowledge, learning and building consensus – wikipedia

Collaboration is a central them in Agile and it is more than two people working side-by-side. In the context of Agile, strong collaboration is a critical quality the needs to be demonstrated by the project team and throughout the duration of the project.

A few questions to assess the Collaboration dimension of the project team:

• Is the business representative an active member of the project team?
• Is it accepted that the detail of both the requirements and the solution will emerge as the project progresses?
• Does the project team accept changing business needs?
• Do team members accept tasks outside their role and responsibility in order to successfully deliver?
• Are developers included in the planning process?
• Are the team members heavily involved in the decision making process?
• Is the product owner willing to discuss trade-offs between scope and schedule?

Communication

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

Just like collaboration, communication is an elusive concept that is fundamental to the success of the project team.

A few questions to assess the Communication dimension of the project team:

• Are the right tools in place to facilitate the communication process between team members?
• Is a wiki in place to centralize access to key project information?
• Does the team have a collaborative space allocated to them?

Continuous Improvement

Continuous improvement is an ongoing effort to improve products, services or processes. These efforts can seek “incremental” improvement over time or “breakthrough” improvement all at once. Delivery (customer valued) processes are constantly evaluated and improved in the light of their efficiency, effectiveness and flexibility – wikipedia

The empirical nature of Scrum imposes continuous improvement to the project team. In order to implement the process for the team members to learn and develop their skills, certain aspects need to be established up front and improved throughout the project life cycle.

A few questions to assess the Continuous Improvement dimension of the project team:

• Are the team members’ performance periodically evaluated and honestly communicated?
• Are the best practices challenged on a regular basis?
• Does the team use an empirical process to learn and improve their performance?
• Does the team hold retrospection sessions to improve?
• Does the team reserve time to implement improvements?

Processes and Tools

Process typically describes the act of taking something through an established and usually routine set of procedures to convert it from one form to another – wikipedia

A tool, broadly defined, is an entity that interfaces between two or more domains; that facilitates more effective action of one domain upon the other – wikipedia

Finally, to take advantage of the changes an Agile transition brings, the project team needs to use different tools and processes in order to avoid falling back to their old patterns.

A few questions to assess the Processes and Tools dimension of the project team:

• Does the product owner understand that solving 20% of the problem delivers 80% of the value?
• Is the team composed of a group of 5 to 9 people?
• Is the team capable of starting the projects with incomplete requirements?
• Are projects broken down into smaller components?
• Are the iterations time-boxed?
• Are the required processes clearly defined and communicated to all team members?

I am currently working on a more exhaustive questionnaire to help those going through a transition monitor their progress. I hope to share the questionnaire shortly.

As a follow up to my previous posts (part 1, part 2, and part 3), this fourth and final article written in collaboration with my colleagues Stéphane Lécuyer, Jean-René Rousseau, Sylvie Trudel, Joël Grenon, and Eric Laramée, presents why the use of external coaches is a key success factor for an organizational transition to Agile.

---

Most people in organizations that initiate an Agile transition will tell you that, to be successful you need to do more than reading Succeeding with Agile: Software Development Using Scrum and taking a ScrumMaster Certification. Some organizations succeed without external help while others prefer to follow Forrester’s recommendation and hire consultants to support them. In this context, there are three types of coach.

The Organizational Coaches

The Organizational Coach uses a support approach coupled with an advisory role to assist the various stakeholders in developing the required skills to maximize the benefits of their Agile transition. As a member of the project steering committees and working directly with the individual managers involved, the Organizational Coach helps transform the traditional management style used within the organization. Thus, the coach helps the various stakeholders assess the gap between the current situation (current management style) and the expected target (new leadership style). The coach then works with the stakeholders to define an appropriate plan of action and take concrete steps to address the obstacles encountered during their personal development. This coaching approach offers the following benefits:

• Establishes a partnership between the Organizational Coach and the client with the intend to achieve a successful transition;
• By working directly with the individuals and their team, the Organizational Coach helps them move from the current state to the desired situation;
• Supports the stakeholders via discussions, suggestions and observations to help them change their management style and to ensure the development of the skills required to reach the desired level of management Agility;
• By pushing the leaders outside their comfort zone, the Organizational Coach attempts to change the status quo.

The Organizational Coach typically plays the role of the Agile expert at the management level. In addition, the Organizational Coach works directly with managers from both the technology and the business side of the organization in order to help them assimilate and apply the Agile principles to their daily management activities. As such, the Organizational Coach support the management team in their development of an Agile Leadership better suited for the success of the transition.

The Team Coaches

Ultimately, the objective of the Team Coach is to develop the skills and competencies of the ScrumMasters to become quickly autonomous and derive the maximum benefits of the Agile approach. More specifically, the Team Coach supports the start of the projects, provides recommendations for improving the implementation of Scrum throughout the projects and disseminates the best practices. The Team Coach promotes and facilitates a cohesive adoption of Agile within the teams. In addition to supporting the execution of the project, the Team Coach works closely with the ScrumMasters to develop and implement activities to improve the team’s performance and to develop the skills of team members and the ScrumMaster. The coach’s role is to share his expertise and best practices with all team members in order to help accelerate the development of their skills and quickly make the team more efficient.

The Engineering Practice Coaches

The Engineering Practice Coach supports the Team Coaches by specifically addressing the engineering practices used within the software development process. As such, the Engineering Practice Coach reinforces software development best practices, helps the various teams identify and remove impediments, and foster team self-organization. As an expert on agile development and testing technologies and practices, the Engineering Practice Coach stays abreast of the latest industry tools, developments, and best practices, and broadly share and evangelizes those developments inside the organization. The Engineering Practice Coach brings a broad expertise of engineering practices in the Agile development team, including:

• Test Driven Development (TDD),
• Various Agile automation test frameworks (eg. GreenPepper),
• Release planning techniques,
• Story point estimation,
• Integration of software engineering best practices (eg. code reviews, unit tests, etc.), and other techniques that enable teams to deliver high quality software products in an Agile structure.

For example, within each development team, the Engineering Practice Coach ensures that the engineering practices supporting the iterative and incremental development are known, understood, and properly implemented. In addition, the Engineering Practice Coach may also accompany the architecture team in the selection of tools and technology.

Conclusion

We hope you enjoyed these short articles and have found useful information to help you succeed with your organizational transition. Do not hesitate to send us an email if you would like additional information about a specific topic.

As a follow up to my previous posts (part 1 and part 2), this third post in a series of 4 short articles written in collaboration with my colleagues Stéphane Lécuyer, Jean-René Rousseau, Sylvie Trudel, Joël Grenon, and Eric Laramée, addresses the impact of an Agile transition on the functional and people managers.

---

Transforming the Managers

In an Agile transition, it is necessary to work closely with the various people managers to help them truly understand and assimilate the principles related to Agile so they can integrate them into their actions. Based on our experience, in addition to team coaches we recommend the use of organizational coaches to help managers change some of their management approaches and use a leadership style that is more appropriate for the new Agile teams.

The transition to a new style of leadership is not limited to software development teams, it also applies to the interactions and relationships with the managers of the business groups – typically the product owners.

Getting managers to become more Agile requires changing behaviors and using a more democratic approach to management. More specifically, the people managers need to:

• behave more Agilely by transferring certain power to the teams members themselves and to let them determine how best to accomplish their tasks;
• empower their teams through self-organization and commitment to results;
• transfer decision-making to individuals who are closest to the activities;
• demonstrate greater receptivity to ideas and innovation emerging from their teams;
• clearly define the desired vision;
• adapt to the context of each team to ensure alignment with the overall objective;
• ensure cohesion between the teams and their members;
• capture the strategic objectives of the transition in order to demonstrate the importance of the project;
• support the sense of urgency;
• provide the necessary resources so they can position themselves as leaders in this transition;
• accept and publicly endorse the idea that the status quo is not acceptable and that the old methods are no longer adapted to the new reality.

In this context, the managers themselves become change agents within their department and in the organization to;

• integrate those who are convinced to take part in the center of expertise;
• systematically involve business people in the transition;
• adapt their style of management when necessary to use an inclusive and democratic approach.

In this perspective, the ‘command and control’ management style needs to evolve into a servant leadership so that contributors can take responsibility and demonstrate stewardship. The intend is to be supportive through tangible measures so the team members can quickly adopt new ways of doing things.

It is worth asking what approach will be used to achieve such a transition for managers. With the experience gained during our previous mandates, we recommend to use the following means to achieve the desired results:

• awareness of the managers of the requirements related to an Agile transition through appropriate training;
• creation of groups (communities) of interest to share learning, fear, reactions, etc.;
• implementing individual meetings or group meetings with different stakeholders to understand the fears, their challenges, their resistance and provide the necessary support to help;
• provide an organizational coach to individuals or groups who require special attention during the transition;
• identification of committees where the presence of the coach is required to help move the transition forward;
• establishing and defining the parameters required to support new objectives related to the transition;
• preparation and dissemination of communications about the progress of the project.

In next week’s post, we will explain in Part 4: Why a coach is useful for a successful Agile transition.

As a follow up to my previous post, this second post in a series of 4 short articles written in collaboration with my colleagues Stéphane Lécuyer, Jean-René Rousseau, Sylvie Trudel, Joël Grenon, and Eric Laramée, addresses the impact an Agile transition typically has on some of the traditional software development roles: the project manager, the architect, the business analyst, and the QA specialist.

---

One of the first obstacle we routinely encounter in coaching teams through their Agile transition is the mapping of the Scrum roles to the traditional roles. Since Scrum only has three roles (product owner, scrum master, and scrum team), what happens to the project manager, to the architect, to the business analyst, and to the QA specialist after the transition?

Based on our experience, here are possible strategies to properly map the traditional roles to the three roles defined by Scrum.

The Project Manager

Traditionally, the project manager is responsible for determining who, what, and when activities need to be performed and then to ensure the team complies with the plan that was prepared to meet the budget, time and scope constraints.

With the traditional approach, project management is based on compliance with the plan while Agile and Scrum propose a different approach where maximizing the business value is the main vector of project management. Under this new approach, the product manager needs to collaborate with the team members and delegate to them some of his traditional responsibilities since they will determine who does what, and when within the constraints of the project.

In this context, the role of the Scrum Master is to enforce the process and seeks to build an efficient self-organized team. To the question “do we still need a project manager in Agile?”, experience shows us that in most organizations, the answer is yes.

The need for accountability, regulatory compliance and alignment with the framework and IT governance are not covered by the role of the Scrum Master and as such remain the responsibility of the project manager.

However, the project manager needs to adapt its management style and use leadership rather than authority with the team to get things done. In the context of a multi-team organizational structure, the presence of a project manager is also valuable, where he is coordinating the teams and the synchrony between them and between entities external to the project teams.

From our experience, some project managers are more willing to become product owners while others will feel challenged by the role of Scrum Master. In the end, it will be the responsibility of the organization to determine how to redefine the roles and their associated responsibilities.

The Architect

Similar to the project manager, the architect is known to play a different role post-transition compared to that required in traditional development teams. He must act as a consultant to the teams and provide them with the necessary support instead of dictating the rules and guidelines to be followed. The architect should also be familiar with the concepts of emerging architecture, where just enough architecture is planned to allow the team to innovate and find the optimal solutions.

The architect then acts as a catalyst for sharing best practices within the organization. Here is a list of practices summarizing the changes of behavior for the architect:

• Is an active member of the development teas, helping to build the right software and acting as consultant;
• Does not attempt to predict the future, he provides a coherent vision but knows that tomorrow’s problems will be easier to solve tomorrow;
• Is changing its architecture in an incremental way, leaving room for emergence;
• Does not seek to document everything to perfection, he focuses on a few relevant diagrams and documents the best practices based on his audience;
• Seeks to validate its concepts through concrete experiences.

Once again, although the role of the architect does change after an agile transition, it remains an important role to be filled.

The Business Analyst

The business analyst is another role that seems neglected by Scrum. To ensure close collaboration between the team and the Product Owner, Scrum ensures that the necessary elements are effectively communicated directly to the team without a formal and complex documentation. However, to ensure continuity of information, we know that functional documentation that is adequate and representative of the software to be developed is essential.

The business analyst becomes a valuable contributor to the Product Owner. The responsibilities of the business analyst are as follows:

• Supports the Product Owner in gathering and writing the required stories;
• Does just enough analysis for the functionality to be carried out during the next iteration;
• Prepares and updates documentation used at the end of each iteration;
• In collaboration with the QA Specialist, helps determine the quality assurance strategy.

In a multi-team context, the business analyst may be called upon to play the role of Product Owner. He then becomes responsible for core components of the product within the various sub-teams.

The Quality Assurance Specialist

Quality is a fundamental concern in Agile project management and each iteration should produce an increment of quality software. To do this, we recommend incorporating a quality assurance specialist within the Scrum teams, and right from the start of the project. A QA specialist assigned to a Scrum team has the following responsibilities:

• Participates in planning sessions to raise issues relating to quality;
• Helps clarify the definition of “Done”‘;
• Prepares plans for acceptance testing;
• Validates the increments of product delivered.

Other Roles

As will be presented next week in “Part 3: Impact on the functional and people managers”, managers also get impacted by an Agile transition.

If you have been reading about Agile for a while and are interested in a transition or if you have already initiated a transformation, you have previously heard all the benefits that Agile can bring to your organization but …

Are you aware of the impacts such a transition will have on your organization? On your team? And on yourself? Would you know how to deal with these impacts?

If you believe that implementing Agile within a company simply means reducing documentation, standing up during daily meetings, using whiteboards and post-it notes, and getting rid of the project manager, you will certainly be shocked to see how profound the changes can be.

In a series of 4 short articles written in collaboration with my colleagues Stéphane Lécuyer, Jean-René Rousseau, Sylvie Trudel, Joël Grenon, and Eric Laramée, we aim to highlight some of the most common (and rarely described) impacts an Agile transition can have on an organization. The articles will be published weekly and will cover the following 4 impacts.

• Part 1: Impact on the organization
• Part 2: Impact on some of the traditional roles
• Part 3: Impact on the functional and people managers
• Part 4: Why a coach is useful

---

Adopting Agile practices is not a trivial change; it requires support and time to become effective. The use of external coaches, training materials, and internal support groups can greatly increase the speed and success of adoption. - Forrester Reports “Agile Development: Mainstream Adoption Has Changed Agility”.

Many organizations rely on external consultants to help them successfully transition to Agile. Others initiate a small transition after having researched the best practices. Having gained experience from the implementation of Agile within organizations over the last 8 years, we can attest that the impacts related to the establishment of an Agile development approach affect many areas in the organization. Through our experience, we have prepared a high level description of potential impacts you may want to anticipate before getting deep into your transition.

Impact	Description
Organizational structure	Most large organizations have a traditional hierarchical structure. When launching a new project, project managers must draft team members from various functional departments. The Agile approach highly recommends restructuring project teams around a dedicated multidisciplinary team.
Decision making and governance	The Agile approach seeks to create autonomous and self-organized teams. It invites people managers to apply a different style of leadership to their teams and pushes the decision-making authority to the level closest to the activity being performed. Under such model, managers provide guidelines to support the decisions rather than act as the ultimate decision makers.
Compensation mechanisms	To support the team concept advocated by Agile, compensation mechanisms should avoid individual rewards and foster a compensation model that takes into account the results of the entire team. The compensation model must be aligned with the business objectives and the commitment to deliver value.
Relationship with customers	At the heart of the Agile approach, is the concept of working closely with the customer (Product Owner). The relationship with the business customers will be strongly affected by the Agile transition. The traditional form of contract and the expected availability of customers must be revised in order to ensure an effective transition.
Development processes	The standard development process used within the organizations must be revised and typically “trimmed-down” to match Agile values, principles and practices. The revision process should include the initial phases of implementation, deployment and operation.
Tools and technology	The acquisition of new tools to support Agile project management and software engineering practices is inevitable. Although the addition of new tools is not in the heart of an Agile transition, it is nevertheless important to maximize the effectiveness in implementing the new process.
Work space organization	To foster collaboration within teams, organizations may need to rearrange the workspace in “war room” or remove office partitions to consolidate all the team members. This in an attempt to improve communications and collaboration between stakeholders and develop a team spirit and strong collaboration. In addition, easy access to certain items such as whiteboards, removable flip charts, Post-it notes is often recommended.
Behaviors	In addition to practical project management and engineering approaches Agile also has a system of values and principles. In addition to ‘Do’ Agile development, individuals are asked to ‘Be Agile’, that is to say, to be collaborative and transparent, be committed and responsible and also to seek excellence. As Agile approaches are based on greater accountability of individuals and the self-organization of teams, the leadership style of managers and the need to clearly define a shared vision change every day’s actions.
Roles and responsibilities	All roles are affected by the arrival of an Agile approach. As will be presented in Part 2: Impact on some of the traditional roles, while some people might gain power, others will feel they are losing. New skills will be acquired as motivation and engagement of stakeholders will also be affected.

Next week’s post will address more specifically to impact on the role of the project manager, the architect, the business analyst, and the QA analyst.