How to Develop Software – And Why Most Organisations Can’t

How to Develop Software – And Why Most Organisations Can’t

There’s a simple recipe for developing cool, awesome, high quality, cost-effective and just plain sexy software. Most developers know this recipe. Most organisations do not.

How To

Get a (small) bunch of people who enjoy working together, who choose to work together, who choose what they’re working on and the scope of that work, who choose their own tools (if any) and equipment, who love what they do (and why they do it / who they do it for), and who have the autonomy to figure out how they can work best together, in the longer term. Offer them them some difficult (but not impossible) challenges and provide them with the wherewithal* to get on with it. Invite them to deliver working stuff (into production) frequently, and make sure the rest of your organisation knows that everyone benefits from immediate and meaningful feedback each time they do that.

(*By wherewithal I mean information, money, connections, someplace to work, and support).

Why Most Organisations Can’t

Most organisations cannot do this. They cannot attract the kind of people who can and want to work this way. Even if they could, they cannot trust these people to just get on with it. Even when seeing demonstrable progress every week or two. They cannot tolerate the absence of any “management” roles, whether this be overt (e.g. line managers, project managers), or covert (Product Owners, Scrum Masters, et al.). They cannot tolerate people “doing stuff” that they don’t understand, in ways they don’t understand. They cannot reliably give immediate and meaningful feedback. Above all, they cannot tolerate people having fun. After all, work is a serious matter, and results count for much less than how they’re arrived at.

Bonus Tip 1 – What To Do When Your Organisation Can’t

Make your organisation one that can. One that can attract the kind of people who can and want to work this way. One that can trust people to just get on with it. One that can tolerate the absence of any “management” roles – rejoice, even. One that can tolerate people “doing stuff” that they don’t understand, in ways they don’t understand. One that can reliably give immediate and meaningful feedback. Above all, one that can tolerate people having fun. After all, work is a serious matter, and results count for much more than how they’re arrived at.

Bonus Tip 2 – How To Scale

If you have more than one piece of software on which you want to see progress at the same time, get two, three, or a hundred more (small) bunches of people. Ensure they have the wherewithal (including a common purpose). And let them figure it out as they go. Most organisations can’t do this, either.

– Bob

2 comments
  1. Bob

    Spot on again. This must surely be common sense (which of course isn’t that common). It frustrates me that this isn’t obvious to everyone.

    A big problem in spreading this message is that clients quite often don’t get it and want to put in the layers of management etc. that we are trying not to.

    And don’t get me started on the general lack of understanding about Agile (c.f. pretty much most of your grumbles re: Agile “management”), they just don’t get it!

    Sigh!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: