Tailoring Agile Practices for Enterprise System Integration Projects – Part 2

In my previous posts, Agile Practices in Large System Integration Projects and Tailoring Agile Practices for Enterprise System Integration Projects – Part 1, I argued that we need ways to incorporate Agile in system integration projects without (a) changing the entire organization or (b) waiting for the organization to change. We also need to tailor the practices so project managers are able to introduce them within the context of these projects.

In this series of posts, I identify a set of key Agile practices that offer the greatest value and recommend ways to tailor them for large enterprise system integration projects such as Enterprise Resource Planning (ERP), Customer Relationship Management (CRM), supply chain management (SCM) and other large, configurable off-the-shelf (COTS) applications.

This post will explore the role of the product owner.

Product Owner in Agile

The product owner role originates from small teams practicing Scrum. A single person who represents the voice of the customer typically fills this role.

Product owners negotiate requirements with the larger organizational groups they represent. They prioritize them according to all the known dependencies and constraints of the project.

In Scrum, project teams organize requirements in what is known as the product backlog. The requirements are captured in different ways. One of the most widely used approaches is to employ user stories. The primary role of the product owner is to own the product backlog and prioritize it for the project team.

Additionally, the product owner provides information, answers questions, addresses dependencies, and resolves issues, as needed, for the development team.

The Challenges of Integration Projects

Applying the product owner role, as defined in Scrum, to system integration projects is challenging because:

  • most information available on this role is from small software development teams, and
  • it is rare to find a single person who can fill these monumental shoes, in the context of enterprise system integration projects.

Prioritizing the backlog in these projects involves making complex business and technical decisions that come with inherent conflicts and tensions. The product owner must decide which options to pursue and which ones to kill. These choices are seldom between right or wrong, or good or bad. Many people need to be consulted, and many dependencies need to be addressed. One bad decision can generate many implications and create a ripple effect throughout the entire organization.

The more departments, divisions, or geographic areas the project touches, the more challenging it becomes for one person to effectively build the commitment and ownership necessary for a project to succeed across the enterprise.

Single or Multiple Product Owners?

The single vs. multiple product owner choice is one of the hotly debated topics when considering scaling Agile for large and complex projects.

The most cited argument against multiple product owners is the excessive delays in making decisions, due to the inability of individuals to prioritize and collaborate on a shared product backlog.

In large system integration projects, agility is the result of making decisions in a timely fashion. It is also critical that those decisions are owned by the broader organization.

This is the reason I recommend a team-based product ownership model with a product owner team working together to make decisions with shared responsibility, accountability, and authority on behalf of the broader organization.

Product Owner Team

The focus of the product owner team is on ownership and prioritization of the backlog, taking into account other project dependencies and constrains. For this team-based product ownership model to work, I recommend the following:

  • The product owner team operates as part of the core team. It is made up of members of the larger functional and technical core team. The most important characteristic of successful product owner teams is that team individuals must also work within the project’s core team and perform actual functional and/or technical roles within the core team.
  • The product owner team is comprised of team leads representing all the competing interests, conflicts, and power struggles of the broader organization. It is critical that these competing aspects play out in the open, within the core team, so they can be addressed head-on.
  • Both business and technical teams are represented because (a) these projects are faced with complex technical issues, and (b) most decisions require consideration of both the business and technical implications of each decision.
  • Within the team, there is no rank or positional power when making decisions. Each member brings their own functional and technical expertise to the team, but ideas are selected based on their own merits.
  • A framework for timely decision-making and escalation is established at the start of the project. In the absence of such a framework, the individuals who are responsible for decision-making and escalation will find creative ways to avoid the discomfort that arises from the conflict and tension inherent in the process.
  • Clear rules of engagement regarding disagreements and escalations are in place to enable the team to cooperate, align with each other, and break impasses on decisions.
  • The product owner team makes all decisions at the project level. Decisions are escalated to entities outside the project only in the case of an impasse. This event should be rare and will typically occur at the beginning of a project.
  • The steering committee serves as the next escalation level when the project owner team is unable to make a decision on their own. A project steering committee makes final decisions, but only when there is an impasse at the product owner team level. Each organization is different so some trial and error is to be expected.
  • The steering committee’s function is to gain executive engagement.  Its members are all the executives whose departments are affected by the project.
  • Conflict is part of making tough decisions. A good project schedule will allow time for decision-making. However, be alert so that you can spot those people who are avoiding the discomfort of making tough decisions.

