Re: [scrumdevelopment] SCRUM with Fixed Price Contracts
- Hello Ron [and Group] :)First of all, one of the reasons why I joined Agile was not only 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 referenced.Based on this, we would use our historical estimates [revised 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].Once the project is approved, the project is run largely on SCRUM 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 two 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. I agree that this is not much additional work, but these long 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".Another problematic area is the top management starts viewing estimates [proposal estimates] as the metric and the teams which exceed that metric are categorized as under performers.I agree completely that capturing all requirements upfront is 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?I am quite a new comer to Agile and Project Management in general, 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.ThanksVickiP.S. I also agree that having a pre-sales team spending time on these proposals is a bad investment especially if we do not get the contracts. But that can be for some other time.
Ron Jeffries <ronjeffries@...> wrote:On Saturday, July 1, 2006, at 5:15:38 AM, Vickydhiman wrote:
> Is it possible to run SCRUM with fixed price contracts especially
> custom projects? For instance, lets say you need to make a program
> to communicate between two satellites. And client is big company -
> say NASA. They would only entertain fixed price estimates but are
> happy to run the project with SCRUM. Now in order to give a good
> estimate, I need all requirements defined to sufficient level of
> detail - along with complexity/ third party components price/
> resource chart etc. That goes against Big Design Up Front [or is
> it different?] of Agile/ SCRUM? Without this, I cant estimate
> amount of work using any method.
> If I leave things to chance at a later stage then I might keep discovering the devil in detail
> far too late, far too often [every sprint] and my estimate is going to shot way over.
> How can this be handled?
I'm curious: How do you do fixed price contracts now, that doesn't
"leave things to chance"? Do you actually have all the requirements
up front? Given whatever you get, how do you estimate now?
This is how I develop software.
Take the parts that make sense to you.
Ignore the rest.
Do you Yahoo!?
Next-gen email? Have it all with the all-new Yahoo! Mail Beta.
- 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?