From Project to Product: The Complete List of Agile Delivery Anti-Patterns

Hrishikesh Karekar 10/12/2023

Most major firms are increasingly embracing agile development approaches as their preferred method.

Large traditional enterprises embarking on building new products or upgrading existing ones choose agile development approaches. However, they often struggle to operate with the same mindset as many successful technology companies. The critical differentiator is the mindset that drives their practices. Project mindset and practices are deep-rooted in traditional enterprises. They struggle to shift from project to product mindset, which is the differentiator and the critical success factor with an agile approach.

Why Move from a Project to Product Mindset?

Design Project Management

The project mindset and execution practices introduce many anti-patterns that often negate the benefits the agile approach was supposed to bring. Contracts that rely on a traditional project mindset, especially those around fixed-cost agreements, aggravate them further. This article looks at 14 anti-patterns in 7 distinct areas and practices that can help us move towards a product mindset. This is definitely not an exhaustive list. Several of these ant-patterns are also agile anti-patterns in general. The project environment and mindset aggravate the challenges and make it much harder to avoid them. The goal is to provide a starting point, think objectively, and provide a perspective on moving from a project-centric approach to a product-centric approach.

An agile delivery approach is formidable. However, its potential is lost and severely underutilized by not moving to a product-oriented mindset. Making this shift can help you deliver products faster, better, and most importantly, products that customers love and are delighted to use.

1. Team Goals Anti-Patterns

AP1 – Deliver the project by satisfying the iron triangle constraints

In a project-focused approach, the team’s goal is to deliver the project to constraints similar to the iron triangle – create a product with a pre-defined scope within agreed timelines and costs. This approach is not much different than a waterfall approach though. Project charter would involve defining scope at a high level (e.g., Epics), often elaborated in initial sprints. So while we are moving a bit away from eliciting detail requirements upfront, the scope boundaries are still very rigid. Customer centricity is absent.

Aim for – Maximizing Value Delivery

In a product-oriented approach, the team aims to maximize value delivery to customers in line with a product roadmap. An initial product roadmap and MVP start the product development process. The roadmap evolves during the product lifecycle based on accelerated feedback cycles. The team aims to deliver early and frequently to maximize value for both stakeholders and users instead of following a predetermined and fixed plan.

AP2 – Stakeholder Centric missing the user’s perspective

The project team’s focus is primarily on the business stakeholders to deliver to their needs and specifications. They do not empathize enough with the end user’s perspective or actively seek early feedback from final users of the product.

Aim for – Customer satisfaction and Delight

Customer centricity and understanding the end user’s perspective are critical in a product-oriented approach. Teams will use techniques like design thinking and personas to put themselves in the customer’s shoes to maximize customer satisfaction and delight them with the product.

Practices that could help

2. Scope Management Anti-patterns

AP3 – Scope is committed already for the duration of the project

While elaboration of the backlog items may not have happened, scope boundaries are often defined and constrained with higher-level items like Epics/Features.

Aim for – Evolutionary roadmap that balances near term commitments and medium to long term forecast

Ongoing and Continuous backlog evolution with a Solution/Product Roadmap based on accelerated learning cycles using MVPs. MBIs etc.

AP4 – Backlog refinement is essentially elaboration and detailing of high-level scope items

Scope management is focused primarily on elaboration and detailing of the high-level scope defined before the project start. The product backlog is mainly a high-level plan that is built upfront and committed. During the course of execution, discussions are often limited to the scope boundaries already agreed upon.

Aim for – Aligning to product vision and user feedback through accelerated learning cycles

Scope management is focused primarily on aligning the product backlog to the product vision and user feedback through accelerated learning cycles. Product backlog strikes a balance between coarse-grained backlog items (that provide perspective for future sprints/program increments and are “forecast”) versus fully refined backlog items (planned to be consumed in the next few sprints)

AP5 – Product Backlog visibility is limited. Teams have tunnel vision

