Many versioning and branching strategies are available. I prefer a simple approach: mainline development using GitVersion for automatic Semantic Versioning.
Continue reading Mainline branching strategy using GitVersion(5 min read)
Category: Project Management
Waterfall does not exist(10 min read)
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 (old link) 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.
Scaling agile – a look at SAFe(10 min read)
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(10 min read)Estimation worksheet(3 min read)
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:
