Fixed Bids - The Bane of Agile?

Kaushal Karnad, a PMP and Certified Scrum Master in the Certified ScrumMasters group I follow on LinkedIn, asked the group

Can fixed bid work for Agile?

A fixed bid is the bane of an agile team. Why?

Because your beloved team assumes most of the risk. Fixed bids throw up a giant red flag of distrust -- Not the kind of client relationships most of us are seeking.

It is hardly possible to be agile and still agree to a fixed bid project -- unless the bid is astronomically padded in your favor. But I'm guessing the kind of client seeking a fixed bid is not predisposed toward selecting high bidders, so that’s out.

Product owner requirements in an agile project are largely discovered and prioritized along the way. To commit to a fixed bid for an entire project would require you to pull a number out of thin air. The team would be asked to commit to a number that has no basis in estimable reality -- very stressful for everyone.

Don't despair Kaushal. It's a stretch, but following is one possible pseudo fixed bid scenario to consider:

Assumptions:

• Start with 1-month "trial" iteration zero
• Have, say, 4 developers at the princely sum of $100 per hour
• Iteration zero will be "fixed-bid" at $64K

After your iteration zero retrospective, your client will know exactly what's been produced because you’ve shown an impressive demo of the fledgling product. He now has a decision to make - scuttle the project or continue for another "fixed-bid" iteration. The client could continue to make the same series of "scuttle or continue" decisions following the end of the iteration.

The significant downside is that you're still assuming all the risk, since you could line up a rock-star team for this project, and then on the client's whim, have to blow up the team following iteration zero. But, assuming you can last beyond iteration zero, each iteration should bring a level of trust.

I have no legal expertise, but here are some practical contract addenda that might (or might not) help should you venture into the quagmire of fixed bids:

• Team will demo shippable software to Customer every 30 days at no additional charge
• Customer may replace any requirements that Team hasn’t yet started working on with one or more of equal total size (in the estimate of Team) at any time.
  
• Customer may request interim, mid-iteration releases at any time, and will be charged an agreed-upon time and materials cost.
• Should Customer’s business goals be satisfied early, Customer may terminate contract for N% of the remaining un-billed contracted amount.

More Information on Fixed Bids:

• Agile Consulting, Jeff Anderson - How to Make Agile Development Successful within a Fixed-Price Consulting Model
• The Software Simplest, Udi Dahan - Successfully Applying Agile to Fixed-Bid Projects
• Martin Fowler - Fixed Price
• Code Better, Greg Young - Agile: Fixed Price Bids

Self-Organization: Flocks, Schools & Colonies

One of the Twelve Principles of Agile Software expressed in the Agile Manifesto, calls for self-organizing teams:

The best architectures, requirements, and designs emerge from self-organizing teams.

Self-organization was recognized in 1955 by Farley and Clark as:

a system that changes its basic structure as a function of its experience and environment

Self-organizing systems are widely observed and recognized in physics, chemistry, mathematics, cybernetics, economics, and biology. The prospect of collective intelligence certainly is intriguing.

What are the characteristics of flock of startlings (above right), schools of fish (left) or a colony bees (below right), that might be relevant to how we form, feed and sustain self-organizing teams?

Birds and Fish
Schools of fish move like a single organism. Schooling reduces the risk of being eaten by a predator because the odds of individual detection are less. Fish, unlike migrating geese who form an aerodynamic vee, do not flock in a regular geometric shape.

Flocks of birds group into a geometric shape for the aerodynamic advantage, but otherwise birds group together obeying similar heuristics as fish. Both organisms perform complex tasks with simple individual behavior. Both groups react instantaneously to external events by spawning different invididual tasks to accomodate external stimuli. Further, small differences in individual behavior might influence the collective behavior of community.

Simulations to mimic flocks of birds use three simple rules:

1. Collision avoidance - don't crash into a flock-mate;
2. Velocity matching - move at the same speed as flock-mates;
3. Centering - strive to stay close to flock-mates.

These simple rules, inate behavior in birds and fish, might spawn a fruitful discussion during your next Retrospective.

Bees, Ants, and Wasps
Colonies of bees and ants perform community tasks by a distributed function that doesn't seem to require a central organizer. The two observed characteristics of interaction are:

• Hierarchical - one insect asssumes a dominant role and the other submissive
• Thropic - a community "decision" is made (e.g., ants produce more foragers when food is scarce)

Agile teams need to make community decisions. To be a good Agile teammate, it is important to develop an instinct for the signals of when to exercise dominance and and when to be submissive. You must be capable of both behaviors as events dictate.

A defining property of living systems is that they self-assemble against nature's tendency toward disorder, or entropy ~ Erwin Schrödinger