Final Thoughts

Conflict in enterprise integration projects is real and should be anticipated by every healthy organization undertaking major changes. The choices are to either ignore conflict or to embrace it. I recommend giving conflict a home, in the form of a product owner team model, so you can deal with it effectively.

There is no doubt that this team-based model for the product owner role can slow down decision-making. Working through differences takes time and adds to the overhead.

Stakeholders who have real (not proxy) input in project decision-making, especially during conflicts, will have more ownership of the final solution. Even when they don’t get their way, they are more likely to accept and own a solution if they believe that they had a role in the decision-making process.

In future blog posts, I will continue this series by covering these Agile practices:

  • Single prioritized backlog of work
  • Planning with time-boxing
  • Rolling Wave scheduling
  • Planning work in short iterations
  • Daily 15-minute standup meetings
  • Retrospectives
  • Continuous Integration

As always, if you have any comments, questions, concerns, or rants, – or you just want to say hi – please feel free to leave a comment below. Cheers!

Please read my previous posts on this topic:

Agile Practices in Large System Integration Projects

Agile Practices in Large System Integration Projects – ERP Case Study

Tailoring Agile Practices for Enterprise System Integration Projects – Part 1

Tailoring Agile Practices for Enterprise System Integration Projects – Part 3

 

5 Responses to Tailoring Agile Practices for Enterprise System Integration Projects – Part 2
  1. […] Tailoring Agile Practices for Enterprise System Integration Projects – Part 2 Bookmark It Hide Sites Tags: Agile « Previous Post Next Post » 4 Responses to Tailoring Agile Practices for Enterprise System Integration Projects – Part 1 […]

  2. […] Tailoring Agile Practices for Enterprise System Integration Projects – Part 2 […]

  3. […] Tailoring Agile Practices for Enterprise System Integration Projects – Part 2 […]

  4. Rajeev
    June 14, 2012 | 10:59 am

    Hi,

    This is a great start to implementing Agile for large scale system integration projects. I am interested to read follow up articles. I am a Product Release Manager working for a ERP Software company and one of our goals is to transition to Agile implementing the best practices for testing upfront rather than a big-bang testing.

    Look forward to the follow up Parts on this topic.

    Thanks,
    Rajeev.

  5. […] my previous post Agile Practices in Large System Integration Projects and in Part 1 & Part 2 of “Tailoring Agile Practices for Enterprise System Integration Projects” series, I identify a […]

Leave a Reply

Wanting to leave an <em>phasis on your comment?

Trackback URL http://www.guerrillaprojectmanagement.com/tailoring-agile-practices-for-enterprise-system-integration-projects-part-2/trackback

Tailoring Agile Practices for Enterprise System Integration Projects – Part 2

In my previous posts, Agile Practices in Large System Integration Projects and Tailoring Agile Practices for Enterprise System Integration Projects – Part 1, I argued that we need ways to incorporate Agile in system integration projects without (a) changing the entire organization or (b) waiting for the organization to change. We also need to tailor the practices so project managers are able to introduce them within the context of these projects.

In this series of posts, I identify a set of key Agile practices that offer the greatest value and recommend ways to tailor them for large enterprise system integration projects such as Enterprise Resource Planning (ERP), Customer Relationship Management (CRM), supply chain management (SCM) and other large, configurable off-the-shelf (COTS) applications.

This post will explore the role of the product owner.

Product Owner in Agile

The product owner role originates from small teams practicing Scrum. A single person who represents the voice of the customer typically fills this role.

Product owners negotiate requirements with the larger organizational groups they represent. They prioritize them according to all the known dependencies and constraints of the project.

In Scrum, project teams organize requirements in what is known as the product backlog. The requirements are captured in different ways. One of the most widely used approaches is to employ user stories. The primary role of the product owner is to own the product backlog and prioritize it for the project team.

Additionally, the product owner provides information, answers questions, addresses dependencies, and resolves issues, as needed, for the development team.

The Challenges of Integration Projects

