Agile vs. Waterfall in Preparing Fixed Price Bids
Agile vs. Waterfall in Preparing Fixed Price Bids

Delivering Fixed Price Proposals in less than 30 Days: Are Agile Development Organizations Better?

One could make an argument that Agile Development organizations are better trained, more prepared and could deliver higher quality proposals than Waterfall based Development organizations.

In this post, I’m just going to cover a couple of items at a high level.

Agile vs. Waterfall in Preparing Fixed Price Bids
Agile vs. Waterfall in Preparing Fixed Price Bids

Proposal Turnaround Time is Critical

If the organization has typically 30 days to turn around a proposal, which type of organization will be more comfortable in doing so, Agile or Waterfall?  I think it is an easy call.

In an Agile (Scrum) environment, the whole Organization (Project, Business, Technical, Finance and Quality people) can be optimized for producing results every 2 to 4 weeks.  In a Waterfall environment, requirements or design writing could take weeks or months prior to even developing or testing, resulting in 4 to 6 month plus to deliver something for business people to play with.  So if different parts of an organization just naturally wait for information, will they not feel out of place if all of a sudden they have to figure out a solution in less than 30 days?  I would say they would have lots of trouble.  Most Agile Organization would not sweat a 30 day proposal, but I have seen many waterfall organizations in my 20 years of project management not bid work just because they could not get it together in 30 days.

In an Agile (Scrum) environment, Business people or Product Owners (POs) are decomposing Features and Epics into small components or User Stories pretty much on a weekly basis.  In a Waterfall environment, requirements or design writing could take weeks or months.  In proposal writing, every organization I have seen decomposes the requirements into manageable pieces.  So if the business people learn how to do this regularly as in an Agile organization, would they not be better trained and experienced than a Waterfall one?

In an Agile Team environment and now the new DevOps models people of all different technical background get used to working with each other day in and day out.  In a Waterfall environment they only get together at exchange or review gates or milestones.  To tell the truth, I always cheated and made sure my different technical groups always talked even in my 1 year plus waterfall projects J.  So if a proposal team needs to address design, development, test and logistical deployment, what group would take less time for Forming, Storming, Norming and Performing (Bruce Tuckman in 1965)?  Remember time is short.

Now comes the tricky part that all organizations have trouble with and that is estimating price and schedule.  I have sat in countless Waterfall proposal rooms where we had to send out to various managers for estimates and they would ask about the design scope, time, experience needed, etc…  However, in the Agile world the teams are already fixed in size and weekly rate is set.  It is actually the easiest math formula ever.  So in Agile, we already know our cost per iteration.  The only question we have left to ask is, how many iterations?  Earlier, I mentioned that the Agile Business teams and the Agile Dev (DevOps) Teams are highly trained in decomposing and even better trained at looking at stuff on the shelf and figuring out how to size it to new work.  Again they do it all the time.  Practice makes perfect. Right? If the proposed effort  is not something totally out of the current business product portfolio, then it should relatively easy for an Agile Team, in conjunction with a suite of POs, to figure out the number and relative size of features of parts needed to fulfill the contract.

Decompose the proposal in Agile
Decompose the proposal in Agile

Then based on the velocity that all Agile teams measure themselves against (would it not be great if waterfall teams measured their outputs, aka benchmarks, hhmmm?), it is relatively easy to determine the number of iterations.  If a team’s velocity is 2 Features per iteration and they decomposed the effort into ten (10) Features then it would take five (5) iterations to complete the job.  I admit that this is a very simplified example, but the methodology holds for real world efforts.

Lastly, the icing on the cake or as I would compare it to my Mom’s green pistachio cake with some kind of special homemade green dream whip icing she makes for St. Patrick’s Day, which is so good.  If your organization wants to take two weeks and create a “Demo” product from existing products, which an Team (Agile or Waterfall) is used to creating slightly enhanced products and “Demo” every two weeks?  Can you guess?  That is Right, the Agile Team!  If you as an organization were able to not only provide a technical proposal, but also a working demo of limited sorts to a customer, who do you think a customer is more likely to go with?  The one who just produces paper or actually builds a mockup webpage or data system?  It just may be the Wow factor, one needs to beat out the composition.  Remember you are also demonstrating the iteration process to the customer and proving your basis for pricing your proposal as well as your skilled craft work.  Hey a two-for, cool J

I hope this post helps to generate discussions among your organizations and within our groups.

I’m working on some more Fixed Price Proposal and Contract post for future releases (Agile Iterations, LOL).  Hint, I love Spikes.  If you like this topic, please feel free to follow me or request a connection on LinkedIn.