Many organisms have evolved sophisticated community behaviors. It is instructive to examine other self-organizing communities as we form, feed and sustain our Agile teams.

Want to Read More?

• James Brett has an excellent primer called Flock Theory Applied written in the context of Scrum
• Carnegie Mellon School of Computer Science has a Review of Literature on self-organization.

Scrum Lingua Sustainability

As a marathon finisher (Twin Cities 1998, 2000) and Scrum proponent, I don't know if Sprint or Jog is a more misleading description of what it is that we do week after week and month after month.

One is unsustainable; the other implies sandbagging. Most of us strive for the sweet spot of pacing and productivity; somewhere between extremes.

The Scrum community needs a term for the zone one slips into during a long run, say more than 10 kilometers, where you're not conscious of your respiration, you're not suffering chaffing, yet you are vaguely aware that your body is transporting you over the pavement like a well-oiled machine.

Scrum is a superior way to think about and organize projects. But the Sprint nomenclature is misappropriated. The universal appeal of Scrum is pace and productivity -- both humane and sustainable.

Many teams eschew using Sprint to describe what we do in favor of the steadfast Agile term Iteration.

I prefer iteration. It implies convergence toward mutually agreed upon goals.

Those of us who recall using iterative algorithms in Numerical Analysis will remember that convergence isn't a given, it's the goal. Convergence requires the right seed values, like the care and feeding of a Scrum team.

Extreme Interviewing - An Agile Aptitude Test?

How do you hire for an Agile team?

Does an Agile aptitude test exist? Does traditional interviewing work when it comes to finding people suitable for an Agile team?

Scrum proponent Gunther Verheyen, a member of Scrum Practitioners on LinkedIn, pinged our group about an article on hiring people to an Agile team.

In Hiring Software Developers: The Agile Aptitude Test, Richard Sheridan and Lisamarie Babik of Menlo Innovations explain to CIO Magazine how "Extreme Interviewing" helps hiring managers select Agile team members who posses the requisite Social Intelligence to apply Agile principles.

The gist of Extreme Inteviewing is that candidates are gathered and paired off to solve a problem.

Here's a distillation from the article of the 3 most important characteristics of Extreme Inteviewing:

1. The interviewers are not interested in the outcome of the problem solving;


2. The interviewers are looking for good "kindergarten skills"; and


3. The interviewers are seeking pair-partners who "make their partner look good"

#3 is intriguing because it gets to the heart of teamwork.

Take-Away Tips

If you're hiring to an Agile team, consider Social Intelligence as well as Technical Prowess.

If you're already part of an Agile team, think about ways in which you've made your teammates look good. A well-placed assist is as satisfying as an acrobatic slam dunk.

If you're part of a dysfunctional team, reviewing kindegarten skills might be revealing fodder for your next Retrospective.

Agile Asphyxiates Creativity?

What is your organizational attitude? Does it have a pulse for inspired ideas? Does your organization encourage pie-in-the-sky thinking?

or

Is your organization compelled to justify every shekel spent on product increments from the Backlog?

Reeju Srivastava, Senior Software Engineer at Nokia asked our Agile Alliance group:

Is there any space for Innovation and Creativity in Agile methodology?

Telefonica R&D Agile Coach, Gemma Hornos Cirera suggested a Creativity Backlog:

We have a "Creativity Backlog" during the whole iteration... when we finish the iteration sometimes we have what we call "creativity/innovation meetings"

The purpose of Gemma's creativity/innovation meeting is to evaluate the best ideas and move them into the Product Backlog.

Stacia Broderick and Lee Devin explore organizational innovation and creativity. In the blog post Is Agile Squashing Innovation? they ask

What can management do so that teams stay innovative?

I highly recommend that you read Is Agile Squashing Innovation? - particularly if you manage - or work in - an organization the suffocates right-brain thinking. Broderick and Devin give an actionable list of suggestions to help innovation and creativity bubble to the top by:

Seeking, Identifying, and Budgeting for Innovation.

Agile Ennui and Egyptian Pyramids

The oldest known Egyptian pyramid is the Pyramid of Djoser.

This rock-solid design has served its intended purpose since the third dynasty. That's roughly 4,620 years of service. Suffice it to say,

That's one lengthy dirt nap for the Product Owner Pharaoh Djoser

It seems the Pharaoh's Scrum team delivered the ever-elusive value in a mere 20 years -- which begs the question:

Who has built software that lasted more than 36 months?

Deftly tapping an ergonomic keyboard is not quite like moving heavy rocks. Is it still possible to equate quality with duration? Today we build beautiful things, then hire demolition experts to strategically place charges to blow them up.

I once spent 18 months on a product that was universally praised, promptly scuttled, and never used.