Applying the product owner role, as defined in Scrum, to system integration projects is challenging because:

  • most information available on this role is from small software development teams, and
  • it is rare to find a single person who can fill these monumental shoes, in the context of enterprise system integration projects.

Prioritizing the backlog in these projects involves making complex business and technical decisions that come with inherent conflicts and tensions. The product owner must decide which options to pursue and which ones to kill. These choices are seldom between right or wrong, or good or bad. Many people need to be consulted, and many dependencies need to be addressed. One bad decision can generate many implications and create a ripple effect throughout the entire organization.

The more departments, divisions, or geographic areas the project touches, the more challenging it becomes for one person to effectively build the commitment and ownership necessary for a project to succeed across the enterprise.

Single or Multiple Product Owners?

The single vs. multiple product owner choice is one of the hotly debated topics when considering scaling Agile for large and complex projects.

The most cited argument against multiple product owners is the excessive delays in making decisions, due to the inability of individuals to prioritize and collaborate on a shared product backlog.

In large system integration projects, agility is the result of making decisions in a timely fashion. It is also critical that those decisions are owned by the broader organization.

This is the reason I recommend a team-based product ownership model with a product owner team working together to make decisions with shared responsibility, accountability, and authority on behalf of the broader organization.

Product Owner Team

The focus of the product owner team is on ownership and prioritization of the backlog, taking into account other project dependencies and constrains. For this team-based product ownership model to work, I recommend the following:

  • The product owner team operates as part of the core team. It is made up of members of the larger functional and technical core team. The most important characteristic of successful product owner teams is that team individuals must also work within the project’s core team and perform actual functional and/or technical roles within the core team.
  • The product owner team is comprised of team leads representing all the competing interests, conflicts, and power struggles of the broader organization. It is critical that these competing aspects play out in the open, within the core team, so they can be addressed head-on.
  • Both business and technical teams are represented because (a) these projects are faced with complex technical issues, and (b) most decisions require consideration of both the business and technical implications of each decision.
  • Within the team, there is no rank or positional power when making decisions. Each member brings their own functional and technical expertise to the team, but ideas are selected based on their own merits.
  • A framework for timely decision-making and escalation is established at the start of the project. In the absence of such a framework, the individuals who are responsible for decision-making and escalation will find creative ways to avoid the discomfort that arises from the conflict and tension inherent in the process.
  • Clear rules of engagement regarding disagreements and escalations are in place to enable the team to cooperate, align with each other, and break impasses on decisions.
  • The product owner team makes all decisions at the project level. Decisions are escalated to entities outside the project only in the case of an impasse. This event should be rare and will typically occur at the beginning of a project.
  • The steering committee serves as the next escalation level when the project owner team is unable to make a decision on their own. A project steering committee makes final decisions, but only when there is an impasse at the product owner team level. Each organization is different so some trial and error is to be expected.
  • The steering committee’s function is to gain executive engagement.  Its members are all the executives whose departments are affected by the project.
  • Conflict is part of making tough decisions. A good project schedule will allow time for decision-making. However, be alert so that you can spot those people who are avoiding the discomfort of making tough decisions.

Final Thoughts

Conflict in enterprise integration projects is real and should be anticipated by every healthy organization undertaking major changes. The choices are to either ignore conflict or to embrace it. I recommend giving conflict a home, in the form of a product owner team model, so you can deal with it effectively.

There is no doubt that this team-based model for the product owner role can slow down decision-making. Working through differences takes time and adds to the overhead.

Stakeholders who have real (not proxy) input in project decision-making, especially during conflicts, will have more ownership of the final solution. Even when they don’t get their way, they are more likely to accept and own a solution if they believe that they had a role in the decision-making process.

In future blog posts, I will continue this series by covering these Agile practices:

  • Single prioritized backlog of work
  • Planning with time-boxing
  • Rolling Wave scheduling
  • Planning work in short iterations
  • Daily 15-minute standup meetings
  • Retrospectives
  • Continuous Integration

As always, if you have any comments, questions, concerns, or rants, – or you just want to say hi – please feel free to leave a comment below. Cheers!

Please read my previous posts on this topic:

Agile Practices in Large System Integration Projects

Agile Practices in Large System Integration Projects – ERP Case Study

Tailoring Agile Practices for Enterprise System Integration Projects – Part 1

