I am thinking about version 0.2 and would like to include:

1. A handle
2. Room for A4 paper
3. 2 suggest a second layer (like a box of chocolates)

Grand plans!

I built the box because I was constantly trying to move all of these items to different meeting rooms (and because I like order in my life). Anyone else ever had the same issues or do I just need to get a ‘bag for life’ from M&S?

I left the box with my team at Nokia. If it’s still in use please comment or take a picture and share it.

1. Stop eating crisps – started 18/08/2011
2. Code every day for at least 30 minutes – started 24/08/2011

1. Get the team together every day
2. Spend an hour each week working on something as a team

Each day, for one minute, a randomly selected member of the team pitches an idea that we should all work on for an hour that Friday. A vote decides what we do (or it should, we seemed to slide towards a particular idea this week).

This week we spent the hour looking at how puppet works by studying a module for one of our services.

I’m looking forward to seeing how this develops over the next few weeks, I’m certainly going to learn a great deal.

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.

I’m using this as a learning exercise so I’ll continue with it, but some feedback would help me test my ideas and learn if anyone is interested enough to take a look at the code. I’ve focused on HTML5 local storage when building this page so that your stories are available next time you visit. Next I’ll make sure stories display in the order they were added when you return and clear the editable content when you begin to type.

Browser local storage has a lot of potential for prototyping. Having a simple way to persist data that overcomes cookie size limitations means you can try some relatively complex interactions using just HTML5 and javascript before launching into a fully fledged application. Smashing Magazine has a nice primer for local storage.

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.

6 Weeks after I first suggested the idea of creating a local Scrum user group we held first meeting.  People quickly joined a hastily created group on LinkedIn and started spreading the word.  The first person to join the group was Nigel Baker, a Bristol based Certified Scrum Trainer, who kindly offered to sponsor the first meeting and present with another local CST, Paul Goddard.

The turnout for the meeting was good, about 19 people.  This was impressive considering how difficult it was to find the lecture theatre at the University campus!  Nigel and Paul presented “15 tips to do good Scrum (and more importantly, build better products!)“, which was both informative and entertaining.  This gave everyone a lot to talk about when we moved to the student bar on campus, thankfully the unexpected Mexican night had pretty much finished by the time we arrived.

Everyone at the meeting was clearly enthusiastic about Scrum and Agile development, many face similar challenges.  My hope is that members of the group will be able to support each other to use Scrum successfully.

There has been some discussion in the LinkedIn group since the meeting including ideas for a second meeting.  I’ve included these and some of my own below:

• Scrum for distributed teams
• Software to support Scrum (can they be better than a board and post-its?)
• Turning your clients into Product Owners
• Scrum or Lean?
• Starting Scrum in a Waterfall environment

Thanks to everyone who attended the first meeting and made it a successful event.  I’d welcome suggestions for speakers, venues and sponsors.  Help with arranging meetings would also be very much appreciated.  Check back here or the LinkedIn group for details of the next meeting, looking forward to seeing you all there.