Agile Practices in Large System Integration Projects

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:

Tailoring Agile Practices for Enterprise System Integration Projects – Part 1

Tailoring Agile Practices for Enterprise System Integration Projects – Part 2

Tailoring Agile Practices for Enterprise System Integration Projects – Part 3

Agile Practices for System Integration Projects – ERP Case Study

To your project success!

9 Responses to Agile Practices in Large System Integration Projects
  1. Tapio
    May 17, 2010 | 10:35 am

    I also work in R&D for a fairly large enterprise system.

    In my recent work I’ve noticed that multiple product owners end up in political power battles and are eventually unable to prioritize and otherwise collaborate on a shared product backlog. This is because typically different product owners have different end users in mind. In this scenario, the pressure is put on Scrum Master and even the team – and that is not nice.

    Consequently, I strongly support some sort of “reasonable dictatorship” in large projects too. Recently I’ve worked in an environment, where one product owner has several “aides” that give their recommendations for the product owner. This arrangement seems to work nicely.

    I, for one, look forward in reading your posts in this topic.

    • samad_aidane
      May 21, 2010 | 2:19 am

      Tapio,

      Thank you for taking the time to read this post and share your thoughts.

      I agree that enterprise system integration projects are inherently full of conflict and political power battles due to competing priorities and interests from different departments, divisions, and regions.

      I really see the inability to prioritize and collaborate on a shared product backlog not as an issue with having multiple product owners. The real problem I found is that multiple product owners either don’t have a framework to cooperate and align with each other or are allowed to avoid their responsibility.

      Prioritizing a shared product backlog requires making tough business decisions on behalf of the entire organization. This comes with inherent conflict and tension.

      In the absence of a framework for decision making, people assigned to this role will find creative and elaborate ways to avoid discomfort this conflict and tension.

      Some ideas I would like to explore in upcoming posts will cover decision making rules of engagement, ways to break impasse when product owners can’t agree on a decision, time-bound decision-making, and escalation process.

      I look forward to continuing the conversation and get your insights in future blog posts and comments on this topic.

  2. Jason Fair
    May 28, 2010 | 2:50 pm

    I have successfully implemented agile and Scrum with large scale ERP and agree with your statements that there need to be some
    adaptations to the agile approach for large ERP projects. I do believe however that a single product owner is needed during the sprints to manage the backlog, manage priorities, remove impediments and act as a liasion to other key stakeholders. We created a product council that had each of the process owners collectively reviewing the release backlog and prioritizing as a group on behalf of the business. However there was a specific product owner managing the details of the sprint backlog on a daily basis. Looking forward to further discussions.

    • samad_aidane
      June 5, 2010 | 4:19 pm

      Jason,

      I think the single vs. multiple product owners question is one of hotly debated topics when dealing with scaling agile.

      It is always great when the organization can agree on a single product owner.

      However, the more departments, divisions, or geographic areas the impact of the project touches, the more difficult it becomes for one single person to effectively perform the role of product owner. It becomes more difficult for one person to build the commitment and ownership needed for the final solution to succeed across the enterprise.

      I liked the fact that even with a single product owner you use a product council. When done properly, the product council can be a great tool for promoting the needed commitment and ownership.

      Another approach that worked for me is to have a product ownership team (or product council) but have it be made up of members of the core project team.

      The key is to establish a framework for timely decision making and escalation by keeping all decisions within the core project team. In addition, a steering committee should be established to make final decisions but only when there is an impasse at the product ownership team. Each organization is different so some trials and errors are to be expected.

      With this setup, the project may get slowed down a little due to the added overhead. But, when there is conflict in interest and priorities, people that have real (not proxy) representation in project decision making will have more ownership of the final outcome of the project. In such environment, even when people don’t get their way, they are most likely to accept and own decisions if they feel they have a direct a role in how they have been made.

      Your thought leadership in this area, based on real and practical experience in the trenches, is a valuable asset to all project managers taking on the challenging of bringing agile to their enterprise. I look forward to your future insights.

      Thank you.

  3. […] my previous post, Agile Practices in Large System Integration Projects, I argued that some Agile practices are not easy to implement in enterprise system integration […]

  4. […] my previous posts, Agile Practices in Large System Integration Projects and Tailoring Agile Practices for Enterprise System Integration Projects – Part 1, I argued that […]

  5. […] I had the pleasure to talk to Jason Fair about his work in bringing Agile to large complex integration projects. This is topic that I am very interested in and have been writing about. You can check out the series of blog posts on Agile Practices in Large System Integration Projects […]

  6. […] Agile Practices in Large System Integration Projects […]

  7. […] my previous post Agile Practices in Large System Integration Projects and in Part 1 & Part 2 of “Tailoring Agile Practices for Enterprise System Integration […]