Visual approaches use limited or negligible. Product backlog visibility and understanding are poor across stakeholders because of details lost in excels and detailed documentation in Agile Life Cycle management tools like Jira and others. Teams do not have the big picture or understanding of the vision. They are primarily focused on their narrow team backlogs

Aim for – Highly visible and aligned Product Backlog

Vision is well articulated and understood across all stakeholders. Visual approaches like customer journeys and user story maps illustrate and create transparency around the product backlog and release plans. Customer journeys help to capture the end-to-end user experience and bring in customer-centricity. User story and Feature maps articulate the product evolution excellently. Teams have a good understanding of what other teams are doing, fostering collaboration.

Practices that could help

3. Planning and Prioritization Anti-patterns

AP6 – Planning is primarily resource leveling and dependency management

Prioritization and sequencing are weak as the end goal is to complete all the committed epics/features that define the scope boundaries of the project. Prioritization is focused mainly on dependency management and resource-leveling.

Aim for – improving value delivery and economic outcomes

Prioritization is focused on improving value delivery and economic outcomes using techniques that quantify the cost of delay, e.g., Weighted Shortest Job First. Teams strive to reduce risk by prioritizing complex work earlier and allowing for early integration to discover challenges.

AP7 – Commitment is not a whole team exercise

Planning happens in small forums, especially between people who are considered experts. Team involvement, visibility, and transparency around planning and work commitments are weak.

Aim for – Active team involvement for commitments

Planning is a whole team exercise, and teams are actively involved in work commitments. Leadership actively practices psychological safety to create a safe working environment where the team can voice concerns and challenges.

AP8 – Business stakeholders not involved throughout the lifecycle

Business stakeholders often do not like to be actively involved in co-creating the product and providing early feedback. They primarily involve in giving requirements and participate in acceptance testing.

Aim for – Business stakeholders to be actively engaged in co-creation

Business stakeholders actively participate in co-creating the product through close collaboration in planning, prioritization and by providing frequent, timely feedback.

Practices that could help

4. Team Organization Anti-patterns

AP9 – Short-lived teams for the duration of the project

Teams come together and organize for the project’s duration that may comprise a set of epics or features. The team often disbands once the project is over. A different project team might handle the next set of epics and features. A significant challenge is also created because each team has to go through each stage of the Tuckman model of forming, storming, norming before reaching the performing stage.

Aim for – Long-lived teams for the duration of the product

A core flex capacity model is often used to create long-lived teams for the duration of the product. A core team is set up and stable for the course of the product lifecycle. Additional teams are ramped up / down as necessary to respond to product needs and market rhythms and events.

Practices that could help

5. Budget Management Anti-patterns

AP10 – Fund and deliver the scope

Projects are initiated to deliver scope items. They may be high-level items like Epics. However, they still draw a fixed boundary. The duration and budget allotted are tightly coupled to the requirements listed in the Epic. Epic may be using terms like MVP, but that is often the first release not necessary about validation. Epic hypothesis and validation are absent or weak. Teams continue to develop the next in line requirements as per the plan. Budget management primarily ensures that the development of the agreed scope items happens in constraints – the planned budget and timelines. Variances on spend and schedule get tracked.

Aim for – Funding capacity to foster innovation and delivery of value

Capacity is funded for a predetermined cycle based on the strategic vision for the product. Epics are prioritized and implemented with a lean startup model. They have a clear outcome hypothesis that is validated with an MVP before the rest of the epic is developed. Pivoting and adjustment to the epic are done based on MVP outcomes and ongoing feedback mechanisms. This allows scope for innovation and is more focused on delivering value rather than sticking to a predetermined plan. The capacity allocation would be reviewed in periodic review cycles and adjusted as necessary. Innovation accounting and actionable product metrics provide the necessary input to the budget review cycles.

AP11 – Changes are viewed as scope creep and managed by change control boards

Minor changes within the high-level scope items agreed at the start of the project are considered OK unless they do not impact the overall agreed cost and schedule. However, significant changes might arise due to the accelerated learning inherent in an agile approach. These often get a push back from the teams because of the bureaucratic process involved. They have to be presented to Change control boards (CCB). The practices of the CCBs are many times not lightweight, creating a further demotivator for the teams even to propose changes. The better option is to push changes out of the project or park for later. The bureaucracy introduces delays that often create risk or a loss of opportunity.

