3

As far as I understand, Scrum doesn't impose obligations on a software development company - no fixed date of project's completion, no fixed budget.

How can a customer be sure that a Scrum team isn't wasting their money or at least spend them carefully?

I mean that the Scrum team may not be interested in working efficiently, give higher estimates for tasks in order to be able to work lazily, or the software development company may even be interested in working on a project as long as possible (if it gets paid for time and materials contracts).

  • 1
    The underlying assumption of your question is based on Theory X management. Further, there's a false premise buried in your question that utilization or efficiency of developers is a valid proxy for economic value. Scrum isn't just for development teams; it requires a paradigm shift for customers and stakeholders, too. – Todd A. Jacobs Sep 19 '20 at 17:40
  • 3
    How are customers sure that a non-Scrum team isn't wasting their money? I'd like to know what your baseline for knowing money is well spent is :) – Erik Sep 20 '20 at 15:41
  • @Erik It's simple. They don't know, BUT they instead have a contract that a finished, tested product will be delivered on a specified time. – Daniel Sep 24 '20 at 12:41
  • @Daniel ok, if we buy into that dream, how do the customers know the contract isn't overpriced so the devs can laze about and still get it completed? – Erik Sep 24 '20 at 12:52
  • @Erik Independent software consultant, maybe from their own company. Or comparing the prices proposed by various other software vendors. – Daniel Sep 25 '20 at 17:52
4

Iterative delivery. If each sprint the customer is testing and potentially releasing a working increment of functionality then they have regular evidence of the quality of product, they can feedback on any problems and they can prioritise future work as needed. Also the customer has the option to walk away if they choose and keep what was already delivered. This contrasts with other delivery approaches that may have longer delivery cycles, entailing greater risk and less opportunity to fail fast.

Budgetary and time constraints are essentially business contractual matters and nothing to do with whether Scrum is used or not. No framework or approach can guarantee delivery on time and budget, but Scrum is a good way to maximise your chance of doing that.

  • But the fact that "each sprint the customer is testing and potentially releasing a working increment of functionality" doesn't mean that a Scrum team isn't wasting his money or at least spends them carefully. – Daniel Sep 19 '20 at 16:57
  • Sure, but if you are paying someone to do a complex piece of work then you should work closely with them, monitor progress, inspect the results and keep an eye on how your money is being spent. That's the same whether you are using Scrum or any other approach. – nvogel Sep 19 '20 at 17:12
  • 1
    @Daniel The problem you are describing is a problem. However, it's not a Scrum problem. You could do the same thing in a waterfall project and waste money for a year before the customer noticed. Additionally, if you want to be even more engaged as a customer, you can look at how XP approaches it. In it, there is no product owner. They have a real customer working alongside the team. Menlo Innovations works this way (menloinnovations.com/our-way/our-process) and they do virtual tours. If this is a real-life problem for you, I'd look at how they work. – Daniel Sep 19 '20 at 17:20
  • @nvogel A Product Owner doesn't often have (and shouldn't) technical background so he can't tell whether the technical team works efficiently. – Daniel Sep 19 '20 at 17:25
  • 1
    What do they want? And why are they concerned. The reality is that they are at far lower risk with Scrum because they are only committed for a few weeks. If they don't like what's delivered, they demand a new team or leave for a new software company. Fixed scope fixed date fixed cost projects provide a guarantee, but have the problem that if they got the req's wrong at first they are out of luck and statistically, few of those projects actually deliver on the promise. – Daniel Sep 19 '20 at 17:43
4

TL;DR

In most agile frameworks, you measure success or failure based on measurable outcomes, not utilization rates or external process governance. In fact, measuring anything other than objective outcomes will be counter-productive.

If you find yourself asking whether a Scrum Team is working "hard enough" for the money you're spending, you're focused on the wrong thing. Instead, you should continuously re-evaluate whether the rate of progress towards the business goal is ahead or behind, whether the evolving product is currently (or likely to become) fit for purpose, and whether the current or future value of the product is aligned with your project's total budget or ongoing run costs.

Collaboration Over Contract Negotiation

The project sponsor (in most cases, the internal or external customer) is ultimately responsible for collaborating with the project team to continuously refine "good enough" in various dimensions. The Agile Manifesto explicitly values customer collaboration over contract negotiation. As an agile framework, Scrum provides for effective collaboration through (among other things):

  1. Ongoing stakeholder engagement.
  2. Process and progress transparency.
  3. Predictable cadence of framework events, including frequent inspection and inflection points.
  4. Incremental product delivery.
  5. Ability to "fail fast."

While the Scrum framework doesn't guarantee success—no framework does; that's a misguided assumption, but a common cause of finger-pointing in contractual disputes—it does provide an extremely strong empirical framework for avoiding sunk costs. By leveraging the framework, product sponsors and other stakeholders have frequent opportunities to inspect the developing product, collaborate with the team, refine expectations, measure fitness for purpose, and wrap up projects early (e.g. when "good enough" or "doomed to fail").

Sponsor/Customer Expertise Matters

If the project sponsor (or customer) lacks the domain expertise to evaluate "good enough" or "doomed to fail", then they need to do one or more of the following:

  • Find a trusted advisor or subject-matter expert they trust to provide some basic governance and decision-making.
  • Bake time for knowledge transfer and self-education into the project budget.
  • Learn from the Scrum team over the course of the project.
  • Be honest with themselves (and the Scrum Team) about their levels of expertise and confidence in the project.

Sponsoring a project you can't understand or effectively measure is a bad idea, ab initio. However, effective communications, ongoing collaboration, and continuous 360° feedback can create the trust, confidence, and domain knowledge to oversee such projects effectively.

See Also

3

Todd A. Jacobs gave a good example of how to handle this within a Scrum context, but this isn't entirely a question about Scrum. The broader question is if you can trust the vendor or not, no matter if they are using Scrum or something else.

Trust + time + inspection

I'll formulate my answer by using an analogy.

Let's say you go visit some third world country as a tourist. You land at the airport and you need to go to your hotel. You exit the airport and you see a bunch of taxis waiting in front of the airport. You get into one and they will drive you to the hotel at the right price and using the correct route, right? Well... no. If you do that you will probably be ripped off. You will pay more for the ride, you will probably go on the longest and slowest route, the taxi driver might not even start the meter but tell you the price once you reach the hotel (assuming they don't take you to the nearest forest and rob you of all your money).

So, getting into the taxi, first starts with trust. Do you trust getting into the car with that driver? If you are naive you will probably get into the car. If you know how those people operate you will not. But you still need a taxi to get you to the hotel. You need a taxi you can trust more than those guys sitting in front of the airport waiting to "catch a big fish". You might, for example, arrange for transportation with a trusted company before arriving at the airport, or there might be some self-service terminals in the airport that you can order a taxi with (and they give you the car identifier in which to get in), there might be a list of trusted companies that are listed at the airport and you can call their dispatcher and ask for a taxi, etc.

Getting back to the software vendor, this implies finding a trusted vendor to begin with. So you must perform some due diligence and select a vendor with reputation, experience, recommendations, etc, not just pick a vendor from the street.

But even if I get into a more trusted taxi or find a more trusted software vendor, in the context of this question, I can still get screwed on the way to town. Here is where time and inspection come in. You start on your drive and you are careful at what is happening. Did the driver start the meter? Is the price the same as the one written on the door of the taxi or the one you agreed upon when ordering the taxi? Is the car going in the general direction it should be going? You give it some time and you look at what's happening. If you want to stare at the scenery instead, then that's your problem.

Going back to the software vendor now, you start the project and monitor what's going on. How is the communication with the vendor? How is their progress? Are they delivering what they said when they said? What's the quality of the product that they are delivering? Do they ask for questions? Are they transparent with their work? You need to be involved. You can't step out of the picture and stare at the scenery instead. More so with Scrum, where the client must be involved in the project, not like in something like Waterfall where you can throw some requirements over the fence, disappear, then come back at the end and complain that they built the wrong thing. You have to be involved, monitor what's going on, and collaborate with the vendor. Here is a counter example: what if the Scrum team isn't lazy, but very fast? Is that automatically better? It's not, because they could be producing garbage code very fast. So you have to inspect the deliveries and progress and see if it matches your expectations. Is the product evolving how you want it? Is it where it's supposed to be? Is it doing what you need and of the proper quality? If it isn't, then you decide what to do (i.e. inspect and adapt).

Going back to the taxi ride, if you notice after a while that something isn't right, you decide what to do. Keep going or tell the driver to stop and get out. If you are in town, you might decide to get out of the car. If you are in the middle of a corn field then you might decide to continue even if you know you will pay more money than supposed to. The same with the software vendor: if you see something not right, you decide what to do. Continue, change something, stop the project entirely, increase collaboration, reprioritize stuff, etc. But in order to do this, you need to understand what's going on inside the project, you need some expertise in managing software projects to recognize when you are not where you want to be. Otherwise you just have to trust that the vendor isn't ripping you off, or in the case of the taxi analogy, trust that the driver will do an honest job and get you to the hotel on the right route and at the right price.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.