They are doing it wrong. Once the cash runs out the user stories go onto the backlog until the client hands over more cash. Which is the point of sprint reviews and collaborating closely with the client. So they understand that they can have this feature or that feature but unless they produce more cash they cannot have everything.
It comes down to estimating the user stories as well. Agile methodologies like scrum are project management methodologies but you have to know what you are doing and it's really only suited for projects that have a UI. In particular web development. At least in my opinion.
A place I worked at ditched waterfall at the organizational level. For scrum one of the reasons they did that was to cut out process that costs to much money. So they would be more competitive when bidding for work. Is that a good thing? Maybe, maybe not.
We bid a fixed cost to perform a defined set of requirements. There is an occasional need to clarify a requirement but in general from Day 1 the scope of work is known, what we're being paid is known. You can dev in Agile or Waterfall, but either way it's not a "let's figure it out as we go" situation. There is no opportunity to work with the customer to horse-trade potential additional features by removing requirements. The amount of BS required to modify the requirements just doesn't allow it.
So with a PM hat on, my problem is that no one should ever say "I don't know what it will take to finish and I don't know what it will cost". You bid a cost against a set of requirements that doesn't change. When I worked in a waterfall method, people could answer those questions. I don't understand why Agile creates a dense fog around what the remaining work is. It's the same scope and requirements today as it was before.
Still with the PM hat on, another problem with Agile is it gives people with a certain mindset too much opportunity to avoid accountability. Everyone else has to commit to a timeframe and budget, and Agile isn't a golden ticket to get out of that. I've seen stuff like this:
Sprint plan: Item A is 8 points and will finish in 6 sprints.
End of sprint 1: Item A is 8 points and 3 are complete.
...
End of sprint 4: Item A is 15 points and 7 are complete.
...
End of sprint 6: Item A is 22 points and 12 are complete.
Nope, you don't get to move the goalposts. Item A hasn't changed from Day 1. You were supposed to finish in 6 sprints. You don't get to say "I was only planned for 8 points and I got 12 points done! Yay!" NO. You got half the work done that you said you would since Item A is only half done.
That said, I think Agile is an excellent fit for software being developed for INTERNAL use, where everyone can be flexible and figure out as they go what's the most important things to be done.
Facebook
Twitter