Aim for – Building In Pivoting and scope alignment to evolving situations and accelerated learning

Budget constraints still apply with the capacity model. However, within those boundaries, solution/product roadmaps and plans evolve based on accelerated learning cycles. Pivoting is possible when needed and built into the process with the Lean Startup model for Epics and the periodic budget reviews for necessary allocation and adjustment. With this approach, change is welcomed rather than dreaded.

Practices that could help

6. Success Criteria and Metrics Anti-Patterns

AP12 – Track variances to the Iron triangle constraints

Success means managing adherence to the agreed scope, cost, and timeline. Tracking variances on those parameters helps in ensuring compliance and delivering to the “iron triangle” expectations. However, user feedback is often not included in the measurements because of infrequent deliveries and long cycles to production. This essentially means no major difference compared to a traditional approach.

Aim for – Delivering value to users and business

Success means ensuring that the users and business are satisfied with the product delivery. In that context, defining what constitutes “business value delivered” with business stakeholders and measuring that is critical. Teams clearly articulate what business value means and have clear ways to measure it. Soliciting user feedback through various mechanisms is actively practiced.

AP13 – Focus on Outputs and vanity metrics

Teams rely on metrics that measure outputs or are not very actionable. The velocity of a sprint when the definition of done only includes deployment to a system test environment is not a useful indicator of predictability for the overall release. A burndown chart as well that tracks task completion tells us if the team will finish the sprint on time but will the stories get accepted by the product owner? These kinds of process metrics often do not give insights to help answer the question “Are we building the right product?” and take decisions for course correction if needed.

Aim for – Focusing on Outcomes and actionable metrics

Teams measure metrics that focus on outcomes rather than outputs. . Outcomes could be increased user adoption for the product, improvements in business parameters, or customer delight, e.g., better user retention, increased sales, etc. While some process metrics might still be measured, the real actionable metrics are crucial that can help to keep us on track to maximize stakeholders and user value delivery.

Practices that could help

7. Incident Management and Operations

AP14 – Traditional IT Service Management with tiered support models by siloed operation teams

Project teams primarily focus on developing the product and handover to operations. However, functional silos exist between Dev and Ops. The operations team relies on traditional ITSM approaches like tickets, SLAs, and CABs in a process-centric – service lifecycle approach that is outdated in today’s world. They are replaced already by better models even with leading service management standards like ITIL. However, teams don’t leverage them.

Aim for – Holistic IT Service Management with digital-age practices

We need to think of service management holistically. It is a means of delivering business value, not just IT value. Dev and Ops work as one team together (either structurally or as a virtual team) to maximize both – new feature delivery and ensure the system’s stability. Teams rely on digital-age practices like DevOps, SRE, High-Velocity ITSM, Safety Science and Resilience Engineering, and Swarming Support Models to ensure they remain focused on value delivery.

Practices that could help

DevOps
SRE
High Velocity ITSM
Safety Science and Resilience Engineering
Swarming Support Models

Share this article

Leave your comments

Post comment as a guest

Comments

Comments

No comments found

Hrishikesh Karekar

Agile Expert

Hrishikesh is a Director, Financial Services BU at Capgemini. He has 19+ years of experience in IT software industry playing high responsibility roles as Agile Transformation Lead, Agile Coach, Program Manager, Delivery Manager, Technical Project Manager, Technical Lead & Software Engineer. Hrishikesh is passionate about building high performing teams, taking individuals and teams on a journey of excellence and satisfaction. His vision of Agile is not just about implementing effective, efficient and lean processes, but transforming people’s mindsets – to deliver better ROI and real business benefits. Hrishikesh holds a Bachelor of Engineering, Production Engineering from VJTI, University of Mumbai.

From Project to Product: The Complete List of Agile Delivery Anti-Patterns