Are you considering going Agile? It’s a brave move since even positive change may entail risk. This is definitely true for the transition to Agile project management. If you want your organization to reap the rewards sooner and with fewer “growing pains,” avoid these five common mistakes.
Waterfall masquerading as Agile is a common mistake many organizations make. Adding a veneer of Agile by incorporating “user stories” or “task boards” does not make the project Agile. True Agile includes moving aggressively towards project goals in an incremental fashion to continuously deliver value. True Agile includes avoiding activities that do not add value to the product. True Agile is being responsive and adjusting as you go instead of rigidly adhering to a plan. Don’t get caught up in making your organization look and sound more Agile through the use of CSM’s and buzz words. Focus on the purpose of the methodology so it will actually pay off.
Project management methodology has a variety of Agile styles; Scrum, Lean Development, Evolutionary Project Management, Feature Driven Development, and Unified Process are just a few. Pick one style to start. Even a relatively smooth transition to Agile can feel pretty chaotic. It makes things much, much worse when different teams or different departments are each doing Agile in their own way. There’s nothing wrong with adjusting your approach as you figure out what works for your particular organization, but consistency is needed. Make a plan before you take your first Agile step so everyone is on the same page.
With all the information on “How to Do Agile Right” that’s available online, it’s tempting to think it’s easy to implement. You may have even heard that the best way to transition to Agile is to simply start doing it. It is important to learn from experience; however, it’s not necessarily a good idea to learn just from your OWN experience. You can expect setbacks along your road to Agile, so it’s a good idea to have someone on hand with a map. The larger, more complex, and more rigid your organizational structure, the more likely it is that you will need professional advice on how to proceed. Bringing in a subject matter expert can be particularly helpful for securing buy-in. It may be easier for an expert to articulate the value of Agile to your stakeholders, since they do this all the time.
It’s tempting to wait and see if competitors successfully implement Agile before sticking a toe in the water yourself. This approach simply means you’ll be playing catch up while they reap the rewards of being “better, faster, and more affordable”. Being late to the game in transitioning to Agile can place additional strain on everyone involved, because you’re expected to prove that you can do it as well as the competition even though they’ve had a head start.
Without stakeholder education of Agile methodology, projects are at a high risk of failure. It is imperative that organizations new to using Agile methodology “sell” their stakeholders on agile concepts and benefits. This education is rooted in the critical need of stakeholder business involvement within day-to-day aspects of project development (e.g. timely determination of requirements). An initial investment in time is required in order to have project stakeholders understand what Agile is and is not. This education period will enable stakeholders to fully grasp the impact and differences that they will encounter as they complete the transition from their existing methodology to Agile methodology. For instance, if transitioning from traditional “waterfall” methodology, less formality in documentation artifacts should be expected.
Transitioning to Agile methodology is a challenge that shouldn’t be underestimated. It’s well worth the effort once you get it to work for you!