For those of us who have been working with Agile for a while, the values, the principles, the approach, the methods and the practices are almost second nature but for those who start to enter the Agile world, the ramp up can be challenging – especially if you are looking at all of this from a management position.

After being asked by a few people “Where can I start if I would like to know more about Agile?”, I decided to put together this short list of reference material. There is also a good discussion happening on LinkedIn.

I am missing anything? Is there material you would recommend to managers?

What is Agile?

Agile software development refers to a group of software development methodologies based on iterative development, where requirements and solutions evolve through collaboration between self-organizing cross-functional teams.

The term was coined in the year 2001 when the Agile Manifesto was formulated.

Agile methods generally promote a disciplined project management process that encourages frequent inspection and adaptation, a leadership philosophy that encourages teamwork, self-organization and accountability, a set of engineering best practices intended to allow for rapid delivery of high-quality software, and a business approach that aligns development with customer needs and company goals. (Agile software development – Wikipedia)

“Agile Development” is an umbrella term for several iterative and incremental software development methodologies. The most popular agile methodologies include Extreme Programming (XP), Scrum, Crystal, Dynamic Systems Development Method (DSDM), Lean Development, and Feature-Driven Development (FDD).

While each of the agile methods is unique in its specific approach, they all share a common vision and core values (see the Agile Manifesto). They all fundamentally incorporate iteration and the continuous feedback that it provides to successively refine and deliver a software system. They all involve continuous planning, continuous testing, continuous integration, and other forms of continuous evolution of both the project and the software. They are all lightweight (especially compared to traditional waterfall-style processes), and inherently adaptable. As important, they all focus on empowering people to collaborate and make decisions together quickly and effectively. (Agile 101: What is Agile Development? | VersionOne)

Just what is agile software development? In 2001, a group of methodologists got together to agree on a common set of guiding principles around effective software development. Rather than summarize their agreements here, I’ll point you to their “agile manifesto”.

From a pure definition standpoint, agile is a conceptual framework generally centered on iterative and incremental delivery of working software, driven by the customer. The iterative part suggests that we are repeating, or iterating, a complete lifecycle of development over a short, fixed span of time. With each of these iterations, we ship some working subset, or increment, of features. (A Brief Introduction to Agile — Developer.com)

What is Scrum?

Scrum is an agile approach to software development. Rather than a full process or methodology, it is a framework. So instead of providing complete, detailed descriptions of how everything is to be done on the project, much is left up to the team. This is done because the team will know best how to solve its problem. (Introduction to Scrum – An Agile Process)

Scrum is an iterative, incremental framework for project management and agile software development. Although the word is not an acronym, some companies implementing the process have been known to spell it with capital letters as SCRUM. This may be due to one of Ken Schwaber’s early papers, which capitalized SCRUM in the title.

Although Scrum was intended for management of software development projects, it can be used to run software maintenance teams, or as a general project/program management approach. (Scrum (development) – Wikipedia)

Scrum is an agile framework for completing complex projects. Scrum originally was formalized for software development projects, but works well for any complex, innovative scope of work. The possibilities are endless. (Scrum Alliance -What Is Scrum?)

The Scrum Roles

Scrum has three roles: Product Owner, ScrumMaster, and Team. (Scrum Alliance -Scrum Roles)

Tips for an Agile Transition

Organizational Impact of an Agile Transition

When development teams adopt agile practices, product management is often caught off guard by the amount of work added to their already overflowing plate. Agile calls for new product management skills and traditional staffing models do not typically accommodate the new product owner role. Given that most product managers are already overworked, how can they manage these new activities to derive more value from software projects and products? (InfoQ: How Product Management Must Change to Enable the Agile Enterprise)

Agile methodologies are helping software organizations stay competitive by delivering products more frequently and with significantly higher quality. Making the switch to agile development also challenges traditional notions of project management, introducing new ways of managing time, cost and scope. Learn how to successfully manage agile projects with the resources below. (Agile White Paper: The Agile Project Manager | VersionOne)

When an organization starts to explore Scrum, there’s often an uncomfortable moment early on when someone points out that the role of “manager” seems to be missing entirely. “Well I guess we’ll have to just get rid of ‘em all!” wisecracks one of the developers, and all the managers in the room shift uncomfortably in their seats. (Scrum Alliance -Manager 2.0: The Role of the Manager in Scrum)

About Agile Coaching

Gartner’s analysts (Thomas Murphy and David Norton) predict that by 2012 “agile development methods will be utilized in 80% of all software development projects”. The authors explain that although Scrum will continue gaining in popularity over the coming years, organizations will not be successful in their transition unless they move toward a team-focused culture (Gartner Predicts 2010: Agile and Cloud Impact Application Development Directions | Analytical-Mind)

In their recently released study “Agile Development: Mainstream Adoption Has Changed Agility“, Forrester reports that “35% of respondents stated that Agile most closely reflects their development process”. The report is based on Forrester’s/Dr. Dobbs Global Developer Technographics Survey, Q3, 2009, which surveyed 1298 application development professionals. (Forrester Reports “Agile Development: Mainstream Adoption Has Changed Agility” | Analytical-Mind)

Recommended Blogs

Recommended Books

You might be interested in these related posts:

1. Scrum Role: Scrum Master
2. What is Scrum?
3. Scrum Role: The Scrum Team

We are currently recruiting Agile Organizational Coaches.

Main duties and responsibilities

The Agile organizational coach works directly with the Information Technology and Business management teams to help leaders assimilate and apply the Agile principles to their day-to-day activities.

The organizational coach helps transform the traditional management style to a more Agile approach. Thus, the coach helps managers to properly assess the differences between the current situation and a set target. He then works with the managers to define a suitable plan and take concrete actions to address the obstacles encountered during the transition. More specifically, the organizational coach:

• Through appropriate training, educates managers to the application of  Agile to their management style;
• Creates groups (communities) of interest and exchange to assist managers in their development;
• Meets with various stakeholders to understand the fears, challenges, and resistance and provides the necessary support to help them;
• Participates in various management committees to train members of such committees and support them in their development.

Requirements

• Have held a management position within a large organization;
• A minimum of fifteen years of experience in managing software development teams;
• A minimum of two years experience in an Agile development environment;
• Significant experience in project management;
• Bachelor’s degree in business administration, commerce or management.

Assets

• Certified ScrumMaster;
• Bilingual (English and French);
• Experience in the financial sector (banking, insurance, investment);
• Certification from the International Coach Federation.

General Criteria

• Political acumen and diplomacy;
• Ability to find solutions win-win situations;
• Passionate and self-motivated;
• Team player;
• Talented facilitator;
• Understanding of business needs, business processes and organizational dynamics of a business.

You might be interested in these related posts:

1. What the heck does an Agile Organizational Coach do?
2. What consultants don’t tell you before you begin an agile transition – Part 4: Why a coach is useful
3. Currently recruiting Agile consultants

If you are in the process of transitioning your organization to an Agile approach, you have certainly realized that moving to Agile impacts more than the software development team – if you haven’t realized it yet, you will eventually find out the hard way

In a large scale transition, it is necessary to work with the various managers to help them understand and assimilate the principles related to Agile and make them integrate those principles into their day-to-day actions. Therefore, an Agile Organizational Coach helps managers change their management approach to a leadership style better suited for an Agile environment.

The transition to a new leadership style is not limited to the software development teams. It also applies to the interactions and relationships with the business team’s managers. Making managers more Agile requires changes in their behavior, more specifically, it requires managers to:

• Transfer certain powers to the team members themselves so they can determine how best to accomplish their tasks;
• Define the desired vision, to adapt to the context of each team to ensure alignment with the overall objective of the project and ensure cohesion between the teams and their members;
• Accept and publicly endorse the idea that the status quo is no longer acceptable and that the old methods are no longer adapted to the new reality;
• Adapt their style of management when necessary to use an inclusive and democratic approach.

As such, the role of the Agile Organizational Coach is to:

• Educate managers through appropriate training;
• Create groups (communities) of interest and exchange to assist managers in their development;
• Organize individual and group meetings with various stakeholders to understand their fears, their challenges, their resistance and to provide the necessary support to help;
• Work with groups who require special support during the transition;
• Participate in management committees where the presence of an agile expert is required.

You might be interested in these related posts:

1. Looking for a challenge? You may be interested in an Agile Organizational Coach Job
2. What consultants don’t tell you before you begin an agile transition – Part 3: Impact on the functional and people managers
3. What consultants don’t tell you before you begin an agile transition – Part 4: Why a coach is useful

In line with my earlier post (Are you an Agile Leader? – Nine questions for people managers), I like to use metaphors to explain various concepts but I also like metaphors to determine the profile of the people attending my presentations. I recently used the cereal metaphor presented below (the power point slide is available here).

In addition to being a good ice-breaker for the presentation, this slide usually gets people talking about (and sometime defending) their management style. Needless to say the “Fiber One” managers are often the ones who find the agile concepts harder to grasp.

Which cereal are you?

You might be interested in these related posts:

1. I don’t feel so good – I’m a people manager in an Agile organization
2. How do you react to bad news? Assess your management skills
3. Don't Sell Buzzwords to Business Leaders, Learn How to Describe Real Value

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?

You might be interested in these related posts:

1. What consultants don’t tell you before you begin an agile transition – Part 2: Impact on some of the traditional roles
2. You are not doing SCRUM if you don't have a ScrumMaster
3. Nothing interesting – Just making sure Technorati will track this blog!

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

You might be interested in these related posts:

1. The Nine Dimensions of Agile Leadership (revisited and improved)
2. The 7 Dimensions of an Agile Project Team
3. Agile Leadership (Agile Management) – part II

As a follow-up to my post on Agile Leadership, I have described the 7 dimensions of an Agile Project Team and what it means to deliver results in an Agile context. This forth (out of five) post briefly looks into the Agile Work Environment (or Agile Work Space) to successfully support the delivery of results by the project team.

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done – Principles behind the Agile Manifesto.

As suggested by the Manifesto, providing the right environment will support a fast paced, entrepreneurial, flexible and autonomous culture allowing the project team to focus on their objective while enjoying their environment.

A few questions to assess the work space configuration of the project team:

• Are all team members co-located?
• Does the physical environment support effortless communication?
• Are team members within 10 meters (30 feet) of a white board?
• Are team members allowed to stick post-it notes to the walls around them?
• Does the project team have access to natural light?
• Are team members allowed to decorate their work space?
• Do the project team members have access to free good-coffee?
• When necessary, do team members have access to private rooms to concentrate on their activities?

Needless to say, the right work environment can have a significant impact on the project team’s performance. More specifically, the right work environment should support the team’s autonomy, ability to communicate and collaborate. It should support the use of the right processes and tools to be efficient while allowing them to enjoy their surroundings.

You might be interested in these related posts:

1. The “Best Agile Work Space” Contest (The BAWS Contest)
2. Day one in an Agile environment
3. Do you know why you show up at work every day?

As mentioned in my guest post on Management 3.0, times are changing and many organizations are finding ways to lead people to deliver better results.

Having spent most of my professional career in the software development industry, either as a consultant or as an employee of large corporations, it is obvious that many of my inspirations for leadership came for the technology side of things. I quickly realized two things:

1. Working with technology opened my perspective to more innovations and allowed me to develop a willingness to continuously improve what was around me – not only the technology but the tools and the processes in order to derive better performance from people and later on to strive for a more balanced work-life,
2. I noticed that many people in organizations who could change the way people were managed were caught in their old paradigms:
   • Senior managers who had power refused to change and were counting the days until retirements,
   • Middle managers who had an open mind, had no time to implement innovations or had no power to do so,
   • Support departments were more interested in maintaining status quo after years of implementing policies and procedures and weren’t so inclined to look for better methods.

Once in a while, an external consultant would present some promising avenue to help improve performance and morale but their attempt would vanish once they closed the doors behind them.

Then came Agile. Although the Agile Manifesto was published in 2001, I discovered the underlying principles years later and it became obvious to me that what was recommended for software development organizations would certainly work, outside the technology departments. For almost two years, I have been analyzing the principles, reading books, and working with colleagues and clients to derive an improved method of working. From my “Rebel Leadership” concept came the “Agile Leadership” approach.

You might be interested in these related posts:

1. Agile Leadership (Agile Management) – part II
2. Agile Principles Applied to Management
3. Agile in a Command-and-Control Organization : What to do when upper management forces overtime?

A few days ago, I broke down the key dimensions associated with an Agile Project team in an attempt to explain Agile to managers but I purposely excluded the concept of RESULTS in order to remain focus on the key dimensions. As such, the main reasons why an organization would choose to go Agile haven’t been specifically addressed in my previous post.

Working software over comprehensive documentation - Manifesto for Agile Software Development

Yes, working software is the goal of the project team but the ultimate goal of the organization remains to maximize return on investment (ROI). The next logical question should be “What does maximizing return on investment (ROI) mean in an Agile context?”

In my opinion, maximizing ROI in an agile context means:

• Paying the right price for the developed software while getting the most business value – the right price means the cost associated with the labor without significant overhead costs;
• Developing a competitive advantage by adapting to changes in the environment while quickly and incrementally developing the results in order to capture the market opportunities;
• Increasing customer satisfaction by giving them the product they need, when they need it;
• Allowing project team members to develop their skills while having fun.

Too many times, maximizing ROI simply means increasing throughput and/or decreasing cost – no matter what. Delivering results in an agile context should not limit its focus on the very short term but also take into consideration a longer term investment in the capabilities of the team members.

You might be interested in these related posts:

1. The 5 Dimensions of Leadership in an Agile Context
2. FAQ: Communities in the context of business
3. We have a huge budget and too much time to complete our business intelligence (BI) project

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.

Agile Leadership - The Project Team

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.

You might be interested in these related posts:

1. The 5 Dimensions of Leadership in an Agile Context
2. The Nine Dimensions of Agile Leadership (revisited and improved)
3. Project Charter – Agile Project