I’m not a whiner, but does anyone experience existential ennui when they think about how we’re spending our time?

Agile coach David Hussman pointed out that the Egyptians practiced Evolutionary Design (cf. Evolutionary Design - A Conversation with Martin Fowler) with improvements with each iteration. According to David:

"The first pyramids were merely burial mounds. The next version was the step pyramid (Djoser's tomb) and the next version the "bent" pyramid (a design in rock that they had to refactor during construction. These were all the forerunners to the Giza structures. It was a progression of small, simple structures which evolved based on the learning (and failures) from the last iteration."

Scrum Project Naming

In the Scrum Practitioners Group on LinkedIn, project manager David Koba asked members:

Do you use code names for your projects?

Well, yes. All of us love laugh-out-loud monikers. I still use the cloaking pseudonym Cleatus Spitznoggle when I peruse high school classmates on Classmates.com.

But for Scrum projects, I prefer meaningful names.

One of 10 critical unity factors in cross-functional teams is TEAM IDENTITY. (see my blog post 10 Critical Factors in Cross-Functional Teams).

A well-oiled Scrum team has:

• Common purpose;
• Pride in what the team stands for; and
• Pride in the incremental accomplishments of delivering a superior product.

Since Scrum teams are often comprised of members who initially identify with their functional organization (e.g., Information Technology, Operations, Quality Control, or Marketing), it's important that the Scrum TEAM IDENTITY evolve over a series of Sprints so that it becomes centered about the product.

I favor project names that promote TEAM IDENTITY centered on the product.

Let the product lead.

I am fortunate to be engaged with a smart group of people building a networking and collaboration product for law professors. We’re the Law School Exchange project.

Our project name is not as memorable as using Star Wars characters like Chewbacca or Biggs Darklighter. And, it is not as intoxicating as a mixed drink project name like The Wet Hen or The Nose Cooler.

On the contrary, our project name suggests a product-focused identity to rally around. It’s a name that doesn’t seem geeky to non-programmers. And, perhaps more importantly, our project name is self-explanatory to the organization footing the bill.

Some folks in the Scrum Practitioners group mentioned the naming of individual Sprints (e.g., after the month they happen to correspond to). Be careful not to lock the team into naming conventions that don’t fit when the team decides that 2-week Sprints are preferable to month-long Sprints.

Take-Away Tips:

• Give your Scrum Project a self-explanatory, product-focused name that the team can rally around and is easily recognized by the organization.
• Give your Sprints incremental numbers. Nothing conveys progress to the Stakeholders more succinctly than a trusty old integer.

MVP of your Agile Team

I engaged four Agile and Scrum discussion groups with the question:

Which person is more valuable to an Agile team?

One with SUPERIOR KNOWLEDGE of software systems and architecture
-- or --
One with AVERAGE KNOWLEDGE capable of admitting what he doesn't know

And, who would you rather work with?

Many in the Scrum Practitioners Group and Agile Alliance Group misunderstood the gist of my question. Probably because the question is "Bobtuse". Among the Scrum crowd, it sparked a somewhat embarrassing thread about Product Owner versus ScrumMaster. Not my intent. I blamed myself for misleading them, then offered further explanation that I'm entertaining a thesis that the sublimation of ego is a crucial ingredient to team success.

I coined the aphorism

"Humility is the WD-40 of teamwork"

I did get many thoughtful responses. Management consultant Steve McGee fed me:

"..a passion for knowing the truth, contrasted to a passion for being right..."

from something he noticed while reading about gender communication differences. He said,

“… men are stereotyped as always competing to be right. I was offended by that, and after thinking about it, it seemed this distinction had been missed. In both cases there will likely be an argument or at least debate. But the goals and therefore the results will be totally different.”

Steve agreed that to get an honest evaluation and transparency, team members need to subjugate their egos. He went on to say,

"If a person is willing to trade certainty (accept ambiguity) so they will not miss any potential information, he or she will get closer to understanding what's really going on and can respond more effectively.”

Thanks Steve.

My Agile mentor, David Hussman said,

“I feed on environments where people are proud to say they don't know. Some of the smartest people I know, know when to say they don't know, and when to shut up and listen.”

Thanks David.

Regarding who he'd like to work with, Agile coach Paul Ellarby said,

“...it all depends upon their personality. I have worked with individuals who freely admit they are "not experts", yet try to dominate all discussions around their area of responsibility. Similarly, I have worked with folks who clearly are highly valuable experts, yet listen carefully to the teams dialog, and respond in clear, concise, and respectful tones.”

Paul also reminded me of the aphorism “Two ears, one mouth - use them in proportion...”.

Thanks Paul.

Was it Socrates or Epictetus who said

"we have two ears and one mouth so we listen twice as much as we speak”?