I’ve spent the past several months on an Agile project at a company that is going through the process of switching from an entrenched waterfall software development process to Agile. And while I’m still not going to claim to be an Agile guru, I’ve learned a few things from watching the process unfold. Here are five of the most important ones:

1)      Use Agile-friendly tools. Many legacy tools are optimized for a waterfall process. When you have to use them for an Agile project, it feels like you’re trying to cram a square peg in a round hole. On our project, we created a new document that we call an Agile Requirements Document for working with stakeholders to document their epics and user stories in an easy-to-consume format. And we do have a tool that we are using to manage the backlog, but it isn’t very Agile (or user) friendly. I see some Agile teams going to shareware or online tools for their projects because the corporate applications available to them are just not meeting their needs.

2)      Jump in. Really, unless your organization does a lot of stand-alone projects, the collaboration between your Agile project teams and your non-Agile project teams is going to be a huge nightmare. When an Agile project team has dependencies on another group that only does waterfall and has a two year product roadmap that cannot be altered, you’re not giving your Agile team much chance of success.

3)      Plan ahead. This may sound counter-intuitive, but going Agile doesn’t mean abandoning planning. In the Agile world, solid Enterprise Architecture is essential to the success of projects. Just as our Constitution creates a framework which enables our freedom to thrive, so does EA create a cohesive technical framework which enables Agile team success. If your organization doesn’t have an articulated current and future state, then you don’t have really have Agile; you have chaos.

4)      Self-directed means self-directed. I think this might be the hardest part of Agile for most organizations. A self-directed team determines their own internal processes and hierarchy. Given a goal, they decide how best to reach that goal. It takes time for a self-directed team to hit their stride and become really effective. It seems to be almost irresistible for organizations to meddle with and over-manage Agile teams. Going Agile means a leap of faith that many businesses are really uncomfortable with; it means trusting and empowering employees. Agile does not thrive in an authoritarian environment.

5)      Expect attrition. If you are making the switch from traditional to Agile project management, expect there to be some people who won’t want to or be able to complete that journey. You can provide training, good tools, and support, but some folks are not going to get groovy with Agile. In my experience, the switch to Agile takes a toll on middle management. Some people will leave, and some who stay will undermine the new paradigm. It’s a good idea to take that into consideration as you look towards beginning or expanding Agile in your organization.