Tailoring Agile Practices for Enterprise System Integration Projects – Part 3

 

5 Responses to Tailoring Agile Practices for Enterprise System Integration Projects – Part 2
  1. […] Tailoring Agile Practices for Enterprise System Integration Projects – Part 2 Bookmark It Hide Sites Tags: Agile « Previous Post Next Post » 4 Responses to Tailoring Agile Practices for Enterprise System Integration Projects – Part 1 […]

  2. […] Tailoring Agile Practices for Enterprise System Integration Projects – Part 2 […]

  3. […] Tailoring Agile Practices for Enterprise System Integration Projects – Part 2 […]

  4. Rajeev
    June 14, 2012 | 10:59 am

    Hi,

    This is a great start to implementing Agile for large scale system integration projects. I am interested to read follow up articles. I am a Product Release Manager working for a ERP Software company and one of our goals is to transition to Agile implementing the best practices for testing upfront rather than a big-bang testing.

    Look forward to the follow up Parts on this topic.

    Thanks,
    Rajeev.

  5. […] my previous post Agile Practices in Large System Integration Projects and in Part 1 & Part 2 of “Tailoring Agile Practices for Enterprise System Integration Projects” series, I identify a […]

Leave a Reply

Wanting to leave an <em>phasis on your comment?

Trackback URL http://www.guerrillaprojectmanagement.com/tailoring-agile-practices-for-enterprise-system-integration-projects-part-2/trackback

Tailoring Agile Practices for Enterprise System Integration Projects – Part 2

In my previous posts, Agile Practices in Large System Integration Projects and Tailoring Agile Practices for Enterprise System Integration Projects – Part 1, I argued that we need ways to incorporate Agile in system integration projects without (a) changing the entire organization or (b) waiting for the organization to change. We also need to tailor the practices so project managers are able to introduce them within the context of these projects.

In this series of posts, I identify a set of key Agile practices that offer the greatest value and recommend ways to tailor them for large enterprise system integration projects such as Enterprise Resource Planning (ERP), Customer Relationship Management (CRM), supply chain management (SCM) and other large, configurable off-the-shelf (COTS) applications.

This post will explore the role of the product owner.

Product Owner in Agile

The product owner role originates from small teams practicing Scrum. A single person who represents the voice of the customer typically fills this role.

Product owners negotiate requirements with the larger organizational groups they represent. They prioritize them according to all the known dependencies and constraints of the project.

In Scrum, project teams organize requirements in what is known as the product backlog. The requirements are captured in different ways. One of the most widely used approaches is to employ user stories. The primary role of the product owner is to own the product backlog and prioritize it for the project team.

Additionally, the product owner provides information, answers questions, addresses dependencies, and resolves issues, as needed, for the development team.

The Challenges of Integration Projects

Applying the product owner role, as defined in Scrum, to system integration projects is challenging because:

  • most information available on this role is from small software development teams, and
  • it is rare to find a single person who can fill these monumental shoes, in the context of enterprise system integration projects.

Prioritizing the backlog in these projects involves making complex business and technical decisions that come with inherent conflicts and tensions. The product owner must decide which options to pursue and which ones to kill. These choices are seldom between right or wrong, or good or bad. Many people need to be consulted, and many dependencies need to be addressed. One bad decision can generate many implications and create a ripple effect throughout the entire organization.

The more departments, divisions, or geographic areas the project touches, the more challenging it becomes for one person to effectively build the commitment and ownership necessary for a project to succeed across the enterprise.

Single or Multiple Product Owners?

The single vs. multiple product owner choice is one of the hotly debated topics when considering scaling Agile for large and complex projects.

The most cited argument against multiple product owners is the excessive delays in making decisions, due to the inability of individuals to prioritize and collaborate on a shared product backlog.

In large system integration projects, agility is the result of making decisions in a timely fashion. It is also critical that those decisions are owned by the broader organization.

This is the reason I recommend a team-based product ownership model with a product owner team working together to make decisions with shared responsibility, accountability, and authority on behalf of the broader organization.

Product Owner Team

The focus of the product owner team is on ownership and prioritization of the backlog, taking into account other project dependencies and constrains. For this team-based product ownership model to work, I recommend the following:

  • The product owner team operates as part of the core team. It is made up of members of the larger functional and technical core team. The most important characteristic of successful product owner teams is that team individuals must also work within the project’s core team and perform actual functional and/or technical roles within the core team.
  • The product owner team is comprised of team leads representing all the competing interests, conflicts, and power struggles of the broader organization. It is critical that these competing aspects play out in the open, within the core team, so they can be addressed head-on.
  • Both business and technical teams are represented because (a) these projects are faced with complex technical issues, and (b) most decisions require consideration of both the business and technical implications of each decision.
  • Within the team, there is no rank or positional power when making decisions. Each member brings their own functional and technical expertise to the team, but ideas are selected based on their own merits.
  • A framework for timely decision-making and escalation is established at the start of the project. In the absence of such a framework, the individuals who are responsible for decision-making and escalation will find creative ways to avoid the discomfort that arises from the conflict and tension inherent in the process.
  • Clear rules of engagement regarding disagreements and escalations are in place to enable the team to cooperate, align with each other, and break impasses on decisions.
  • The product owner team makes all decisions at the project level. Decisions are escalated to entities outside the project only in the case of an impasse. This event should be rare and will typically occur at the beginning of a project.
  • The steering committee serves as the next escalation level when the project owner team is unable to make a decision on their own. A project steering committee makes final decisions, but only when there is an impasse at the product owner team level. Each organization is different so some trial and error is to be expected.
  • The steering committee’s function is to gain executive engagement.  Its members are all the executives whose departments are affected by the project.
  • Conflict is part of making tough decisions. A good project schedule will allow time for decision-making. However, be alert so that you can spot those people who are avoiding the discomfort of making tough decisions.

Final Thoughts

Conflict in enterprise integration projects is real and should be anticipated by every healthy organization undertaking major changes. The choices are to either ignore conflict or to embrace it. I recommend giving conflict a home, in the form of a product owner team model, so you can deal with it effectively.

There is no doubt that this team-based model for the product owner role can slow down decision-making. Working through differences takes time and adds to the overhead.

Stakeholders who have real (not proxy) input in project decision-making, especially during conflicts, will have more ownership of the final solution. Even when they don’t get their way, they are more likely to accept and own a solution if they believe that they had a role in the decision-making process.

In future blog posts, I will continue this series by covering these Agile practices:

  • Single prioritized backlog of work
  • Planning with time-boxing
  • Rolling Wave scheduling
  • Planning work in short iterations
  • Daily 15-minute standup meetings
  • Retrospectives
  • Continuous Integration

As always, if you have any comments, questions, concerns, or rants, – or you just want to say hi – please feel free to leave a comment below. Cheers!

Please read my previous posts on this topic:

Agile Practices in Large System Integration Projects

Agile Practices in Large System Integration Projects – ERP Case Study

Tailoring Agile Practices for Enterprise System Integration Projects – Part 1

Tailoring Agile Practices for Enterprise System Integration Projects – Part 3

 

5 Responses to Tailoring Agile Practices for Enterprise System Integration Projects – Part 2
  1. […] Tailoring Agile Practices for Enterprise System Integration Projects – Part 2 Bookmark It Hide Sites Tags: Agile « Previous Post Next Post » 4 Responses to Tailoring Agile Practices for Enterprise System Integration Projects – Part 1 […]

  2. […] Tailoring Agile Practices for Enterprise System Integration Projects – Part 2 […]

  3. […] Tailoring Agile Practices for Enterprise System Integration Projects – Part 2 […]

  4. Rajeev
    June 14, 2012 | 10:59 am

    Hi,

    This is a great start to implementing Agile for large scale system integration projects. I am interested to read follow up articles. I am a Product Release Manager working for a ERP Software company and one of our goals is to transition to Agile implementing the best practices for testing upfront rather than a big-bang testing.

    Look forward to the follow up Parts on this topic.

    Thanks,
    Rajeev.

  5. […] my previous post Agile Practices in Large System Integration Projects and in Part 1 & Part 2 of “Tailoring Agile Practices for Enterprise System Integration Projects” series, I identify a […]

Leave a Reply

Wanting to leave an <em>phasis on your comment?

Trackback URL http://www.guerrillaprojectmanagement.com/tailoring-agile-practices-for-enterprise-system-integration-projects-part-2/trackback