My name is Will, I'm 30 years old, and I'm a Pivot. In my three year tenure here at Pivotal Labs, I've found that it may be easy to see the parts that make us successful consultants, but that forrest is hard to see for all the trees. Everything from breakfast to keybindings plays a part in making us one of the top software consultancies and the greatest place I have ever worked.

In any consulting job, a project truly fails when expectations are not clearly communicated. In Ruby, we have a great tool for communicating expectations about code. What if we applied that same tool to real life? The anchors at Pivotal Labs have a wealth of knowledge about what elements contribute to a smooth running project. I have my own ideas about what makes a project fun to work on. Below is a very short start to what I like to see about a project going in. This is not to say that a project that fails this spec is "bad", just that I feel a lot better when a project already has these things in place.

Though I am certain someone could do it, it is hard to dispute the connection between having choices and control over your daily work and overall job satisfaction. The people with more power to govern themselves will typically report that they are more satisfied with their jobs. This is why pairing can play a huge part both with picking who you work with and what you work on.

In response to some recent web browser related debates:
http://sachin.posterous.com/the-web-sucks
http://techcrunch.com/2010/04/30/joe-hewitt-web-development/
http://yehudakatz.com/2010/04/30/the-web-doesnt-suck-browsers-are-innovating/

The web has long since tried to help developers realize the [perhaps misguided] promise that you can write software once and run it anywhere without modification. This might have even seemed feasible when the only real consumer web-enabled device was a desktop or laptop PC with a fairly standard monitor resolution, keyboard, mouse - predictable. You could even bank on IE probably being the browser of choice at one point, like Netscape before it.

Back at the 'Labs we start off every morning with breakfast at 8:45, then at 9:05 someone rings the cowbell. The cowbell lets everyone know, "Hey we're doing stand-up, come if you want, carry on if you need to be doing something else."

I recently returned from a trip to Egypt with Pivotal's own Lara Owen. Like all good tourists, we went and saw the Pyramids of Giza. Like far fewer tourists, we also went to Saqqara to see the Step Pyramid and then on to Dashur, home of the Bent Pyramid and the Red Pyramid.

In the 3rd Dynasty, the Step Pyramid is constructed under the rule of Djoser. The pyramid has entered the market. By the 4th Dynasty, under the rule of Snofru, six steps are no longer enough, users want seven steps and smooth sides.

In an attempt to meet these new market demands, the Bent Pyramid construction begins. Half way through, they realize they made a mistake, and adapt their plan accordingly by changing the angle down from 54° to 45°. The next attempt, still within Snofru's lifetime, becomes the gold standard of pyramids and is known as the Red Pyramid. With it's consistent sloping smooth sides and added height, this pyramid was fit for any king.

What I thought about, as you might have guessed by now, was the methodology used to construct each of these pyramids. In the case of the Step Pyramid form the 3rd Dynasty, it would be easy to see a king proclaim, "I want this kind of pyramid and I want it ready by the time I die." And he'll get something twenty years later that resembles what he wanted twenty years ago.

Snofru had a different plan. He was going to shake up the way people think about royal tombs. He was going to do something no one else had done. This man of foresight said to his people, "We will release early, and we will release often. We will have meetings along the way to reflect on how we have progressed, and we will then plan ahead only as far as is practical, adjusting as we go. Most importantly, we will trust each other such that mistakes can be made without causing great harm to the project." It was with this spirit that Snofru began work on the Bent Pyramid.

He didn't know what he was doing, there was no model to copy, no patterns to solve this problem. So he guessed 54°. And they built, and they talked and said "Hey Snofru, this looks great, but it won't be stable if we continue at this angle." To which Snofru probably replied, "I will trust your expertise here, can we make the angle less steep and see how that works out?" So 45° it was.

When the finished, they stood back and looked at the work they had done. It was taller, and it did have smooth sides, but it wasn't quite right. Snofru, being a wise king, knew that this was a great success.

1. A taller pyramid could indeed be built.
2. 45° was a sustainable angle
3. He was still drawing breath and now had the knowledge to fully realize his goal.

Snofru still had plenty of time on his hands, and because he released early instead of letting construction drag on, he had new insight from the retrospective that he wouldn't possess otherwise. So he built the Red Pyramid with complete success.

Snofru was, in my opinion, the first adopter of Agile principles. His "employees" trusted him enough to be able to push back when the plan needed revising. He trusted them right back not to yank his chain about things being too steep. He made his mistakes up front, which taught him lessons about his domain, and it enabled him to be successful in the long run.

No matter what point scale you use to estimate stories, and if you call them "points", "gummi bears", or "t-shirts", people always want to know what they mean. The problem is that the keepers of the points don't know how to relate to the users of the points.