Workshop in a box – 0.1

by Andrew on June 7, 2012

With only 3 of us in the Bristol Nokia office during Christmas 2010 I took the opportunity to create myself a ScrumMaster box:

Share photos on twitter with Twitpic

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.

30 days

by Andrew on August 23, 2011

This seems like an interesting life hack from Matt Cutts so I’m going to give it a go and try something new for 30 days. Actually, stop and start something. Perhaps not as exciting as some of Matt’s challenges but I want to do these two things:

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

One minute idea

by Andrew on July 25, 2011

I’ve just joined University of York as the Head of Web Services. Last week we started a simple practice which aims to do two things:

  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.

New Theme

by Andrew on May 15, 2011

The legibility of the theme I was using wasn’t great so I’ve switched to using the “Modernist” theme.

Agile focus

by Andrew on May 13, 2011

I’ve come to realise why I am interested in agile software development and project management. It’s because I think organisations need to change and I have a vision of what they might look like in the future. This morning I’ve been reading about and listening to presentations on the purpos/ed site, a new movement started by Andy Stewart and Doug Belshaw. In a short space of time they’ve captured the imagination of people that share a passion for defining, changing and challenging what education is. It’s inspiring to see this and the same passion exists in the agile community, but what are we focussing that energy on?

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.


Quick user stories and HTML5 storage

by Andrew on May 4, 2011

After reading Mike Cohn’s post “Advantages of the ‘as a’, ‘I want’ user story template” I started thinking about the simplest and quickest way to create and capture stories. I’ve been using Evernote a lot recently and it’s a good place to keep a simple backlog that you can access anywhere. To have any advantage over using Excel, Evernote or Greenhopper directly the authoring step has to be very simple. The screen capture below shows how stories are displayed and you can try the live demo.

Quick user story creation in a browser

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.

Little’s Law

by Andrew on September 17, 2010

Through anecdotes and observation I know that limiting Work in Progress (WIP) is a good way for teams to focus on delivering stories and  ensure that bottlenecks don’t occur.  However, until recently I clearly explain why until I came across Little’s Law which states:

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.

BSUG Poster

by Andrew on March 17, 2010

Bath Scrum User Group poster

Done is really done

by Andrew on February 14, 2010

It’s so reassuring to be able to experience the benefits of practices that you read about.  On our last sprint we deployed our completed stories into the live application as they were completed meaning done is really done.

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.

Bath User Group kick-off meeting

by Andrew on January 14, 2010

This post is long over due but hopefully it will be the impetus for organising regular meetings of the group in 2010.

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.