Three main measurable ingredients of a healthy development team/environment  are:

1. speed: The rate at which we get things done.  Or a better term would be pace.  Are things moving so slowly that no progress is being made?  Are we operating at breakneck speed, or with reckless abandon?  Are things moving at a manageable pace where we can think, design, re-think, and execute?  Can we turn if we need to? or stop when necessary? How often does our speed fluctuate?
2. velocity: (veloci-raptor):  I have been using this term with account managers to describe how quickly we can complete projects, and every time I do my college Laura thinks I am talking about dinosaurs.  Velocity is a measure of speed in a direction.  It can also be explained as the distance traveled over time.  You may remember from physics that a car moving 100km/h forward for 10 minutes, and then 100km/h backwards for 10 minutes has an average velocity of  0km/h.  Why? Well, while the car maintained a speed of 100km/h the the entire time, in the end it didn’t go anywhere.  Adding direction to the mix begs the following questions: which direction are we heading? Positive? Negative? Towards a greater goal? Short term? Long Term?   Are we moving in a direction at all?  Does the direction change so often we are actually going in circles, or nowhere at all?
3. mass:  this is the long shot of the analogy, but  lets make mass represent the team’s attitudes.  A team which is positive has more mass, while a team which is deflated has less mass.  Contributors to mass are simple:  Positivity, Support, Teamwork, Collaboration, Leadership, Accountability, and more.

momentum = velocity * mass

Momentum is all about velocity and mass, and remember that velocity is your speed in a direction. To maintain speed and course through a hostile collision, the more momentum you have the better.   A team with momentum can easily bump small challenges out of the way, and can maintain speed and course during a collision with a larger issue.  Conversely, a team with little momentum can find the even smallest  collisions challenging.

Speed, Direction, Mass and Momentum. I am going to re-focus on gaining momentum using throttled speed, by gaining mass and most importantly by maintaining a net positive direction.  Remember that friction reduces speed, as do turning, and collisions.  If you want speed, you need balance the straightest path with the least resistance, while avoiding the catastrophic collisions.   Oh, and once you are rolling with velocity and mass, inertia will keep you moving.  Note: the speed and direction need not reflect soulless productivity.  You control the speed and the direction, and you can direct the ship anywhere you want.  It is up to the leaders and the team to balance these components.

Next I will turn my focus to kinetic energy, potential energy, and gravity.

What are your thoughts?

My favorite part of his post is the end where Peter states,

“Oh! And to all those programmers that I antagonized by asking “how hard can it be” when some business pressure meant a 90 degree turn in code – I apologize. I now know software happens at the level of details not concepts.”

I have worked on a few projects with Peter, and he should rest assured that he is not the only one to have suggested a 90 degree turn in code. Also, Peter should know that his revelation will offer coders insight on how our non-coding coworkers view software development. I now know to simply remind my requirement suppliers that the details are not as flexible as the concepts.

However; The point of Peter’s post is a little broader than the coder/business dynamic. Peter has shared some new found respect, and I feel that I have had an experience in which I can do the same. For the past few days I have been dedicated full time on web app QA and managing our bug system. It has been a race to the finish line, and the other developers are working very hard to deliver top quality which I must somehow measure. I realize how challenging it is to be the QA gatekeeper for a team of developers. Every feature and change requires me to race to complete a number of feature and regression tests. [And don't forget about cross browser testing.] This task takes great patience, attention span and a tedious amount of concentration. Furthermore, it doesn’t take very long to realize that programmers will loose their appreciation. It starts off warm and fuzzy as you save their behinds, but after sending a bug back for the fourth time the programmers no longer feel like sharing the love.

So, in the spirit of Peter’s post… To all those QA tester’s to whom I have passed incomplete features or have forced to regression test immediately before a deadline – I apologize. I now know that the assurance of quality stems from meticulous attention to detail and a rigourous amount of searching, testing, and reporting. You have saved my butt on more than one occasion, and the nature of software QA means that only you and I will every know about the bugs we killed immediately before release.