- Glen While I see the value of your question, I think what Jon is pointing out was not an unusual situation, when the RFI was used to reveal the ‘bestMessage 1 of 15 , Feb 28, 2010View Source
While I see the value of your question, I think what Jon is pointing out was not an unusual situation, when the RFI was used to reveal the ‘best ideas’ from multiple vendors. The resulting RFP’s and RFQ were not much more than a combined shopping list from all the vendors who submitted. To the ‘winners’ of such contracts, the software CLIN’s were often poorly disguised lifts from the RFI’s and the RFP responses. The performance CLIN’s that used MIPS as a criteria still make me edgy. That single bogus criteria probably wasted more ink, legal time, and fruitless development than anything else that comes to mind. Here we had a marketing gimmick being accepted as a benchmarking tool. If you worked for Sperry, CDC, DEC or Wang and had IBM influencing contracts to use MIPS you knew you were going to spend a truck load of time building crap that allowed you to show your system stepping through instructions that mimicked the IBM instruction set and did not take advantage of the advances your products had in macro instruction management. Now jump back to Jon’s comments about an estimate that is supposed to be within 10% and I think Jon’s politic description of this being R&D is a sign of his restraint and maturity.
(BTW my apologies to all those who follow this group. My example is as far from stories and wireframes and UI UX as you can get, but I hope it goes to show that even those of us who dwell in the underworld of computers have usability issues!)
"Planning constantly peers into the future for indications as to where a solution may emerge."
"A Plan is a complex situation, adapting to an emerging solution."
What would define as a "R&D" project?
From: email@example.com [mailto:firstname.lastname@example.org] On Behalf Of Jon Kern
Sent: Sunday, February 28, 2010 1:19 PM
Subject: accurate quotes was Re: [agile-usability] stories and wireframes
well, therein lies my original reason for developing an agile process in
the early 90s... The DOD projects and government customers always seemed
to want estimates +/-X% where X was often pretty low -- like 5% or 10%.
And the projects were R&D, not "Build me another of those simple web sites."
If you get a list of requirements that are like this:
Title: simple feature name
Description: Given X, when Y, Then Z
Hours: estimated time to complete
Risk Multiplier: number like 1, 2, 3 used to multiply the hours by
You can control various parts of your process to at least give the
**illusion** of trying to be responsible at getting an accurate quote.
* Comprehensive nature of the list is inversely proportional to
order of magnitude. You want +/5%? Then you can't leave items off
* Be sure you do not have any risk levels higher than desirable --
or you have to do work to knock down the risk, or simply accept
the multiplier. Acceptable risk level is inversely proportional to
order of magnitude. You want +/5%? Then you can't leave huge swags
in your estimation process.
If you want a highly accurate quote to +/5% on a difficult R&D-like
project, then you basically have to jointly do enough up-front work
until both the client and the developer agrees to have enough
information to make an accurate quote. That's because the nature of such
development (IME) is one of discovery. Pretty hard to estimate that
which is yet to be discovered. Hence, agile methods...
Personally, I find trying to get to an accurate quote is frequently hard
to do and has little payoff. The RFP style of doing software for R&D
type of projects is often a sham. For my money, it is better to work in
the open. Iterate to a reasonable guess at what can be done within a
given budget, and then manage to it as closely as possible, allowing
changes as the business sees fit and is willing to accept.
Tim Wright said the following on 2/27/10 2:24 PM:
> what's the minimum level of up-front analysis necessary in order to------------------------------------
> give a quote that's accurate within an order of magnitude?
Yahoo! Groups Links
- Hi Tim benefits of an agile approach, are not obvious, if you are new to it, and it does take time to win the client/stakeholder(s) over sometimes. theMessage 2 of 15 , Mar 3 3:08 AMView SourceHi Tim
benefits of an agile approach, are not obvious, if you are new to it, and it does take time to win the client/stakeholder(s) over sometimes.
the Analysis, happens early on, this is true, but it is not shallow, if anything it is deeper than traditional approaches.
1. Team based meetings that are designed to generate awareness of the project, as a whole.
2. Team meetings to establish the weight of each component of the project, adds another level of project awareness through the team.
3. Indepth consideration of each component, breaking it down into independant/dependant/critical/non-critical elements
these 3 stages of project understanding are so beneficial, and when you involve all the people and utilise the idea of open questions, the team can get great focus and direction.
4. Sprints, quick daily catchups, can seem daunting, commiting 20 minutes each day, but, again these are so beneficial, because indirectly each team member that is having an active part at the time in the sprint, gets direct feedback.
in fact the only potential obstacles to an agile project work method, are the people involved. - awareness of the methodology is best gained through taking the plunge and trying it. We got an external agency in to train up the scrum masters.
--- In email@example.com, Tim Wright <sambo.shacklock@...> wrote:
> Here's a question that's been in the back of my mind for some time now:
> If the only up front analysis work you do is enough stories for the first
> iteration, how do you estimate the cost of the project so that the sponser
> can determine if the project has a worthwhile cost/benefit ratio?
> On Sat, Feb 27, 2010 at 7:07 AM, William Pietri <william@...> wrote:
> > On 02/26/2010 08:09 AM, Alla Zollers wrote:
> > > Hi Everyone --
> > >
> > > I am a designer currently working on an agile project and we are in
> > iteration 0, the story discovery phase. The team has been using story
> > trawling to discover all the various stories, and it has worked to a degree,
> > but after some of the basic CRUD stories have been written, the more complex
> > flows honestly require more thought and perhaps a wireframe to truly flesh
> > out all the functionality. [...]
> > >
> > > I guess this bring to the forefront my biggest discomfort with agile,
> > there is thought that needs to go into design and functionality, but when do
> > you do this? and how do you involve the whole team?
> > >
> > Hi, Alla. A lot of people will have answers on this. Here's mine.
> > My main thought is that if you are doing it right, the team should never
> > stop thinking about design and functionality, about whole products and
> > real users. Unfortunately, a lot of people making a waterfall transition
> > bring along dangerous habits, like concentrating design thinking in an
> > up-front phase, or trying to discover all the stories before starting.
> > My experience is that the minimum you need to start the first iteration
> > is to have enough stories defined that the team has at least an
> > iteration's worth of work to do. That's it. Generally, that won't be a
> > lot, as things are slow-going at the start. As that work proceeds, the
> > product and design folks start fleshing out a sensible backlog. The
> > backlog, in turn, makes it clear what research, what design, what
> > thinking needs to happen so that the team is ready for future iterations.
> > One of my teams is on something like iteration 163 right now, and shows
> > no signs of stopping. There's no way that up front they could have
> > discovered all the stories that they have done, let alone the ones that
> > they will do going forward. And if they had tried, a lot of the work
> > would have been wrong: the best designs come from the best information,
> > and the later you are in the project, the more information you have.
> > So instead of creating a plan and trusting it, put your faith in the
> > team's ability to learn, to discover, to create. The shift that you need
> > to make is from being plan-driven to being planning-driven. Which might
> > sound like a small step, but it's a scary one: you're giving up the
> > thing that made you feel safe before, and you haven't yet experienced
> > success with the new approach.
> > William