Category Archive for: ‘Transition to Agile’

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.

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.

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.

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.