Skip to main content

How to Handle Predictability Requirements in Scrum Consulting for Large Corporations?

Last post 06:25 pm November 1, 2024 by Ian Mitchell
3 replies
02:50 am October 31, 2024

Hello, Scrum Community!

I’m facing a dilemma that I believe many of you may relate to. In Scrum, our process is iterative and adaptive, which differs significantly from the traditional Waterfall model:

- Waterfall:
 - Starts with a complete and detailed requirements gathering.
 - Defines a fixed scope and a strict timeline.
 - Sets an overall budget, with delivery after several months based on a rigid roadmap.

- Scrum:
 - Flexible, dynamic scope: The backlog is updated as the team discovers new ways to add value.
 - Continuous evolution of requirements: Requirements are not fixed at the start and may change to better meet client needs.
 - Incremental value delivery: The process continues iteratively, adapting until all needs are met.

While this iterative approach might work more easily within a company’s internal consulting teams—where a tech area provides solutions for other business areas—it becomes far more complex in external B2B consulting. Large corporations that hire external consultants often expect:

- Cost and timeline certainty: They want to know the project’s total cost and timeline upfront.
- Clear deliverables: They need clarity on what will be delivered at the end of the project.

These expectations can challenge not only the clients but also the consulting firms that must allocate resources and manage financial risks effectively.

Key Challenges and Questions

1. Predictability vs. Flexibility:
  - How can we balance clients’ need for predictability with Scrum’s iterative nature?
  - What strategies can provide cost and timeline visibility without compromising Scrum’s flexibility?

2. Resource Allocation:
  - For both consulting firms and clients, committing to a project without a fixed scope raises concerns about team and resource allocation.
  - How can we demonstrate the need for a dedicated team while the backlog remains flexible?

3. Risk and Cost Estimation:
  - How can we estimate risks and costs in a process where scope and requirements evolve continuously?
  - What practices can prevent budget surprises while preserving Scrum’s adaptive approach?

4. Acceptance of Incremental Delivery:
  - How can we manage expectations around incremental progress rather than “final” deliveries in each Sprint?
  - What approaches do you use to demonstrate that Scrum delivers value even without a fully-defined outcome at the start?

Open Question to the Community

I’d love to discuss how you, in your practices, have developed approaches to position Scrum as a reliable and measurable process in external consulting.

- How do you address corporate clients’ predictability expectations in a B2B context?
- What strategies do you use to estimate costs and timelines while reducing perceived risks for both the client and your own firm?

I’d greatly appreciate any insights and experiences you can share regarding these challenges!


08:19 pm October 31, 2024

Predictability is determined by the rate at which work is Done. Knowing that work is Done is the foundation of empirical process control.

The basic unit of accounting in Scrum is therefore the Sprint. We can work out how much it costs to fund X Developers for Y Sprints. Each Sprint is a project, and the most important one we can have, since it allows empiricism to be established and maintained.

The more Sprints a client purchases, the more innovation runway they have for managing risk and uncertainty, and for learning to build the right thing at the right time.


03:39 am November 1, 2024

The more Sprints a client purchases, the more innovation runway they have for managing risk and uncertainty, and for learning to build the right thing at the right time.

That's an interesting strategy, Ian. I could sell a sprint, or a package of sprints, and I can estimate costs by "X Developers for Y Sprints."

But how can I convince my lead that this is in his best interest and that Waterfall isn't the best way to build his solution? How do I approach the subject after my client has shared his pain points and I already have a good understanding of his business?

Most clients in large corporations aren't technical, and usually, we negotiate with managers or directors. I also assume they have their own processes and rules to manage yearly budgets and account for results, especially if they're listed companies subject to various regulations.

I just don't know how to start this conversation without risking alienating my lead. I don't want a manager or director to feel as if I'm patronizing him or to think that this isn't in his best interest or, worse, that it's a scam.

It's more about negotiation, contracts, and sales for B2B consulting. Is it possible to convince clients and create technological products through B2B consulting using Scrum? How do you sell?

 


06:25 pm November 1, 2024

That's a training course in its own right. Soft skills are key, and making the most of opportunities to engage with sponsors and to develop rapport with them. Some of the techniques include vulnerability, open questioning, the art of wondering, and being able to promote a train of thought.


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.