Skip to main content

Author: Martin Fenelon

Adapting Agile Principles for Successful Maintenance Hand-Overs

Over the 20+ years since the Agile Manifesto was created, more and more organizations see agility as key to success, especially for software development. Agile methodologies have revolutionized the way teams approach software development, emphasizing flexibility, collaboration, and continuous improvement. Ideally, there are Product Teams that handle development and maintenance throughout the product’s lifecycle. But what happens if development and maintenance are handled by separate teams?

This scenario can be problematic, especially if the teams are using are using different methodologies, or belong to different organizations (e.g. in-house and contractor teams). What happens when it’s time to transition control of a software project from the development team to the maintenance team? Can Agile principles be applied to facilitate successful hand-overs? In this article, we’ll explore how Agile principles can be adapted and applied to ensure smooth and successful software transitions.

 

Understanding Agile Principles

Before we delve into how Agile principles can be adapted for software transitions, let’s briefly review some the core principles of Agile methodology. Agile is built on four foundational values and twelve principles, as outlined in the Agile Manifesto. These values and principles emphasize:

  1. Individuals and interactions over processes and tools
  2. Working software over comprehensive documentation
  3. Customer collaboration over contract negotiation
  4. Responding to change over following a plan (flexibility)

 

Adapting Agile Principles for Transitions

Now, let’s examine how these Agile principles can be adapted and applied to facilitate successful software transitions:

  1. Flexibility: Agile methodologies prioritize flexibility and adaptability, allowing teams to respond to changing requirements and priorities. Similarly, in software transitions, flexibility is one key to navigating unforeseen challenges and adjusting plans as needed. By adopting a mindset embracing change, teams can proactively address issues and adapt their approach to ensure a smooth transition.
  2. Collaboration: Collaboration is a cornerstone of Agile methodologies, with teams working closely together to deliver value to customers. In the context of software transitions, collaboration between the development and maintenance teams is essential for success. By fostering open communication, sharing knowledge, and working collaboratively to address challenges, teams can ensure a seamless hand-over process.
  3. Continuous Improvement: Agile methodologies also emphasize continuous improvement, with teams regularly reflecting on their processes and seeking ways to enhance efficiency and effectiveness. Similarly, in software transitions, teams should evaluate their transition processes, identify areas for improvement, and implement iterative changes to optimize the hand-over process over time.

 

Advertisement
[widget id=”custom_html-68″]

 

Applying Agile Practices to Transitions

In addition to adapting Agile principles, teams can also apply specific Agile practices to facilitate successful software transitions. Some key Agile practices that can be applied include:

  1. Iterative Planning: Adopting an iterative planning approach to break down the transition process into manageable iterations, with regular checkpoints to assess progress and adjust plans as needed.
  2. Daily Stand-Ups: During the transition period consider holding daily stand-up meetings, where team members share updates, discuss progress, and identify any impediments. The goals is to facilitate communication and alignment between the development and maintenance teams.
  3. User Stories: Creating user stories to capture requirements and priorities from the perspective of the maintenance team can help ensure that the transition process is aligned with the needs of the end-users. Even more importantly, user stories that include updating and maintaining the software and likely rule or data updates will improve the maintainability of the software itself.
  4. Retrospectives: Conducting retrospectives at key milestones during the transition process allows teams to reflect on their experiences, identify successes and challenges, and brainstorm improvements for future transitions. These should also be communicated across teams and product groups.

 

Applying Agile Principles in a Software Transition

To illustrate the application of Agile principles in software transitions, let’s consider a hypothetical case study of a software development company transitioning control of a web application from the development team to the maintenance team:

  1. Flexibility: When unforeseen technical challenges arose during the transition process, the development and maintenance teams collaborated to adjust their plans and implement creative solutions, ensuring a successful hand-over despite the challenges. This included adjusting target dates and budgets for both teams to provide the time and resources needed.
  2. Collaboration: Through regular stand-up meetings and collaborative planning sessions, the development and maintenance teams worked closely together to share knowledge, address issues, and ensure alignment throughout the transition process.
  3. Continuous Improvement: Following each milestone in the transition process, the teams conducted retrospectives to reflect on their experiences and identify opportunities for improvement. By implementing iterative changes based on these retrospectives, the teams continuously optimized their transition processes over time. These were shared with other teams, along with tools, templates, and tips that had proven useful during the transition.

 

Conclusion

