Entrepreneurs: Saving The Odd Million

February 27, 2010 at 3:22 pm 1 comment

OK, a disclaimer: I’m a geek. I have learned to do some business-speak and googled the odd idea about how it’s done, but my instincts are questionable: I haven’t made my first million and therefore I’m not really qualified to give advice to those who have.

My specialty is to deliver software applications. Very often, situations present themselves like this:

  • We are a team of developers. We have finite capacity and Conway’s Law rules us with an iron fist. By  Seth Godin’s   “hunters and farmers” analogy, we are farmers: We try to leave no stone unturned to make sure we build the right thing at the right time. In the face of (inevitably) changing requirements and (inevitable) learning-as-you-go about how the system should be implemented, we do our best to manage technical debt. It’s in our nature to strive for certainty, but we have a hard time getting it.
  • We build applications for hunters: What we produce is a means to an end, to exploit a market opportunity, satisfy demand, help run the business (… a hunting tool of the trade …) more effectively.  The hunter needs commitment: When is it going to be done? How much will it cost?

The hunter’s need for commitment and the farmer’s difficulty to give it in the face of (inevitable) change are a culture clash which dominates our industry. Untold millions are spent every day on experiments which prove over and over again that preventing (inevitable) change through waterfall project management and avoiding (inevitable) learning-as-you-go during project development is not the answer: It has a tendency to result in inflexible, expensive to build and dull end products. You can fairly hear the hunter’s howl of frustration:

“It’s a thinking machine, people! It’s the marvel of the age, one of the cleverest things ever! Why is it so #!!@$!! hard to make it do something smart……!”

The answer to this is a farmer’s answer which makes him howl louder still:

Building non-trivial software requires an incompletely understood balancing act between a complex set of trade-offs involving social interactions, technological factors and resource constraints. Working smarter beats working harder every time. Debate over what is meant by “smarter” is ongoing.

The current fashion for Agile and Lean delivery approaches looks promising and I remain cautiously optimistic that we’ll figure it out in the next 50 to 100 years.

In the meantime, in an extreme case of semantic diffusion, let’s see if we can hijack the concept of a balance sheet to identify a set of mutual commitments between entrepreneur-hunters and farmer-developers which, when in balance and taken with a grain of salt, might help to increase the chances of success:

Hunter-Entrepreneur Farmer-Developers
The team will not miss deadlines, but scope of what is delivered for the deadline is up to the development team. We will not miss deadlines. we will do frequent releases.
I will ensure that features are clearly prioritized. We will deliver the highest priority features first.
I will do my utmost to ensure that requirements are as clear and simple as possible. I will assist the team by minimizing scope. We will minimize cost/effort by adhering to the YAGNI principle as much as possible.
I will ensure that the team has direct contact with end users to the greatest extent possible. We will communicate clearly and skillfully, assisting management in reconciling conflicting user opinions, priorities and requirements and limiting scope.
I will not override technical decisions without clearly understanding the consequences in terms of technical debt. We make all technical decisions with business priorities and the quality of the end user experience as the most important criteria.
I will support the development team in their efforts to adhere to the principles stated in the Agile Manifesto. We will adhere to the principles stated in the Agile Manifesto.

 

It’s far from ideal, but maybe it could save the odd million?  Anything which results in less chaos and more predictability would be good …   Spoken like a true farmer?

Entry filed under: Agile Project Management, People, Software Development.

Software Craftsmanship: Coding Under The Influence Mindmap: How Deadlines Influence Technical Debt

1 Comment Add your own

  • 1. gualetar  |  March 21, 2010 at 7:10 pm

    The subject is fully clear but why does the text lack clarity? But in general your blog is great.

    Reply

Leave a comment

Trackback this post  |  Subscribe to the comments via RSS Feed


Twitter

   @robertreppel