On speaking well

A couple days ago I came across a great post on Speaking Well.

The speaker is Professor Patrick Winston of the Massachusetts Institute of Technology. Professor Winston goes some very effective techniques on how to give a talk. For example he explains why he does not recommend opening with a joke. He explains how to make use of lighting, space, props, and why the best time to give a presentation is at 10:30am.

It is a very clever presentation and he demonstrates many of his techniques by example on himself.

Once again this talk reminds us that the quality of our ideas is often less important than how we deliver them.

Artful Making Part II – Prerequisite conditions for Artful Making

Continuing with my review of Artful Making, here are some things to consider when deciding whether an more industrial approach, or an artful one will better suit your needs.

I have attempted to make Rob Austin’s points (summarized) in block, with my own in clear text underneath.

Artful making (see previous post for defn) features rapid frequent iteration. This approach only makes sense when the cost of an iteration, is cheap compared to the benefits gained from the experience. If the cost of an iteration is high (as in integrated chip, or car manufacturing), you would be better off doing more upfront planning.

Here are two factors to consider in the cost of an iteration:

1. Reconfiguration Costs

Reconfiguration is doing something once, and then tweaking it ever so slightly to do something else. When you can do this cheaply you have a low reconfiguration cost. Car manufacturing doesn’t have a low reconfiguration cost. Reconfiguration of a car design would involve retooling, new equipment, and possibly changing the layout of a plant. Reconfiguration in software development can be relatively inexpensive. Theatre production arranges and rearranges the actions and interactions of the performers, also inexpensively. Hence, software development as well as other business activities can be, in this regard, more like rehearsal than like car making.

Rob is bang on with this point. It shouldn’t be any surprise that early on our industry gravitated towards industrial, or heavily planned waterfall like methods. When you program a computer with punch cards, and a run of the software takes an evening, you are naturally going to spend more time upfront getting things right.

Things are much different today. Just-in-time compilers, databases, Object Oriented design, continuous integration tools, automated regression tests have made the cost of reconfiguring software much cheaper than 40 years ago.

Agile software engineering practices (typified by XP) have low configuration costs.

2. Exploration costs

The second component of the cost of iteration is the cost of trying something that doesn’t work well enough to continue doing it. In an industrial setting, we might think of exploration costs as “scrap costs.” It’s expensive to throw away physical prototypes. When the cost of exploration is high, you want to avoid making too many throw aways. Similarly, a doctor must consider that iteration may have unacceptable impacts on patients. Software development, by contrast, routinely generates “bad” versions as a way to explore possibilities. These versions are not released and can be fixed as early as the next day. Here, too, software development is more like rehearsal than manufacturing; in theatre, there is not much lost when actors try something that doesn’t “work” because something different can be tried in the next rehearsal.

Rob quite rightly points out that agile (and software development in general) doesn’t suffer from the “scrap costs” described in car manufacturing. The scrap costs in software development are people’s time (which shouldn’t be ignored). Still the cost of exploring new designs, architectures, and patterns in software is relatively cheap, compared to the payoff that comes with a cleaner, more maintainable system that is less expensive to support.

Artful Making

Artful Making

Artful Making is a term Rob Austin coined in his book Artful Making – What Managers Need to Know About How Artists Work.

Rob describes Artful Making (paraphrased) as follows:

There is an increasingly important category of work – knowledge work – that you can best manage by not enforcing a detailed, in-advance set of objectives. Often in this kind of work, time spent planning what you want to do will be better spent actually doing. In appropriate – only in appropriate conditions – you can gain more value from experience that from up-front analysis.

Managers should look to collaborative artists rather than more traditional management models if they want to create economic value in this new century.

We call this artful making. “Artful”. And it applies well to the fields of product designs, software. New things that involve groups creating, thinking, talking, and collaborating.

This book looks promising and comes highly recommended.

Stay tuned as I am keen to sharing more great metaphors from this book, and how it relates to the knowledge work of software development.

Your best project

When introducing agile to companies, I am occasionally challenged to offer proof that agile methods are better.

That can be tough.

How can one prove anything as subjective, and emotional, as software development.

On time, on budget!

You have traditional measures like time, money, and how accurately we followed the original project plan.

But that is a false comparison because agile and non agile projects perceive value differently.

Agile projects are not all about time, money, and accuracy with which original plans are followed.

In fact, accurately following the original plan violates one of agile’s core principles – that the plan is going to change.

If the plan didn’t, change an agilist might very well ask – what went wrong?

Rather than prove or claim agile is better, I have found it more effective to get people talking about projects that were really successful.

Common response are:

* a tight team
* good communication channels
* rapid decision making
* strong collaboration
* stakeholder involvement
* passion / hard work
* respect for co-workers
* feeling like you were making a difference
* urgency
* a real feeling of commitment
* pride of work
* fun

None of these characteristics are unique to any method. They are universal.

The reason I question traditional methods of project success is because I have never had someone come up to me and say our project was on time and on budget and then double pump their fists in the air.

Usually it is more along the lines of: “We chucked out the original plan, sat down with the customer, and focused on delivering exactly what they wanted with really fast turn around time between them and us. It was beautiful.”

And yet when you ask them why they aren’t doing that on their current project they shrug their shoulders?

We all know a software methodology doesn’t make or break a project. People do.

The unmistakable trait I see in successful projects that people loved to work on, is that they contain many principles, practices, and characteristics espoused by agile methods.

I can’t prove agile is the best way to develop software (that’s not possible). It’s just that when people tell me about their ideal project, it contains many agile elements.