In conclusion, Agile principles can be effectively adapted and applied to facilitate successful software transitions from development to maintenance. By embracing flexibility, collaboration, and continuous improvement, teams can navigate the complexities of transition processes with confidence and ensure a seamless hand-over that meets the needs of end-users. Through the application of specific Agile practices and a commitment to Agile values and principles, organizations can optimize their transition processes and set the stage for long-term success in software maintenance.

If your organization uses Agile methodologies with development and maintenance handled by different teams, how are transitions handled?

Getting the Call to Action – Taking Over a Project

We usually don’t identify projects that we want to take over and make a request. Instead, we are identified as a candidate to assist or take over an ongoing project. How should we proceed?

 

Our goal is to quickly assess the current situation, focusing on the executive or management level, to help us decide if this is an opportunity that we should take or if we should steer clear. Even if we cannot decline the opportunity, the information gathered here will help us plan our first steps and should help us determine the extent of executive commitment to the project and the way to improve it.

 

The most critical question to ask is, “Why are we changing the PM now?” The PM may have been moved to a more important assignment, transferred to a different position as part of their career growth, or may just be on extended leave. If one of these is the reason given, there may still be some challenges in taking over the project, but there aren’t any warning signs yet.

 

There may be answers that raise warning flags, such as “We just fired the PM.” Or “The PM quit unexpectedly.” These usually indicate a project with issues. Another red flag warning is when the customer (internal or external) has demanded a change in the PM. While this may just be a style or personality conflict between the individuals, there are often deeper issues.

 

Carefully consider the responses you’ve received to this first question before proceeding. Is this shaping up as a situation where you will be the next PM being replaced, potentially harming your professional reputation and career? Do there appear to be political games being played? If so, do you want to join the game? If you have to take the assignment, what precautions are needed?

 

The next question for the Project Sponsor and Business Owner, is “What does success look like?” If they cannot succinctly describe this, how can the project be successful? Even under Agile or Flow Methodologies, “do good stuff” is never enough guidance. All projects have objectives. While they may be modified through the course of the project (being “agile”), at any given point in time the current objective must be clear and understood by all the stakeholders. If you cannot establish a clear response to this question, this issue must be flagged.

 

A more difficult question to get a true answer to is, “What is the current status of the project?” The true status may not be known, and different stakeholders are likely to hold different views. At this stage, we want to determine what views are held by the key stakeholders. If negative views are expressed, this is an ideal time to lay the foundation for future requests for help or support.

 

If there seems to be a consensus that the project is challenged or adrift, an immediate follow-up question needs to be asked: “Should this project be terminated?” Get this option on the table to save a lot of time and effort later. We are not recommending that the project be terminated, though we may do so later after we’ve done a thorough review. We are reminding the executive team that this is an option they should be considering if they haven’t already done so.

 

If the decision is made to continue the next question is, “If it is not on track, what caused it to go off track?” We will get into the actual reasons as part of our project review later on. At this point, we want to discover the executive view. Do not assume that this initial view is 100% true, there are probably some facts that support it.

The remaining questions are focused on executive commitment to the project and our accepting the opportunity to join as the PM. They will lay the foundation for the next steps that you will take as you assume leadership of the project team.

 

We need to learn, “Why was I selected for this project?” The goal is to learn more about the project and why they are coming to you to take over. Is it just because you are available? Do you have specific skills and experience that they think are needed, or something else?

 

Advertisement
[widget id=”custom_html-68″]

 

Next, ask “What do you need from me to help this project succeed?” Essentially a follow-up to the previous question, we are identifying the knowledge, skills, time, and commitment that they expect us to bring to the project. Is the intent for us to carry the project through to completion? If the answer is no, follow up with, “What is the desired project status to trigger my transition out?” These answers will impact your plans for assuming responsibility for the project and how you will be viewed by both management and the delivery team.

 

The next two questions can indicate the likelihood of success. “What authority will I have over the project team? Over external teams or resources that we need to succeed?” A common problem with modern organizations is dispersed authority. Being responsible for a successful outcome without having commensurate authority over the resources and teams is not only difficult, it is a recipe for frustration and disappointment. Uncover any potential issues of this kind now, and be prepared to discuss why the organizational arrangements need to be changed.

 

Ask your manager, the Project Sponsor, and the Business Owner, “What will you do to help this project succeed?” If they appear indifferent or show a lack of commitment to project success, this is a clear sign that the project is unlikely to succeed. Be very careful about boarding the Titanic while the captain is eyeing the lifeboat.

 

