Size (sort of) matters

Recently, I have been keeping a small set of metrics on the stories from my team. I started with simple dates so I could look at leadtimes - the time taken from when we start a story to when we deliver it.

With just these 2 dates you can do a lot! A lot of this came from looking over what was presented by Mattia Battiston at a meetup not so long ago. In particular, I was interested in his observation that there is very little correlation between story sizes and leadtime. This is something I have battled before so I was interested when my own data showed a very similar pattern:

Looking at this you could infer that a 2 point story might take as long as n 8 point story, which is hardly useful. What I missed for a while is the upper bounds across all the story sizes. We have a couple of anomalies at the top but the vast majority are within 10 days - which you should know is the length of our sprints.

That caught my interest. Although we cannot say with any sort of accuracy how long a 5 point story will take - in this example the longest was 26 days and the lowest was 4 days - we can say that 95% of 5 point stories can be delivered within 10 days or less. You can repeat a similar statement for story sizes 8 and below.

So maybe we should revise what we are expecting from our estimation by the team. What we are very good at doing is working out what can deliver within our sprint window. What we actually want to know is how many stories we can expect to be delivered if we want to use this to forecast, which is our throughput.

For me, looking at leadtimes influenced how we were working on and preparing stories. Littles Law describes how we should see a lower leadtime if we lower our WIP. We think more about how more of us can work on a single story, this often starts in prep. We open less and this lowers WIP, decreasing leadtimes.

Having a leadtime which only just fits in a sprint window means we have limited options on how to plan the work in the sprint - we have to start everything on day 1. This would mean loosing fluidity - everyone would be one a single story from beginning to end. Not many options for us at all.

Lowering leadtimes by a few days gives us some flexibility in when we can start stories. We use our story points to influence when we start on things. Larger stories might need to go first but smaller stories run in parallel so that we can deliver throughout the sprint rather than everything at the last minute, which would probably create a bottleneck with testing.

For me the sizes of stories begin to matter less and less. They serve their purpose during prep and planning and help us get to the answer: "Will this fit in our sprint?". When we see a 13 we look to break it down further since we can see it is rarely delivered in less than 10 days, which does not give us enough options. 

If we bring something in mid-sprint, we can look at the previous leadtimes and give a percentage "75% of previous 5 point stories have been completed in the time we have left" allowing us to make a commitment with some accuracy on success.

There are many more interesting things you can gleen from leadtimes and some basic spreadsheet fun, Mattia's presentation is a great place to start.

Out and About: Agile on the Beach 2014 - Day 1

I spotted this last year and missed out on the early bird so made an extra special effort this year since this is one of the few Agile specific conferences in the UK.

Arriving on the Wednesday night meant a pasty and pint was foisted up on us in the bar, which was very welcome after a 5 hour drive. The subsequent pints chatting with the most excellent Jon Tilt from IBM might have been a slight mistake - but we only really discovered this at the breakfast retrospective. Jon showed us all up at breakfast after a run around Falmouth University campus looking fresh as a daisy.

The keynote this year was J. B. Rainsberger, who gave us a round trip of movements and the future of Agile with specific emphasis on XP. As with any good key note there were points I agreed with and some I didn't but the perspective was most welcome. Obviously a seasoned speaker it was a pleasure to listen to and the hour went fast.

Starting a conference about Agile with talking about the death of the brand i.e. Post Agile might have made some people feel uncomfortable but it embraced the idea that change is good as we learn from our experiences. Also, talking about "confident humility" resonated with me - the attitude we bring with us when we collaborate or pair is all important.

There was some fun too - the simplified planning cards were something I would adopt tomorrow! Can't seem to find a picture of them but there were just 3: Do it, Too F**king Big, No F**king Idea. J.B. wondered if there should be just one more, "I'll do that now"

Agile on the Beach has 4 tracks - Craftmanship, Team, Business and Product (which was a bonus track for this year). Curiously, I did not attend a single Craftmanship session which proved to me how my emphasis has changed over the last few years. People might create but teams deliver.

