Waterfall does not exist

I often hear people talk about "waterfall" process software development. But a waterfall process doesn't really exist.

Well, there are software projects that meet the description of waterfall — the post-publication name give to the project structure described in Walter Royce's 1970 paper as the wrong way to develop software.

But there aren't any published methodologies, processes, books, tutorials, courses, tools, or certifications for waterfall. Because it isn't really a thing you should do.

There are many specific methodologies or processes for software development that are iterative, agile, or product based (Scrum, Unified Process, eXtreme Programming (XP), Crystal, PRINCE2, etc).

But there are no such processes for waterfall. Take a look and search for yourself. If you do find one, let me know, because they don't appear to exist.

See, it looks like a waterfall. Gantt chart created in Project Libre.
Continue reading Waterfall does not exist

Scaling agile – a look at SAFe

One of the cornerstones of agile methods is delivering value – “working software over comprehensive documentation”, “production or it didn’t happen”.

To achieve this, when decomposing stories it is important to keep them independently valuable. Stories are only really finished when they are usable by the end customer.

To focus on progressing stories to completion, you want to minimise work in progress and you want to use a strict stack rank of work – 1st , 2nd, 3rd, etc. (Rather that general priority such as high/medium/low, where you have 20 high priority stories, none of them finished.)

However a stack rank doesn’t scale – if number 1 project in your stack rank has 100 week long tasks, you can’t assign 100 people to the project and have it done in 1 week.

The solution is the proven strategy of divide-and-conquer. If project number 1 can accommodate 20 people, then you assign it 20 people (and probably need to split that into 2 teams), then project 2 might have 10, project 3 has 15 people, and so on.

This means multiple agile teams, that need to co-ordinate, while keeping the overall organisation agile.

The Scaled Agile Framework for Enterprise (SAFe) has an approach that coordinates multiple teams towards common goals, leaves individual teams enough room to be agile, and manages planning horizons to preserve the ability to respond to change.

First we will take a look at the planning process for teams, and how SAFe scales to multiple teams using Program Increments, then we will look at plans vs roadmaps, and preserving team agility.

Continue reading Scaling agile – a look at SAFe

Estimation worksheet

This is a worksheet I have had for a while for calculating estimates using not a single value, but three values for best case, most likely case, and worse case. The values are combined using the PERT formula, to calculate a total estimate, statistical ranges, and an overall estimate including contingency.

Download the worksheet here:

Continue reading Estimation worksheet