Klaus pointed me at this
interesting post by Stevey Yegge on Agile Programming. Stevey laudes Google's, startups' and open source projects' approach to "good agile" engineering and, I think, this resonates well how db4objects operates.
I would like to comment on two items with respect to how we do things at db4objects:
Time-driven vs. Date-driven
I like his distinction between time-driven and date-driven. At db4objects we really are explicit and open to an extent like few other companies. But we have one golden rule:
Don't announce dates.
Dates are exactly what stiffles innovation and agility. You cannot predict when you have a smart idea. Or find a nasty bug. Impossible.
On a production management level, we exclusively work with an order of priorities.
Yes, engineers set themselves target dates internally, but noone locks these dates and makes a religion out of them. Noone is punished for missing a date, and no customer is disappointed. What? No customer disappointment? No, because we do not preannounce and hence don't raise expectations. Customers may be disappointed that we do not deliver what they want, but that's something else, attributable to the scarcity of resources.
Usually the biggest problems in our industry arise from promising upfront and not delivering in time. We cut this out with our golden rule and thus are not
date-driven.
Of course, software production has to converge at certain points with customer or marketing relevant dates. So what we do is we split our production plan (which is exactly as Stevey writes, simply a stack of work - represented in
Jira - without dates!) from the marketing communication (MarCom) plan, which has dates. And then marketing gets out of the way and leaves it up to the creativity of the engineers to optimize the output against the jointly prioritized work stack with the marketing dates.
So we do
not say:
- "On September 15 we're going to release B-Trees on field indeces"
We do say:
- We will have a release on or around 9/15 with the newest features,
- We work on "B-Trees on field indeces" with priority #1
- If these things match and the software has the required quality by then - fine. If not, we'll find some other smart way, make a beta, or drop the release, if the finished software is not appealing enough or the quality sucks.
It's a management by scope, not by dates.
We do run these convergence dates in a monthly rythm, so we work in manageable units, get an honest assessment of our progress in a timely manner and can thus constantly assess our productivity (productivity = output / time). So we are
time-driven.
In the last two years we have missed only 2 monthly releases.
I think that's an outstanding result for a company that doesn't set dates.
How can we do that? Well, not only do we win with "good" agility to incorporate learning and feedback to achieve "smarter" results, but we also save a lot of cost: Instead of distracting engineering with overhead (estimates, extensive specs, project management tools, time sheets, and dealing with or even making them managers), we simply ask them to code good software in a focussed and productive manner. Management overhead consumates up to 50% of an engineer's time in a typical conventional company, so, by cutting it out, our basic productivity is already 100% higher than theirs.
Pair Programming Brings Quality and Staffing Flexibility
I cannot speak about my personal experiences with pair programming because I am not a programmer.
I can only speak about my observation: At db4objects, pair programming is highly effectful in building high-quality software which is much less buggy and more complete upon release than with conventional coding. It is quality invested upfront by double-staffing while saving big on bug searching and fixing cost. A rule of thumb of TQM is that fixing a bug after a release costs 10x more than avoiding it. Pair programming is exactly about that.
Pair programming also helps to spread knowledge in a company. Knowledge dissimination is very important when optimizing production, because, rather than just one guy being able to work on a certain module, we can shift people more easily from one part of the project to the other and ramp up our staff much faster - our engineering team has grown 100% over the last 6 months and I cannot see any signs of distress or lacking productivity. Not surprisingly, lifting staffing constraints optimizes the output of our engineering organization.
Stevey writes he hasn't seen pair programming working.
I can say: At db4objects, we do extensive pair programming (virtually, with Skype and VNC - across continents) and it works very well.