I started the day listening to Allan Kelly talking about "Does Agile work outside Software". This was more of a decomposition of what value we expect from Agile and if they apply to other types of business. There were some interesting points raised but the examples were the most compelling.

Lonely Planet apparently use SCRUM throughout the organisation - a talk was given at Agile on the Beach 2013 about how their lawyers use it. Pair Programming? Try pair laywering (if that is a word) - a way of building peer review into the creation of legal documents. Same idea applied to different field. They also use stand ups, iterations and retrospectives.

There was more of this throughout the conference - "Agile = consistently identify and seize opportunities" is a concept that can be applied universally. Although some practices are specific to a field, the principles can be applied to many organisations. Interesting stuff.

Next I moved over to the Team track with a talk from Darci Dutcher about fostering collaboration with Designers. This talk resonated with me since I have had challenges getting developers to communicate. It seems that without IM or SMS as a buffer many of them have problems. Even bribes don't seem to work :(

She focused he talk around 3 ideas: Attitude, Skills and Facilitation. I really liked this talk - specifically the point that nobody 'teaches' collaboration. As she pointed out this is not the same as a compromise or what your bosses opinion is. It should be something new, created by the people in the room, each progressing ideas and being creative.

I did manage to ask her about what else we can do with people who just won't dive in. I have an article on some of these thoughts coming up but Jon Tilt had a some insight - "If you can't change the people, change the people" (not something I like to think about since I like the people I work with)

Talking about Jon... I have seen Jon before at Hursley talking about how IBM started to use Agile. The thing like about Jon's talks is that the challenges IBM face are way larger than pretty much anything anyone else is talking about.

Fancy getting about 30,000 developers across 20 countries and 80 locations on the same page? These developers also work on radically different products (through many acquisitions) and have completely different cultures. Where do you start? So, the title "Making the Elephant Dance" is apt.

Jon is also a great speaker, so this was fun too. My take away from this was their use of Confidence Maps to allow quick visual representations of a projects current status - even the attendees could pick out the project in trouble from the example.

So after a quick bit of lunch (nothing special, sadly - I was spoiled at Re:Develop!) I arrived a little late to see Melissa Perri from produxlabs.com talk about Lean Product Management. It was crammed - the Software track had the smallest room by far and this session proved most excellent, even though I was on the floor in the isle with half the room.

Melissa is an awesome speaker - fast but easy to understand. Her point about moving your focus to the problem is something I have long believed in too. I specifically liked the alternative structure to user stories that she suggested:

When <situation>
I want to <action>
So I can <outcome>

The shift of emphasis to make the problem the topic of conversation is similar to other alternative templates suggested for feature injection. I think I prefer this one however, especially when it is backed up with "Explore problems rather than gather requirements". I think that the phrase 'Problems not Features' could be a bumper sticker. Maybe a tattoo?

There was a nice comparison between a 'normal' Product Manager and Lean Product Manager - essentially that they work to a Goal. She put emphasis on experimenting not developing, proving you are moving the right direction and working with the whole team to produce results. She asked us "What does success look like?". It made me wonder if I was doing the wrong job.... this looked much like what I enjoy doing!

There was more (much more). Her take on an alternative to road maps is something I want to look into. She also wins the newly created conference award for most amount of amusing cat slides - well done you :)

Back on the business track was Frances Bonnington with a talk about the application of SCRUM is a non-engineering industry. Frances was a newly qualified ScrumMaster at this time and this was almost a trial of fire as she took us through a very honest look at what worked and did not work. It all had a happy ending, however when she took charge of some geeks as ScrumMaster. I like happy endings.

Having learned that Melissa's talks are usually rammed, I was early for her last session called "Beyond Pretty: Creating Measurable Designs". I even had a desk so I could write a bit more legibly, go me!

She kicked off with decomposing 'design' - being a mix of Visual Design (What it looks like), Information Architecture (How information is composed on the page), UI Design (How we interact with the design), UX Design (Can users achieve their goal?) and finally Marketing Design (Does it sell the message?).

