Agile has become a standard methodology across multiple disciplines but that doesn’t mean getting started is easy. Development teams already have a certain stride they’ve developed over time. Sometimes their current methods are well documented and sometimes just understood as part of the culture. No matter how their practices have evolved they are probably ingrained and accepted as “the way we do it.” Even if everyone involved has agreed to adopt an agile methodology, issues will crop up. Here are the most common ones to look out for and work through.
Agile has been proven to be an effective methodology for managing software development. At its heart, Agile is a way to manage projects. If you’re accustomed to managing projects using traditional PM solutions, then you may have a running start. That is, if you’re willing to give up on a lot of the procedural record keeping that PM systems require. Agile’s difference is that it focuses on delivery rather than paperwork. The priority is in delivering usable products quickly then iterating to the next version. However Agile won’t solve issues like lack of qualified developers, morale and retention problems, and unrealistic expectations around features and delivery times. Those kinds of organizational problems need to be addressed independently and in advance of committing to an Agile methodology.
Not everyone is enthusiastic about change. Some will resist it as long as possible and against all reasonable efforts to help them accept new ways of doing things. Resistance to changing the way things operate in a complex work environment may be the biggest hurdle you face in implementing an Agile methodology. Managers are likely to balk at the thought of abandoning the all-hands meetings in favor of daily startups or Kanban boards. That seeming loss of direct control can be a significant hurdle, but it’s important that practices get replaced rather than simply added to, thereby increasing or even duplicating efforts in the pursuit of Agile.
The main focus of Agile is delivery. Agile in itself allows for many different methodologies and there is plenty to learn on the way to getting a team up and running an Agile environment. Watch out for the tendency to over focus on the particulars that go into practicing Agile. Individuals need to be trained in Scrum, Kanban, Lean, or any of the other practices but still understand that while these so-called artifacts and ceremonies are important to successfully implementing Agile, they are only components and tools, and not the purpose. Keep the focus on delivery over process.
Knowing when your Agile environment is successful is important, but measuring success in the wrong way can sidetrack actual success. Traditional metrics look at numbers of events, their frequency, and participation. But trying to measure Agile’s success by counting the number of stand-ups or retrospectives held if all ceremonies are being followed correctly, or even how many projects are falling under the Agile framework focuses on the wrong metrics. Because Agile is intended to focus on delivery, teams need to define what they are trying to deliver and measure success against issues they are trying to resolve like delayed deliveries and reduced customer complaints.
Development teams have different customers, but whether they are internal business units or external customers, transitioning to Agile will affect what they receive in ways they may not expect. If they are accustomed to getting project plans and Gantt charts they need to understand well in advance how these expectations will change. They also need to understand that the transition to Agile is likely to produce unexpected and unwanted results along the way and that the development teams are learning their way around the new Agile landscape on their mission to deliver a usable product. The possible problems may not be acceptable to some customers and teams will need to evaluate their plans and what projects should be included in their learning phase.
Moving development teams from traditional to Agile methodologies has proven to deliver tangible advantages. Knowing the problems before they happen can help smooth the journey, bring teams together, and fulfill the goal of delivering projects more successfully.