Re: [scrumdevelopment] SCRUM with Fixed Price Contracts
- On Saturday, July 1, 2006, at 12:05:12 PM, Vickydhiman wrote:
> Hello Ron [and Group] :)Hi ... I was really wondering what you did /before/ you tried to go
Agile, and how it had been working, and why you weren't able to do
at least as well in an Agile situation as you did then. I'm not sure
whether that's what you were addressing, but there's plenty of stuff
to chat about:
> First of all, one of the reasons why I joined Agile was not onlyOK ... I think I'd be inclined to do this with pen and paper, or my
> because we have trouble with our Hybird methods [mix of RUP +
> SCRUM - and no we don't call it SCRUM :) ]. First of all our
> organization deals with Web based projects only. What we generally
> do is define requirements up front in detail [at least till a
> level that goes through the reviews passed as detail enough]. We
> traditionally do it by explaining using a sample wireframe of the
> screen and how different set of users would be able to use the
> functionality on the wireframe. I guess it would be better to
> explain it with an example:
> I would draw a simple screen [using PowerPoint or some other
> simple too] with two text boxes [for user name and password]. I
> would also dig up my image library for sample submit buttons/
> reset buttons. I will place the links Register Now and Forgot
> Password. I will then explain function of buttons and links. I
> would also make it a point to mention that registration link goes
> to the registration wireframe [wireframe number would be
> provided]. In case of unsuccessful log in [exceptions], the
> wireframe screen is also referenced. Similarly, ideal case is
Tablet, but to each ...
> Based on this, we would use our historical estimates [revisedOK, sounds good. I'm curious about a statistic. I've always
> every month] for sign-in screen and add-up these estimates for all
> screens. In case, the estimate does not exist, the screen is shown
> to three senior "Technical Leads" [managers are not kept in loop
> during estimation]. Average estimate is taken for these screens.
> After all the estimates are added, the project is multiplied with
> a complexity factor and an analyst who has not been involved in
> estimation process would review the estimates. Once approved, the
> estimate is sent to the client in the form of proposal
> [wireframes, basic use cases and estimates].
suspected that projects like these have a roughly constant cost in $
/ time per screen, or worst case $ / time per screen widget. Do you
have enough data to address that fantasy of mine?
> Once the project is approved, the project is run largely on SCRUMOK ...
> principles. From all the screens - various modules are identified.
> Based on modules selected by the clients and dependencies [GUI
> design must proceed integration of GUI with backend] sprints
> [generally 2 weeks] are identified.
> For the sprints - tasks are written in detail over the first twoWell, yes ... but if there isn't a card for it, it's an oversight.
> days. Client is involved in these tasks [written more like
> acceptance tests]. This is the phase where trouble actually creeps
> in. Some of the clients [we work with dedicated clients] can
> indulge in long discussions on what is in scope and what is not.
> For instance, in the example above there could be added
> requirement of double opt-in procedure. Although it hasn't been
> mentioned in proposal, the clients come back with arguments like a
> self respecting website would always have double opt-in for all
> the member registrations.
Whose oversight is it supposed to be, the customer's or yours, and
why? Do they "sign off" on the requirements / features / stories in
> I agree that this is not much additional work, but these longWell, I'd think I'd go back to framing earlier if it's delaying
> discussions tend to drag the task formation from two days to
> sometimes three days or even one week depending on complexity of
> module. We tried to start framing tasks one sprint before [I mean
> if team is working on Sprint n, then Managers get working on tasks
> for Sprint n+1], but then it created conflict for manager to focus
> on current sprint in hand. We have tried better communication.
> After everything what it comes down to is even lengthier proposal
> document which outlines more "what is not in scope" than "what is
> in scope".
things. I'd also wonder why the manager has much to do in the
current sprint. Is manager also serving as Scrum Master, or ...
And who's the Product Owner? How do they interact with the process,
with the customer, with the team?
> Another problematic area is the top management starts viewingMemo to Top Management:
> estimates [proposal estimates] as the metric and the teams which
> exceed that metric are categorized as under performers.
Subject: Stupid Top Management Behavior(tm)
We produce estimates for projects, not promises. We can begin to
produce promises if you want to. (See below.)
Estimates have the property that sometimes they are high,
sometimes they are low. Performance is reality, estimates are
guesses. Performance will sometimes be better than an estimate,
sometimes worse. If performance and estimates average out equal,
estimation is pretty good, and we might want to work on reducing
But since an estimate is not a promise, it is Stupid Top
Management Behavior(tm) to behave as if it is. If you would like
us to give you promises instead of estimates, we can do that.
However, be aware that in order to avoid ever going above our
estimates, we will have to raise our estimates. This will have the
result of reducing the competitiveness of our bids.
We await your command.
Your Worshipful Staff.
> I agree completely that capturing all requirements upfront isYou certain can ... you can do the estimates the same way you would
> impossible. Even writing down everything you know in a manner
> which is free from mis-interpretation is difficult if not
> impossible. Hence, my interest in Agile. However, the market we
> operate in is such that if we do not provide fixed price
> estimates, we would be out. And our fixed price estimates are for
> fairly complex projects - where one wrong or erroneous capture can
> be quite costly.
> Perhaps a more possibly question can be - how can we provide a
> fixed price estimate for all the sprints/ iterations up front? Or
> even can we?
were you not doing Agile. I would imagine that that didn't work very
well in the past, and that it would continue not to work very well
in the future.
Agile does give you an advantage if you choose to use it. Because an
Agile project [done as they are supposed to be] delivers features
from beginning to end, and because it can do any features in any
order, you have the ability to do these things, which can help you
perform to your original estimates:
- do the most important things first, maximizing value to the
- do the most risky things first, giving you more time to respond
to difficulties that will arise;
- do minimal versions of features, to deliver value early, to get
concrete feedback, to ensure basic contract compliance;
- fill in the frills and fancy bits on the features as time
permits toward the later parts of the process;
- be completely up front with the client on what is done, not
done, being done, and allowing them to take part in steering the
project to their best satisfaction.
I don't know how to estimate any better than before I did Agile,
except that I know how to estimate more quickly and simply.
But I do know how to deliver a sequence of features better, which
allows me to do a better job of satisfying the customer within a
fixed and finite budget.
> I am quite a new comer to Agile and Project Management in general,Wrong gurus.
> but these issues look all pulling in all the directions to me. And
> from what I have read about Agile, if something is not making
> sense, it means that you have not followed some simple and basic
> principles. Unfortunately for us, number of so called gurus either
> have not been of much help.
> P.S. I also agree that having a pre-sales team spending time onOK ...
> these proposals is a bad investment especially if we do not get
> the contracts. But that can be for some other time.
Accept your conditions, but not your fate. -- Rod Walsh & Dan Carrison
- On 5 Jul 2006, at 16:33, Vickydhiman wrote:
> Hello Sammy:[snip]
> Developers create the estimates based on specifications done by
> Analysts. For most cases, estimates already exists and are pulled
> from the database.
How accurate are the estimates pulled from the database? What happens
when they're wrong?
Who decides that the developer has met the analysts spec?