She posed the question if any one person can achieve all these things, using the phrase 'the unicorn designer'..... makes me think of how I feel about the phrase 'Full Stack Developers' for exactly the same reason.

The talk was about measuring design, which started with a quote:

What cannot be defined, cannot be measured;
When cannot be measured cannot be managed.
- Paul Lillrank

The 'normal' linear approach (IDEA -> Research -> Wireframe -> Build -> Launch!) makes to many assumptions on what is a set of decision. Instead, treat the design as a hypothesis and treat this as a cycle allowing you to test the hypothesis. We only launch once we have solved the customers problem.

She explained there are 2 types of measurement: Quantitive and Qualitiative.

Quantitive is useful for spotting trends and we can measure them against KPIs but it won't tell you why. Lots of tools to do this for you!
Qualitative is about observing behaviour and finding meaning.

Measurable design calls on both of these to prove if your solution is working.

There was a bit of cross over with her previous talk and that was a good thing. The ideas of iterative learning makes a lot of sense and she made a good point that you should only make small changes so you can monitor the outcome. If the change is too large, how do you know what delivered the impact you are looking for?

And there were more cats.

Finally, we ended the day with some flash talks. The highlight for me was a 5 minute talk on certifications and if they are good or bad. The suggestion was for a new certification, a CSSTWP:

Certified Stealing Sh*t That Works Practitioner

Awesome! The stickers were late apparently, which is a shame because I think I would prefer this one over anything else I have seen.

Also of interest was mutation testing. How do you know if your unit tests are working or any good? Well, how about injecting errors and running your unit tests again? Didn't sound like there was much in the way of tooling but I do like the idea.

A conference would not have been a conference without a bit of a party, hosted by IBM. At 6pm we all tottered off to the local beach for a few drinks and some food. They don't call it Agile on the Beach for nothing - by the way, organisers pay attention, it would be much easier to get corporate sponsorship if the name was different :)

The 'Lean' Oven

A while ago, I started a project to build an outdoor kitchen complete with a wood fired oven. It has been a completely frivolous adventure which has kept me busy over the summer. The whole driver for this was the wood fired oven (and the need to build things, obviously).

When I came to the point where I wanted to fit the oven, I kinda stalled. You should know that these things are really expensive, the cheapest was around £500 the most expensive around £1000. I had planned to have a small one since I figured I would only use it a couple of times a year.

It was this thought that made me realise that I was not thinking clearly about the value, or perceived value it would bring me. I had bought into buying the oven because I wanted an oven and that is as far as it went.

So, I started to think how I could test if having an oven would be as valuable as I thought it would be?

So, I found some guides on building a clay oven. This made more sense - it was less money, I could fit it into the space I had created already and it looked fun to do.

Most of guides said how they had 'dug up some free clay' which obviously makes this sort of caper much more attractive. Not much of that around here, so it would be a cost. I found a local company selling clay, the cheapest was around £6 for 12 kgs. A rough calculation suggested I might need about 5-7 bags. This is mixed with sand which is easy to get hold of and relatively cheap so I ignored that for the time being.

It also had a hidden cost in the floor should probably be made using firebricks. It doesn't have to be but if normal bricks crack from the heat then I would loose my entire investment. I would need 15 for my base and they cost about £4 each locally. I can get them cheaper on the Internet but the postage offsets this so much that it probably is not worth it.

This would give me the option to keep it if it worked, which is a fair presumption since I would probably be following instructions from someone else rather than making it up as we go along. So, to test this idea with the option of keeping it would be around £100 - significantly cheaper than buying one that's for certain.

My thinking was a little clearer now. As great as this was sounding, it's still limiting my options and carries significant risk too. It was certainly a do or die operation - if it worked then awesome but if not I would only have a base and a whole load of clay to get rid of.

Then I saw this....

Yes, it's a fire back. I removed some from my house a while back and put them to one side since they are heavy.

I saw an oven however and with some bricks I had laying around I quickly bodged something that 'looks' like an oven:

But does it behave like an oven? The guides all have a ratio between the height of the oven and the height of the opening. You need enough to ensure a good airflow from the bottom to the stoke the fire. Let's test what we have and get some feedback to see if we need to tweak our design or if this is a non-starter.

It lights and keeps going at a steady pace, it never roars but the wood is questionable and probably damp. I stick a BBQ thermometer and just leave it for a while, monitoring the temp every now and again.

The max temp the oven reached was about 150 deg C. Way short of the 600 you would expect from a 'real' oven but this was with dodgy wood and zero insulation, which is key to getting the temperature up and holding it. Whilst it was going, a lot of smoke come out of cracks and gaps. I solved this by simply packing them with some damp sand, which worked a treat and was nicely temporary as well.

What I also observed when I lit the fire was how the smoke came out of the front, which looked like it was causing a bottleneck. I also noted that the heat losses where significant since it got really hot, so insulation would certainly play a part in how well this works for actually cooking things.

So a further improvement would be to create a chimney just after the dip with a column to funnel the hot air up and out a little easier and hopefully improve draw. This is a one time shot since I would have to cut the fire back but I happen to have a spare so this is not as bad as it sounds. If I ruin it then I still have this one as a backup - so I still have options. If I break the first one I would need to be clear on my commitment since if I break the second one too, I have no more options with my current experiment.

Before I do that, however I could try to insulate it and make sure I can get higher temps. Just a covering of sand would probably help, maybe with an oven fire blanket too which has pretty good insulation value. Using some decent wood would be more representative and pretty low cost (or zero cost if my neighbour lends me some from his wood pile).

This is still a work in progress but it is the thought process that I thought was interesting. I was unsure what value my 'feature' would provide me so I wanted to test it and get feedback. I looked around to see what I had that could get me feedback as fast as possible. I then review what I now know and see if it fits with what I thought. I learn from it, tweak it and iterate to get more feedback.

I still have to prove that the oven will provide me with 'value' a.k.a yummy pizza - but a pile of wood and a few friends will answer that. So my BBQ 'showcase' will get me buy in to create a production version of my prototype.

Christmas cards for your competition?

The Internet has thrown up some very counter intuitive business models in the last few years. In time, some of these could well be shown to be daft but for the time being they are on the cutting edge of business.

Conventional wisdom would suggest that having no competitors would be an advantage but in a market place as large as the Internet I think you need competition to ensure any sort of customer base.

Imagine a start up with an innovative idea. There is no established sector but there is potential to attract them, probably from other sectors that are related. Or maybe an established company with a niche product that needs to attract new customers to ensure growth or stability.

This is where competition comes in handy. Although you are all after the same customers, you are all marketing and drawing people to the same sector which advertises both you, your sector and potentially your competitors. So, you win some sales, you loose some sales - but you do stand a greater chance of getting them with competitors doing the same.

Different marketing strategies will target different people and conversions are not always obvious or guaranteed. So once the sector is discovered, customers will often look for competitors to secure the best service and/or price.

I would go as far as saying that entering a completely new sector would actually benefit from competition, so why not create some? You could open source your product and actively encourage people to provide a competing service to stimulate the sector.

Competition ultimately fosters innovation. Each company will be looking at their competition, assessing their products and comparing with their own. This basically creates a feedback loop, where we can reflect on what works and what doesn't work and plan what to do next. We get some new ideas from this new perspective, which starts the loop again from our customers perspective.

Our competitors also push us to iterate ideas faster, to forge better relationships and basically be better than them to ensure we get and retain our customers. All good things, if you ask me.

Complacency is too easy to fall into if we have no need to change. Competition forces us to look for value and act. Our competitors should be considered a mirror - what can we learn about ourselves by looking carefully at what they are doing?

After I wrote this thought process down, I found some other people with the similar points:

http://www.forbes.com/pictures/fgdi45eekll/5-reasons-why-competition-is-good-for-your-business-2/
http://www.shaunrosenberg.com/10-reasons-why-competition-is-a-good-thing