Agile Practices in Large System Integration Projects

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:

Tailoring Agile Practices for Enterprise System Integration Projects – Part 1

Tailoring Agile Practices for Enterprise System Integration Projects – Part 2

Tailoring Agile Practices for Enterprise System Integration Projects – Part 3

Agile Practices for System Integration Projects – ERP Case Study

To your project success!

9 Responses to Agile Practices in Large System Integration Projects
  1. Tapio
    May 17, 2010 | 10:35 am

    I also work in R&D for a fairly large enterprise system.

    In my recent work I’ve noticed that multiple product owners end up in political power battles and are eventually unable to prioritize and otherwise collaborate on a shared product backlog. This is because typically different product owners have different end users in mind. In this scenario, the pressure is put on Scrum Master and even the team – and that is not nice.

    Consequently, I strongly support some sort of “reasonable dictatorship” in large projects too. Recently I’ve worked in an environment, where one product owner has several “aides” that give their recommendations for the product owner. This arrangement seems to work nicely.

    I, for one, look forward in reading your posts in this topic.

    • samad_aidane
      May 21, 2010 | 2:19 am

      Tapio,

      Thank you for taking the time to read this post and share your thoughts.

      I agree that enterprise system integration projects are inherently full of conflict and political power battles due to competing priorities and interests from different departments, divisions, and regions.

      I really see the inability to prioritize and collaborate on a shared product backlog not as an issue with having multiple product owners. The real problem I found is that multiple product owners either don’t have a framework to cooperate and align with each other or are allowed to avoid their responsibility.

      Prioritizing a shared product backlog requires making tough business decisions on behalf of the entire organization. This comes with inherent conflict and tension.

      In the absence of a framework for decision making, people assigned to this role will find creative and elaborate ways to avoid discomfort this conflict and tension.

      Some ideas I would like to explore in upcoming posts will cover decision making rules of engagement, ways to break impasse when product owners can’t agree on a decision, time-bound decision-making, and escalation process.

      I look forward to continuing the conversation and get your insights in future blog posts and comments on this topic.

  2. Jason Fair
    May 28, 2010 | 2:50 pm

    I have successfully implemented agile and Scrum with large scale ERP and agree with your statements that there need to be some
    adaptations to the agile approach for large ERP projects. I do believe however that a single product owner is needed during the sprints to manage the backlog, manage priorities, remove impediments and act as a liasion to other key stakeholders. We created a product council that had each of the process owners collectively reviewing the release backlog and prioritizing as a group on behalf of the business. However there was a specific product owner managing the details of the sprint backlog on a daily basis. Looking forward to further discussions.

    • samad_aidane
      June 5, 2010 | 4:19 pm

      Jason,

      I think the single vs. multiple product owners question is one of hotly debated topics when dealing with scaling agile.

      It is always great when the organization can agree on a single product owner.

      However, the more departments, divisions, or geographic areas the impact of the project touches, the more difficult it becomes for one single person to effectively perform the role of product owner. It becomes more difficult for one person to build the commitment and ownership needed for the final solution to succeed across the enterprise.

      I liked the fact that even with a single product owner you use a product council. When done properly, the product council can be a great tool for promoting the needed commitment and ownership.

      Another approach that worked for me is to have a product ownership team (or product council) but have it be made up of members of the core project team.

      The key is to establish a framework for timely decision making and escalation by keeping all decisions within the core project team. In addition, a steering committee should be established to make final decisions but only when there is an impasse at the product ownership team. Each organization is different so some trials and errors are to be expected.

      With this setup, the project may get slowed down a little due to the added overhead. But, when there is conflict in interest and priorities, people that have real (not proxy) representation in project decision making will have more ownership of the final outcome of the project. In such environment, even when people don’t get their way, they are most likely to accept and own decisions if they feel they have a direct a role in how they have been made.

      Your thought leadership in this area, based on real and practical experience in the trenches, is a valuable asset to all project managers taking on the challenging of bringing agile to their enterprise. I look forward to your future insights.

      Thank you.

  3. […] my previous post, Agile Practices in Large System Integration Projects, I argued that some Agile practices are not easy to implement in enterprise system integration […]

  4. […] my previous posts, Agile Practices in Large System Integration Projects and Tailoring Agile Practices for Enterprise System Integration Projects – Part 1, I argued that […]

  5. […] I had the pleasure to talk to Jason Fair about his work in bringing Agile to large complex integration projects. This is topic that I am very interested in and have been writing about. You can check out the series of blog posts on Agile Practices in Large System Integration Projects […]

  6. […] Agile Practices in Large System Integration Projects […]

  7. […] my previous post Agile Practices in Large System Integration Projects and in Part 1 & Part 2 of “Tailoring Agile Practices for Enterprise System Integration […]

