Archive for November, 2012

Are you an intelligent fool?

Agile & Lean | Posted by Doc
Nov 20 2012

Any intelligent fool can make things bigger and more complex… It takes a touch of genius – and a lot of courage to move in the opposite direction.   ~Albert Einstein

In the Agile community, there are many values and principles that relate to this. One of the twelve principles that comes from the authors of A Manifesto for Agile Software Development (a.k.a. The Agile Manifesto), is this:

 Simplicity–the art of maximizing the amount of work not done–is essential.

When I’m facilitating workshops about Agile and this comes up, the first place people go is this: “So if I understand this correctly, the less I do the better, right? So doing nothing is perfect, right?!?”

After everyone has a good laugh, we get down to really trying to understand this. Is it profound or simplistic? Is it meaningful or just noise? What the heck did those seventeen guys mean by this?

I had an interesting discussion with someone just recently. His argument was that the word “maximizing” should be “optimizing.” I can’t argue with that. I wasn’t there and I don’t know what the authors were thinking, but clearly “maximizing the amount of work not done” could readily be interpreted to mean zero.

wonderingLet’s consider what they might have been thinking and what that implies for the members of a project team. We have to begin with the context that a certain amount of the Manifesto’s authors’ drivers were reactions to the classic/traditional Waterfall approach in which as much work as possible is done up front: requirements, system design, database design, visual design, detailed functional design, test plans, project plan and Gantt charts…

I’ve talked with groups around the world about this. When I ask them how much time they spend before writing a single line of code – doing all the up front stuff – I’ve gotten answers that range from 25% of the total time to more than 75% of the total time! Wow. That says that in one of those organizations a two year project might not see a single line of code written from somewhere between six and eighteen months! Think about the investment, and how it plays into the return on investment (ROI).

Put it in dollars. If a project is estimated to cost $2M, that would mean that somewhere between $500K and $1.5M would be spent before there was anything to actually work with or experience. No code, nothing functional, no idea if we’re on track or not.

A typical agile team writes and works on stories that address the work – the functionality and features – in vertical slices. As a result, if we consider the underlying database, those teams only add structure to the database – tables and columns and indexes and such – that are sufficient to support the current work item. Those teams also only do sufficient visual design – page/form/screen layout, widgets, details – as is sufficient to support the current work item. Those teams also write only enough documentation to satisfy the real needs of the users, operations groups, and others, rather than everything they can possibly think of. And they only add enough documentation to reflect the work they’ve actually done.

What this leads to is another of the twelve principles:

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. 

So now we have an approach that emphasizes simplicity delivering working software on a regular basis. Let’s compare this to the numbers I played with above. A two year project leads to working software that the stakeholders and users can experience in weeks, rather than six to eighteen months. It also means that that working software has been produced for less that $250K – half the cost that would have been spent before writing a single line of code, according to various sources.

I am not calling advocates of Waterfall or other approaches fools. There are many outstanding examples of Waterfall success. I am saying that perhaps we should consider whether there’s a way that might be more effective. I am saying that Einstein and the authors of The Agile Manifesto might just have had something.

Simplicity, genius, courage… good words.

%d bloggers like this: