2

I work for an agency that has a number of customers that fall into the same trap. They have a concept for a piece of software, we do some analysis, sign-off on initial scope/backlog and a reasonable budget and start agile development. However once the client starts to see the product they cant help but tweak endlessly despite our protests and go massively over budget.

What is the state of the art in building new software products efficiently as possible? Should we be prototyping the interface (smoke and mirrors, no backend functionality) until it looks and behaves exactly the way users want it, then build out the functionality? When does a prototype stop and the real product start? Who are the most progressuve thinkers on this front and what are the leading concepts in delivering new software products to market quickly and with minimal waste? Is lean startup (Ries) the most forward movement to adopt?

  • You don't seem to be agile. If you are, what exactly is your problem with this approach? – nvoigt Sep 15 '16 at 13:06
  • 1
    Sounds like you don't get sign-off on specs from your customer and that you are missing a change-request mechanism. – Danny Schoemann Sep 15 '16 at 14:26
7

They have a concept for a piece of software, we do some analysis and agree on reasonable budget and start agile development.

Good.

However once the client starts to see the product they cant (sic) help but tweak endlessly

Also good.

despite our protests

Why are you protesting? If you're in an agile environment, you are supposed to embrace change, not protest it.

and go massively over budget.

And here we see the problem. When you add something into a project, you must take something (requiring approximately equal time+money) out. Or, alternately, you need to add more time and/or money.

Customers changing their minds is normal, expected, and to a point even required by Agile processes and sensibilities. Whereas more traditional methodologies (such as Waterfall) attempt to reduce the likelihood of change, agile methodologies attempt to reduce the cost.

The problem here seems to be that you aren't reducing the cost - which leads to expensive changes. The traditional reaction to expensive changes is to avoid changes, which seems to be what you are attempting to do.

From an Agile perspective, that is wrong. What you should be doing, instead, is making the change beneficial, rather than costly. Make sure that every change adds value to the project - keeping in mind that the only one who is authorized and empowered to determine value is the customer (or the customer's representative, such as the PO in Scrum).

When the customer comes up with a change like this, you need to make certain all impacts of the change are visible to the customer - they need to give up this other feature, or they need to pay more, or the project deadline needs to be pushed back, or some combination of these. (Worth noting, however, that throwing more money at a problem has its limits in effectiveness.) After this, the customer makes the decision of what to compromise - or, perhaps, they'll decide they don't need their shiny new widget after all.

What is the state of the art in building new software products efficiently as possible?

Massively subjective, if you're talking about methodologies and processes. Not only will opinions differ, but the processes themselves vary in suitability based on the situation. There is no one true 'best practice' for software development.

Should we be prototyping the interface (smoke and mirrors, no backend functionality) until it looks and behaves exactly the way users want it, then build out the functionality?

How far you go with prototyping is a trade-off between giving more 'visible' functionality to the customer sooner versus having more working functionality sooner. Typically, the customer should be the one to determine the value of each, though this varies depending on what process you're doing. In Scrum, for example, if you spend the entire sprint creating a big shiny prototype, and you end up not having a shippable product, that's bad.

The rest of your questions are, as with the 'What is the state of the art?', highly subjective.

  • Hi, thanks very much for your comments. I was expecting to be flamed with something so subjective! I think the key here is the customer (the PO) is aware of the impact, increasing costs but I don't believe are acting in their own best interests as they're ignoring the MVP and haven't validated their market/product yet. Re: state of the art - I was was hoping someone could point me to some new (but proven) methodology like Agile development or Lean Startup that could help me help clients be efficient as possible rather than using code development as their playground for testing ideas. – DaveO Sep 16 '16 at 2:37
1

It sounds like the approach you are taking is on the right track, however every time they ask for one of these tweaks I would reinforce the point of maximising value. If they ask to move something / change the UI, I would be saying "Sure we can do that, if you think it is higher priority than adding (the current top priority missing feature)?". If they genuinely think that is the highest priority, then deliver it - it's their problem if they are paying you to deliver lower value work, not yours.

1

There are two factors that you can manage: time and scope. The classical (waterfall) system was to attempt to predict and control both. The results were projects running over budgets for time & money, not delivering the original scope, and low quality.

When creating and delivering with agile software development, you often choose one to limit and the other becomes a forecast. For example, time (cost) can have a set limit and the scope (features) forecast is updated as work progresses. This maintains a fixed cost and makes visible the effect of ever-changing desires.

Of course this is all assuming that the Manifesto for Agile Software Development is being honored.

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.