Agile Practices in Large System Integration Projects

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:

Tailoring Agile Practices for Enterprise System Integration Projects – Part 1

Tailoring Agile Practices for Enterprise System Integration Projects – Part 2

Tailoring Agile Practices for Enterprise System Integration Projects – Part 3

Agile Practices for System Integration Projects – ERP Case Study

To your project success!

9 Responses to Agile Practices in Large System Integration Projects
  1. Tapio
    May 17, 2010 | 10:35 am

    I also work in R&D for a fairly large enterprise system.

    In my recent work I’ve noticed that multiple product owners end up in political power battles and are eventually unable to prioritize and otherwise collaborate on a shared product backlog. This is because typically different product owners have different end users in mind. In this scenario, the pressure is put on Scrum Master and even the team – and that is not nice.

    Consequently, I strongly support some sort of “reasonable dictatorship” in large projects too. Recently I’ve worked in an environment, where one product owner has several “aides” that give their recommendations for the product owner. This arrangement seems to work nicely.

    I, for one, look forward in reading your posts in this topic.

    • samad_aidane
      May 21, 2010 | 2:19 am

      Tapio,

      Thank you for taking the time to read this post and share your thoughts.

      I agree that enterprise system integration projects are inherently full of conflict and political power battles due to competing priorities and interests from different departments, divisions, and regions.

      I really see the inability to prioritize and collaborate on a shared product backlog not as an issue with having multiple product owners. The real problem I found is that multiple product owners either don’t have a framework to cooperate and align with each other or are allowed to avoid their responsibility.

      Prioritizing a shared product backlog requires making tough business decisions on behalf of the entire organization. This comes with inherent conflict and tension.

      In the absence of a framework for decision making, people assigned to this role will find creative and elaborate ways to avoid discomfort this conflict and tension.

      Some ideas I would like to explore in upcoming posts will cover decision making rules of engagement, ways to break impasse when product owners can’t agree on a decision, time-bound decision-making, and escalation process.

      I look forward to continuing the conversation and get your insights in future blog posts and comments on this topic.

  2. Jason Fair
    May 28, 2010 | 2:50 pm

    I have successfully implemented agile and Scrum with large scale ERP and agree with your statements that there need to be some
    adaptations to the agile approach for large ERP projects. I do believe however that a single product owner is needed during the sprints to manage the backlog, manage priorities, remove impediments and act as a liasion to other key stakeholders. We created a product council that had each of the process owners collectively reviewing the release backlog and prioritizing as a group on behalf of the business. However there was a specific product owner managing the details of the sprint backlog on a daily basis. Looking forward to further discussions.

    • samad_aidane
      June 5, 2010 | 4:19 pm

      Jason,

      I think the single vs. multiple product owners question is one of hotly debated topics when dealing with scaling agile.

      It is always great when the organization can agree on a single product owner.

      However, the more departments, divisions, or geographic areas the impact of the project touches, the more difficult it becomes for one single person to effectively perform the role of product owner. It becomes more difficult for one person to build the commitment and ownership needed for the final solution to succeed across the enterprise.

      I liked the fact that even with a single product owner you use a product council. When done properly, the product council can be a great tool for promoting the needed commitment and ownership.

      Another approach that worked for me is to have a product ownership team (or product council) but have it be made up of members of the core project team.

      The key is to establish a framework for timely decision making and escalation by keeping all decisions within the core project team. In addition, a steering committee should be established to make final decisions but only when there is an impasse at the product ownership team. Each organization is different so some trials and errors are to be expected.

      With this setup, the project may get slowed down a little due to the added overhead. But, when there is conflict in interest and priorities, people that have real (not proxy) representation in project decision making will have more ownership of the final outcome of the project. In such environment, even when people don’t get their way, they are most likely to accept and own decisions if they feel they have a direct a role in how they have been made.

      Your thought leadership in this area, based on real and practical experience in the trenches, is a valuable asset to all project managers taking on the challenging of bringing agile to their enterprise. I look forward to your future insights.

      Thank you.

  3. […] my previous post, Agile Practices in Large System Integration Projects, I argued that some Agile practices are not easy to implement in enterprise system integration […]

  4. […] my previous posts, Agile Practices in Large System Integration Projects and Tailoring Agile Practices for Enterprise System Integration Projects – Part 1, I argued that […]

  5. […] I had the pleasure to talk to Jason Fair about his work in bringing Agile to large complex integration projects. This is topic that I am very interested in and have been writing about. You can check out the series of blog posts on Agile Practices in Large System Integration Projects […]

  6. […] Agile Practices in Large System Integration Projects […]

  7. […] my previous post Agile Practices in Large System Integration Projects and in Part 1 & Part 2 of “Tailoring Agile Practices for Enterprise System Integration […]