It’s easy to get side-tracked where that passion is directed at the agile method you use or champion. I’ve realised I don’t care about Scrum, what I do care about is helping teams find the best way to build great products and services. More than that, being part of building them. Not just managing the process. A big part of this is making sure the wider organisation works in a way that supports their teams. This seems obvious but my general observation is that while most organisations talk about this rarely do they care about it.

I’ve used the ‘experience pain to force change’ approach to get new ideas in place but this clearly isn’t as powerful as getting a whole organisation buzzing about what it does and how it can do it better. It’s hugely important that leaders at every level of an organisation create that buzz. Just adopting Scrum or XP doesn’t achieve this and similarly a community focused on those methods won’t change organisations. Still no silver bullets then.

Looking at the success of ‘purpose/ed’ has made me understand that we need to ask why and how we are building products or organisations. We can then ask how it we can do it differently or better. That’s something everyone can get involved in and be passionate about.

The long-term average number of customers in a stable system WIP is equal to the long-term average arrival rate, TH (Throughput), multiplied by the long-term average time a customer spends in the system, CT (Cycle-Time); or WIP = TH * CT.

Little’s law applies to all systems.  An example using Scrum might look like this:

1. 2 week sprint (10 working days)
2. 10 stories in the sprint

Assuming all stories are delivered in the sprint TH is calculated as stories delivered / time.  In this case 10 / 10 = 1.

If we’ve been imposing a WIP limit of 2 stories then we can calculate Cycle-Time: 2 / 1 = 2

In this example a story is in the system for 2 days. If we increase WIP then Cycle-Time also increases eg. 4 / 1 = 4.  Why should we care about this?  If our WIP limit is too high we will end up delivering most of our stories on the last day or two of the sprint.  We are then looking at big bang integration and other activities the Agile attempts to eliminate.

One possible reason for a burndown like the one above is that there was too much Work In Progress.  If 6 stories were in progress for a large part  of the sprint then CT becomes 6 days.  To achieve a burndown where stories are ‘done’ at regular intervals through the sprint we could take the following actions.  Limit WIP to a point where CT stablises around 2 or 3 days or improve Throughput by changing the process.

Scrum has two ceremonies where we can improve Throughput; the daily standup and retrospectives.  The standup is used to maximise throughput in the sprint and the retrospective for identifying process improvements to work on in the next sprint.

Until recently I thought that limiting tasks in progress was the throttle for WIP.  The trouble is that it’s still possible to  have a task in progress for almost every story in the sprint.  The correct way of limiting WIP is to use a meaningful unit of production. In Scrum’s case this is a story.

Pushing work into the live app before you can say it’s done means that deployment has to become part of the story.  We can’t defer the work to a ‘deployment’ story or push it outside of the sprint.  This gives us a better understanding of our velocity because stories encompass all of the associated work.

Deploying in a big bang can surface issues that nobody anticipated.  If the problem is the result of work undertaken at the beginning of the sprint it takes a little time to get back up to speed, but this isn’t a problem if you’re releasing the work as you go. Small incremental deployments mean that we don’t get that slightly anxious feeling as release day approaches.

Why doesn’t deploying to a test environment work just as well?  Until this sprint that’s exactly what we did, but with this experience it feels like a compromise. For one thing, knowing that your work is going public immediately encourages communication between developers and clients which focuses attention on the details of a story.

For me there is a lot more to learn here so I’m going to look into continuous deployment to see what techniques can be used to support it.