Devops for Growth

Agile version control using Git is simple. A developer branches the code to work on a User Story. Git makes it easy to merge the branch back into the trunk. A simple example is shown in the following diagram where all User Story branches are merged back into the trunk by the end of each sprint.

However, generally you need control of what features are delivered to "production". This is often accomplished by having dual streams - an on-going "development" stream (or branch) and a separate "delivery" stream (trunk) allowing control over when features are delivered.

This is very different from traditional version control where branches are eventually discarded (after possibly having been merged back into the trunk) - instead you have two on-going streams. This approach is only possible with a version control system such as Git where a version (ie, a node in the diagrams) can have two parents - in the diagrams this is any node with two outgoing arrows.

For a large project with multiple teams I have even seen the suggestion of multiple on-going "development" branches (eg: see Version Control for Multiple Agile Teams). I have not tried this but I have reservations because code merges between the teams would occur irregularly and might easily be forgotten (remember the rule of merge early and often). The two teams might create conflicting changes which are not discovered until the conflicting code is merged from the trunk into the other teams stream.

Craig Larman once joked that the waterfall process has strong antibodies that reject iterative processes by warping them into some form of waterfall. RUP has been a common victim of these antibodies, seeing its phases turn into some variant of the analysis-design-build-test conveyor.

(...)
The plan is a tool to figure out what should fit in the FivePoundBag. If your plan's not constantly changing, you are very unlikely to be doing adaptive planning, and hence aren't agile.

Feature lists have another problem - you easily lose sight of the context that makes the feature valuable.

This is a reason why Alistair Cockburn is a proponent of use cases, because they concentrate on a narrative of how someone uses a system.

Marc NcNeil also talks about this in terms of Customer Journeys. The weakness of use cases in planning is that they don't give you clear units to tick off so you can assess progress and project consequences of choices into the future.

That makes them less useful as a planning tool, but that doesn't negate their value as tool for imagining what a good outcome would be.

Some simple ideas:

• CRUD (Create, Read, Update, Delete) boundaries
• Acceptance criteria – often the acceptance criteria on the back of the Story Card will give a good hint.
• Happy Path – many stories have exceptional conditions consider splitting them out
• Simple versions of an algorithm. With a complex algorithm and complex UI it might worthwhile to do a simple version of either first and then fill in the detail in the next story. Sometime this can come from making some elements constants instead of looking them up or calculating them