Skip to content

Archive for March, 2010

A revolution. What management revolution?

Amidst a series of changes that impact our socio-economic environment, there is a small revolution taking place within organizations and as the next generation enters the workforce, many of the traditional assumptions will no longer hold, despite many people’s attempt to maintain the status quo.

Picture by chris.corwin

The level of skills, competences and intelligence that the average worker brings into work every day has no comparison to what they used to bring even decades ago. Workers are more educated, more connected and more aware than ever before of the possibilities being offered to them. These possibilities are not limited to the workplace but the same applies to their leisure, the travel plans, their food, etc. While many people remain captive of the old paradigms, they will soon uncover the world of possibilities offered to them, including in their workplace – and how work does not have to be so painful.

Some would call it innovative management, servant leadership, stewardship or coach as leader. Many of these approaches share an increased level of respect for people. Although I initially called the new management approach Rebel Leadership, I finally settled for Agile Leadership to explain my perspective of the new management model.

Over the next weeks, I will publish a few articles on this new management paradigm in an attempt to redefine management. Your thoughts and comments are welcome.

The 7 Dimensions of an Agile Project Team

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.

Picture by Yukon White Light

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.

Book I have Read – February 2010

Another monthly update on the books I read during the past month. For a complete a list, you can visit my virtual bookshelf.

1 Free Audio Book - Audible.com

The Halo Effect: … and the Eight Other Business Delusions That Deceive Managers – (also available in audio book format)

My Rating:

Stumbling on Happiness

My Rating:

le manager agile: vers nouveau management affronter turbulence

My Rating:

True Collaboration – Ants Vs Crabs

http://www.youtube-nocookie.com/v/qOe5Lmyyxiw&hl=en_US&fs=1&rel=0&color1=0x3a3a3a&color2=0x999999

What consultants don’t tell you before you begin an agile transition – Part 4: Why a coach is useful

As a follow up to my previous posts (part 1part 2, and part 3), this fourth and final article written in collaboration with my colleagues Stéphane LécuyerJean-René RousseauSylvie TrudelJoë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.

What is Agile Leadership?

Agile Leadership is the application of the Agile principles (as defined in the Agile Manifesto) to the leadership of software development endeavours.

In addition to encompassing the processes, tools and rules of Agile Scrum, Agile Leadership extrapolates them to change how teams and projects are managed within the context of the work environment and new leadership paradigms to deliver better results.

Agile Leadership Model

Where Agile Scrum mostly focuses on the organization of the project team, the roles and responsibilities of the team members, the artifacts, and the rules under which the project team operates, Agile Leadership includes the work environment as well as the specific leadership abilities expected from the managers and stakeholders.

Agile Leadership is a fundamental paradigm shift with the objective of making the project team successful and the people within the team happier in order to deliver better results. The shift mostly comes from the leadership (aka management style) and the rules used to govern the actions, the behaviours and the outcome of the team.

Getting managers to become more Agile requires changing behaviors and to use a more democratic approach to management. More specifically, Agile Leadership requires to:

  • Transfer certain powers to the team members themselves to let them determine how best to accomplish their tasks;
  • Empower the project team through self-organization and commitment to results;
  • Transfer decision-making to individuals who are closest to the activities;
  • Demonstrate a greater openness to ideas and innovations emerging teams;
  • Clearly define the desired vision and to adapt to the context of each team to ensure alignment with the overall objective of the project and to ensure cohesion between the team members;
  • Provide the necessary support and resources to the project team so they successfully accomplish the expected results;
  • Become a change agent within the organization by accepting and publicly endorsing the idea that the status quo is not acceptable and that the old methods are no longer adapted to the new reality;
  • Systematically involve business people in the definition and execution of solutions;
  • Adapt the style of management so as to use an inclusive and democratic approach.

In addition to bringing new concepts, Agile Leadership also revisits and adds to some of the concepts on which Agile Scrum relies. There is already much documentation (books, blogs, podcast, etc.) on the topic of Agile. In an upcoming blog post, I will add details to the areas of focus listed below and associate the underlying concepts with theories explained at length elsewhere in other areas of expertise such: as organizational behavior, organizational development, management science, and coaching.

What consultants don’t tell you before you begin an agile transition – Part 3: Impact on the functional and people managers

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écuyerJean-René RousseauSylvie TrudelJoë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.

Analytical_Mind – Twitter Weekly Updates for 2010-03-14

Powered by Twitter Tools

Gartner Predicts 2010: Agile and Cloud Impact Application Development Directions

Gartner studied the market and attempt to predict trends in their latest report: Predicts 2010: Agile and Cloud Impact Application Development Directions.

As organizations seek to improve productivity and reduce application operating and maintenance costs, we will continue to see an evolution of software development tools, platforms and practices. To take advantage of this, organizations must shift structures and practices while embracing new technologies — a challenging proposition.

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. As was mentioned in their previous report, very few organizations use a pure-Scrum approach and most rely on an hybrid approach (waterfall and Agile).

The report highlights that organizations struggle to implement true collaboration in the context of globally distributed teams. A situation that has amplified in recent years with outsourcing and off-shoring of software development projects.

In the other hand, the report confirms that teams who have successfully moved to Agile do see productivity improvements especially in “the flexibility of the development team to respond to shifting requirements”. This is especially true for web-based application developments where rapid responses to a changing environment is critical.

The authors point out that organizations need to properly invest in such a transition in order to achieve success.

Organizations that do not make use of key agile practices and do not invest in training and supportive tools’ infrastructure will find that a shift to pseudoagile, while potentially delivering a short-term productivity bump, will end in long-term declines in quality and productivity (…) the promise of four times the improvements in overall productivity has been and will be achieved by select organizations.

Gartner’s report highlights that “development organizations have been making a shift toward agile methods, but this is still slow to move beyond development, and often is a mixture of waterfall practices utilizing an agile or iterative project cycle”. The authors also recommend to “look for opportunities to utilize agile development practices, but recognize that it requires changes and commitment on the part of business and IT”.

Gartner concludes with a few recommendations to help organizations maximize their return from an Agile transition.

  • Recognize the cultural changes that are at the heart of agile.
  • Don’t allow agile excitement to drive cowboy-coding practices.
  • Agile requires discipline.
  • Recognize that scrum is only a partial solution, and focus on a collection of practices.
  • Find tools that enable collaboration and help automate repeatable, consistent practices.

Related documents:

What consultants don’t tell you before you begin an agile transition – Part 2: Impact on some of the traditional roles

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écuyerJean-René RousseauSylvie TrudelJoë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.

Follow

Get every new post delivered to your Inbox.