Finally ask “Do I have the option to turn down this assignment?” The answer may be yes, in which case you need to decide based on your career goals, your current personal situation, and everything you’ve learned about the project to this point. If you decide to accept the opportunity, do so with the firm intention to do your best and to be fully committed to a successful outcome for the organization, the project, and the project team.

 

If the answer is that you have to take the assignment, be professional about it. This may be a good opportunity to request specific things you need to be successful—key personnel; increased authority; ability to request scope, schedule, and budget changes later; etc. Explain that you are going to do a thorough project review and discuss the results with the key stakeholders. That discussion may include recommendations for them to consider, including additional support. Set the groundwork for your review and that follow-up meeting, indicating that you cannot promise a successful project outcome before then.

 

For a more detailed discussion of how to handle a request to take over a project, see my book:  There’s A New Sheriff In Town: The Project Manager’s Proven Guide To Successfully Taking Over Ongoing Projects And Getting The Work Done , Fenelon, Martin J., eBook – Amazon.com

 

11 Questions to Ask Before Taking Over a Project

1.     Why are we changing the PM now?

2.     What does success look like?

3.     What is the current status of the project?

4.     If it is not on track, what caused it to go off track?

5.     Why was I selected for this project?

6.     What do you need from me to help this project succeed?

7.     Do you intend for me to stay as PM through the end of the project? If not, what is the desired project status to trigger my transition out?

8.     What authority will I have over the project team?

9.     What authority will I have over external teams or resources that we need to succeed?

10.  What will you do to help this project succeed?

11.  Do I have the option to turn down this assignment?

 

Potential Challenges With Ongoing Projects

When joining a project that has already started or when tasked to review an existing project, a Project Manager is faced with a number of challenges. These primarily relate to not having been with the project team from the beginning and, therefore, not having been part of the planning process. As noted in a prior article, scope, schedule, and budget are probably already set. Many other decisions have also been made, some explicit, some implicit. This leads to the first challenge that the new PM has—what is the true status of the project? We’ll describe how to determine the true status of the project in more detail in a future article, along with providing some useful tools. Before going there, we should look at potential challenges that arise because a change in PM is contemplated or occurring. These challenges or issues will be added to those that already exist in the project and will also need to be addressed as part of the takeover and recovery plan.

 

There are many reasons for another PM taking over a project, and the project itself may not be in trouble; it may truly be in “Green” status. While that is great and makes things easier for the incoming PM, there are still challenges tied to the change in management that must be dealt with. Let’s review a few of these.

 

First, the previous PM may no longer be available. They may have left the organization, be out on extended personal leave, been moved to a different project, and not available for a hand-off, etc. This means the incoming PM is unlikely to have access to all the information that the previous PM had, especially around the reasons why certain decisions were made. For example, why was the delivery broken into three increments? Why are there four Scrum Teams instead of three? While interviewing the Business Owner (BO), Sponsor, Customer, and delivery team should provide some insights, if we can’t talk to the previous PM directly, we are unlikely to know why they made the decisions that they did.

 

Second, at the opposite end of the spectrum, the former PM may still be around, perhaps due to subject matter or technical expertise. Since they are still part of the delivery team, there are likely to be team and political issues with them no longer being in charge. The incoming PM needs to understand the reasons for the change and the decision to keep the former PM on the team. Specific actions will be needed to reduce any team or political fallout from the change and to ensure that the team continues to move forward as a team.

 

Advertisement
[widget id=”custom_html-68″]

 

Another challenge can arise if the Sponsor, Business Owner, or Customer change at the same time as the PM. Or if one is assessing a project due to a Business Owner change and a project review is requested. There have been cases where a successful Business Owner and PM that work well together are moved to higher priority programs or projects, especially if the current project is going well. This adds to the existing incoming PM challenge of building a relationship with the new Business Owner and rebuilding the team dynamic. Many Business Owners joining a project want to review prior decisions, change requirements and agreements, and potentially alter the goals of the project, all to mold the project to meet their goals and add their personal stamp onto the project. While this is a natural human reaction, it can be deadly in a project. The incoming PM needs to hold the line and minimize the disruption to the project, often without a full understanding of the rationale behind decisions already made. This is difficult to do, even while promising to look further into issues raised by the Business Owner. Diplomacy and firmness are both needed to avoid unnecessarily impacting the project.

 

Of course, there can be non-political challenges as well. When Project Managers discuss situations that they have found when assuming leadership of a project, it is striking how different they are from starting a new project. One of the key differences is that the ongoing project may already show evidence of problems, or have challenges. We’ve listed some common project challenges and possible causes in the table below. The challenges identified when a new PM is being asked to take over a project will influence the initial steps in assuming command, and should be discussed with management as part of accepting the new assignment. We’ll cover how to handle this in upcoming articles.

 

 

