The reality of organizations is that they don’t come in a very neatly packaged configuration to which we can apply a single project management methodology.
I spoke a couple weeks ago at an Oracle users group conference about my experience applying Agile practices in a large Enterprise Resource Planning (ERP) upgrade project. From discussions with project managers who attended my presentation and with other conference attendees, I found there is a strong interest in case studies where project teams have customized Agile to scale in large packaged applications implementation and upgrade projects such as ERP systems.
A theme that kept coming up in all these discussion is the need to customize and tailor Agile practices to fit the special needs of these types of projects. On the other hand, I also heard a number of people advising against customization. The most cited argument against customizing or partially implementing Agile is that doing so prevents an organization from realizing Agile’s full benefits such as speed, efficiency, and cost savings.
In my experience, some agile practices are not easy to implement, as originally conceived, in packaged applications implementation projects. For example, the practice of assigning a single product owner is unfeasible in a complex ERP upgrade project. In such projects, there are typically multiple “product” owners who need to be represented in any major decision that impacts their domain of ownership. To continue to insist that the business nominate a single person in such projects ignores the reality that no one single person in today’s complex organizations can be the chief of all answers.
To customize this practice for an ERP project, there is nothing wrong with having multiple product owners in this case. This should not be an issue, as long as there is a process in place for them to prioritize the backlog and perform the other roles that are traditionally performed by a single product owner. It may not be an elegant solution but it is a practical one that makes it possible for Agile to scale.
In my experience, most practitioners I know want flexibility to pick and choose which Agile practices to introduce to their organizations and when. We need to be able to selectively adopt, adapt, and apply whatever Agile practices that help us reach the finish line and deliver projects successfully. Insisting that an Agile method (or any method for that matter) must be implemented exactly as it was originally conceived for all projects becomes an obstacle to its adoption in many organizations and projects.
Agile needs to continue to evolve beyond its initial framework and practices. We are seeing this now with teams moving from Scrum or XP to Scrumban or Kanban. I think this is a good thing.
I look forward to sharing in upcoming blog posts my experience customizing Agile practices to deliver an ERP upgrade project under aggressive deadline and budget. I will explore the benefits gained from the following practices:
- Use single prioritized backlog of work
- Plan with time-boxing
- Use Rolling Wave schedule
- Plan work in short iterations
- Apply daily 15 minute standup meeting
In the meantime, have you applied agile practices in a packaged application implementation or upgrade project? What worked for you and what didn’t? I would love to hear your thoughts in comments on this blog post.
Please read these other posts in this series:
To your project success!