I’ve been working on a few agile transformation projects recently as well as writing some whitepapers on agile.  What I’ve found through my own experience as well as reading about and hearing about others is that there seem to be some common issues that companies, especially enterprises, face when transitioning to agile.

These issues may be small or large depending on the company and group going agile, but these all seem to show up and need to be dealt with in order for agile to be successful. So, with that, I would like to give you our list of common issues that our customers face when going agile. For this first post, I’m going to focus on the tactical issues teams face. In the next installment, I’ll talk more about organizational and mindset issues.

• Working with waterfall teams:
  • Especially when first moving to agile and picking pilot projects, most, if not all, of the interfacing teams will still follow a waterfall or iterative process.
  • In order to overcome this, you will need to develop a strategy for dealing with dependencies on teams that are not using the same processes.
  • This can mean making one of the POs an “interlock PO” for reaching out to those teams for requirements in advance of delivery (up to a year and a half in advance depending on roadmaps!). Or this could be using an Agile Requirements Document to get on the same page with the interfacing team before entering the requirements into the backlog.
• POs not empowered:
  • We see this often when starting agile, especially when POs are new to the role and are uncertain of themselves. If the PO continually has to go back to the business for verification and cannot make prioritization decisions herself, development can slow down and the benefits of agile won’t be realized.
  • In order to overcome this, companies have to be willing to dive head first into agile for a while. This means allowing the agile teams to be self-directed and empowering the PO to make prioritization decisions- basically it means letting go of some of the control and trusting your teams.
• Limited PO availability:
  • Ideally in agile development, the entire agile team is co-located. Then the development team can ask the PO questions in real time and the PO can answer them.
  • However, given the global nature of today’s projects, this is not always feasible. If the PO is not co-located with the development team, there should be someone else that can stand as proxy for the PO, perhaps a BA.
• POs unwilling to let BAs help:
  • Sometimes when first starting, companies don’t know what to do with their BAs. If the PO is supposed to “own” the backlog, then why do we need BAs?
  • The short answer is, we still need BAs in agile, because that analysis work still has to be done and POs are often not experts in that arena, as they are more focused on customer needs. For the long answer, see the BA in agile whitepaper.

Do any of your companies face these issues? What others?

Navigate here to read my follow up, Common Issues in Moving to Agile – Part 2.