As you can see in the table, many challenges (symptoms) can result from similar causes and be related to multiple issues. It is important to avoid jumping to conclusions or developing action plans before getting to the real causes of the challenges. Future articles will describe the how to get to the root causes and ways to address them. In the meantime, how would you assess the true status of a project that you are joining?

 

For more information on how to handle this situation, and a guide for taking over an in-flight project, please check out my book on the topic. There’s a New Sheriff in Town: The Project Manager’s Proven Guide to Taking Over Ongoing Projects and Getting the Work Done. https://www.amazon.com/Theres-New-Sheriff-Town-Successfully/dp/B0BMJ4J7GL

We Don’t Always Start Fresh

Project Management texts usually assume we’re starting at the beginning of a project, with control over scope, schedule, and resources. Frequently, project scope, resources, and schedule are already determined through strategic planning, Project Portfolio Management (PPM), or the project charter process. In other cases, we take on projects that are in progress. This can occur as a normal part of the project lifecycle as a hand-off from a project initiation team to a project delivery team or due to other circumstances. The existing Project Manager (PM) may be moving to a different, higher priority project, assuming other responsibilities within the organization, leaving the organization for other career opportunities, or leaving the project due to the problems that have arisen. In all these cases, the new PM is required to assess the current status of the project, update or create a plan leading to a successful conclusion of the project, and execute that plan through project completion.

 

There are specific things that a PM can do to improve their chances of successfully completing the ongoing project, regardless of its current state or delivery phase. While these will be covered in future articles, and in my book, There’s a New Sheriff in Town: The Project Manager’s Proven Guide to Successfully Taking Over Ongoing Projects and Getting the Work Done, in this article we will examine how likely it is for a PM to step into an ongoing project.

 

Assuming management of an ongoing project is a lot more common than many people think. All the PMs that I’ve met over the years, through work, at conferences, and online, have taken over projects that were already started. Industry results and surveys also show that the overwhelming majority of PMs have had to assume projects or programs that were already in flight. Close to 200 project managers responded in 2022 to an online global survey on their experience with joining projects that had already been started.

 

PMs are much more likely to take over existing projects than to start with a “clean slate.”

 

Roughly 93% of the PMs responding have had to take over a project that was already started at least once in their careers. There are significant differences and additional challenges when taking over projects that have already started. Despite these circumstances being very common, they are not routine and should not be treated as such. We need to recognize the challenges of joining a project that has already started, along with the typical challenges of managing projects.

 

How frequently does this happen?

 

Two-thirds (67%) of all the projects managed by these PMs had a different PM when they finished.

 

Far from being a rare occurrence, we should assume that most projects will have a change in leadership before they finish. How many PMs plan to hand over leadership to another PM? All too often, we assume that we will finish what we start, so if a change in leadership does occur, we are not prepared for it. Whether we are handing off the project to another PM, or if we are the incoming PM, the hand-off will be more challenging and less successful if we are not prepared for it.

 

Advertisement
[widget id=”custom_html-68″]

 

Why is assuming management of an ongoing project different than starting a new project? Table 1-1 provides a brief listing of project characteristics, components, and key management decisions that are still being formulated when a project is initiated but are usually set once a project has started. We’ll discuss some of these issues, and how to handle them as an incoming PM, in future articles.

 

Table 1-1: New Projects Versus Ongoing Projects

COMPONENT NEW PROJECT ONGOING PROJECT
Objectives Loosely Defined Established
Scope/Requirements Being Determined Preliminary or Approved
Quality Being Negotiated Defined
Schedule Being Negotiated Set
Budget Rough Order of Magnitude (ROM) Set
Delivery Method Candidates identified Chosen
Technology May be defined, flexibility will vary Selected
Delivery Team Being Selected Created and working
Delivery Location May be open Set
Delivery Tools Being determined based on technology and delivery methodology selected In Use
Project Plans Being Drafted Published and Approved

 

The results of the survey, discussions with PMs across the globe, and personal experience have all shown that we don’t always start on a project with a clean slate where we can work with the sponsor and business owner to establish the triple constraints. In fact, it is almost guaranteed that during our PM careers we will have to take over an ongoing project. The bad news is that this can be very different from initiating a project, with additional challenges that make it hard to succeed. The good news is that we are not alone in facing these challenges, and that there are proven techniques that greatly increase the likelihood of success. In addition to covering these in my book, we will address many of them in future articles.