Timing with Tomatoes

After attending some of the Personal Effectiveness talks at Goto; in Aarhus, I decided to have a go at using the Pomodoro technique. At a very basic level, using this technique means working for 25 minutes at a time before taking a 5 minute break, then repeating the pattern. After every four pomodoros, take a longer break.

Linda Rising in particular had talked about the need for regular breaks to ‘recharge’ our brains, and how this can actually make us more effective than working continuously without a break.

My pair agreed to give it a go with me, and in fact found an awesome Android app called Pomodroido, so we set off! We made an effort to get up and walk around during breaks, even if it was just a wander through the office.

Here’s some of my observations from the first couple of weeks we spent doing it.

  • Always knowing that you have a break coming up and how far off it is, makes it much easier to get through stuff – especially boring work, or things that you don’t want to do.
  • Knowing that you’ll be breaking from what you’re doing in 25 min made me focus harder on the work I was doing – as a consequence, by the end of the day, I was often pretty tired.
  • I was a bit skeptical about the longer break, but after four intense 25 minute sessions, I really needed it.
  • The greater focus also meant that I felt I was getting through more stuff than I would have otherwise, especially when I had a list of handover documents to write, which I might have dawdled over otherwise.
  • Getting up and walking around helped me stay alert, especially during the post-lunch afternoon slump.
  • Working with a pair helped both of us be more diligent about taking breaks, getting up and keeping going with the pomodoros.
  • It was useful to have an app – without that, sometimes it was harder to time the pomodoro, I often forgot to check the clock (although we sometimes forgot to start the app as well …!)
  • After finishing up on the project, I tried to carry on with the pomodoro technique while I was packing for my Australia trip, with mixed success – it’s less useful for running errands, for example! However, it’s definitely something I plan to try again on my next project, and for software development I think it has huge benefits.

Why Spike the Poodle?

My first blog was called Spike the Poodle. I’ve recently imported a lot of my old posts from my early agile experiences with Scrum, which made me smile and sigh :)

Here’s the original story of why it was called Spike the Poodle.

“Poodles come in different sizes. It’s not something I’d really given much thought to before. I’m not really much of a doggy person, but when I was younger, one of my friends had a miniature poodle, and so I always kind of assumed that all poodles came in about that size. No.

I attended a Scrum training course in March 2006. It was during this course that, for the first time, I felt that I really wanted to be able to blog and share my experiences of trying to implement what I’d learned back home, and to hear back from others who might be doing similar things.

In learning about estimating the size of project requirements, we undertook an exercise working in pairs to assign scores to different breeds of dog … Great Dane, German shepherd, Pekinese, Labrador, and … you’ve guessed it … Poodle. Without guidance as to what criteria to use, a group of eleven people will come up with some pretty imaginative ways to score different types of dog :) In our case, we decided to use the easy option (we were only given three minutes! And plus, we weren’t the only ones) and estimate based on size.

For most of the breeds it was fairly straightforward, but we disagreed on poodles. I had a picture in my head of a small fluffy thing about the size of two shoeboxes but my partner argued that poodles were more like the size of a Labrador.

So to put this back in the context of project requirements … we both understood different things by what had been described to us. Scrum offers a technique known called Spiking when there are unknown elements in the user requirements, and in the group discussion that followed the exercise, our trainer’s advice was that in this type of situation, we could Spike the Poodle in order to learn more about the requirement … and so the phrase was coined.

It was a funny moment in the course and made me smile to see it in the follow up email. Since the course was the inspiration for creating a site, I stole the phrase to use as a tribute to the newbie ScrumMasters who graduated with me in Manchester, and those who trained us.”

Incorporating Usability

In my quest to incorporate usability into our Scrum model in an agile way, I came across this article on Agile Usability.

It advocates drawing the design on paper to hammer out the big concepts, and running a heuristic analysis with several usability experts to uncover any major design flaws. The designer and developer then pair program to create the interface. Once a prototype is created, perform small scale usability testing. The requirements can then be adjusted. It also points out that Usability experts can help break down the items on the product backlog.

For us, the concept of having usability break down the product backlog is something we are already starting to do, and definitely something I want to continue. The idea of having our designer pair program with a developer to create a design is interesting. I wonder how he’d feel without Photoshop?? The rest of the cycle makes pretty good sense, isn’t that far from what we did this Sprint and seems like a good way to play once the team is all in London (until then, if we can’t be perfectly agile, I’m happy to live with it!)

I’m still researching, but this one was worth highlighting.

Estimatation …

This post was originally published on my last blog: Spike the Poodle

Imagine you and I were looking up at two skyscrapers, and I asked you how high you thought one of them was. You'd probably find it pretty hard to tell whether it was 50m or 500m. But what if I asked you how high the second one was in relation to the first? I bet you'd be able to say it was about a third larger, for example. If you could measure the height of the first building, it'd be much easier then to estimate the height of the second.

People are generally better at estimating relative size than absolute – and this doesn't just apply to buildings. In software development, estimating relative size – usually with story points – and then measuring how many points we can deliver in a given time is generally more accurate than trying to figure out how long a task will take in days, and then allowing for the general daily faffing.

Most developers have spent their careers estimating in time though, and making the transition to story points isn't always easy. There are a few things I've seen recently that can help people get comfortable more quickly with story points.

1. Estimate in a group with developers who have experience with story points.

Having developers in the group who have done it before is probably the best way to get the developers new to story points up and running quickly. They can set a good example and reassure the others that the technique does work. In an inexperienced group, doubt can plague the group and undermine the estimates.

2. You don't have to estimate QA and Dev effort together.

Some agile teams try to estimate the effort to complete a story to include all of the dev and QA work, but this is really, really hard. QA and development are very different skillsets, and it can be frustrating for the team members to have to estimate something they can't be expected to understand.

For teams practicing test driven development and writing unit tests, QA involvement can happen at the start and end of story development, with the QA and BA working together to write acceptance tests prior to development and sign off the story when development is complete. Unless the QA effort is really significant, it's probably OK to represent the dev effort in story points, and have the QAs check the estimates, and just highlight any that are unusually low but might cause a bottle neck for them.

3. Agree a good scale.

There are two common scales for story points: the fibonacci sequence and the power of two, and both work well. The important thing is to agree a sequence in advance, and ensure the upper bound isn't too high. Either 1, 2, 3, 5, 8 or 1, 2, 4, 8 works well. You might choose to use 0 and 0.5 for really small things like configuration. 13 or 16 point estimates become less meaningful and far less accurate – can you really think in terms of 13 times the size of a 1 point story?

Give developers a question mark for the stories they can't estimate – these are the ones that are too big, or have too many open questions. They'll need more analysis or splitting before you can estimate.

4. Get good story granularity.

Whatever estimation scale your developers agree, your stories will need to be small enough to fit into it. Usually your largest stories should be no more than eight times as big as the smallest ones, and you'll need to be clear about what each of them really means.

The best way to judge the granularity is to have some of the more experienced developers review them before you start estimating. This doesn't have to take very long. On a recent project, we spent maybe three or four sessions with developers prior to estimation, each one about an hour long. It might sound a lot, but it's worth it – there were only two stories out of nearly 700 that they couldn't estimate.

5. Capture Low, Likely and High estimates.

In some versions of planning poker, you're supposed to aim for convergence between the team members on an estimate. You can do two or three rounds of estimates on a single story to try and get there. The trouble is that this can take a long time, and get frustrating if team members don't want to budge.

One way of getting around this is to capture low, medium and high estimates, taking the lowest, highest and middle ground from the estimates from all of the developers. They may not agree, that's OK, and it's also OK to capture the disagreement and move on.

The low and high values can be used to weight estimates for release planning.

6. Get comfortable with assumptions.

Stories are a promise for a conversation. You won't know all the details of the requirement when you estimate, it's agile, you're not supposed to. In some cases, you might have a better idea in your head than what's written down on the card.

It's OK to make an estimate based on assumptions (make sure you record the assumptions with the story though!) Assumptions can help move the estimation along faster. If it turns out the assumption was wrong, then the estimate is also wrong and can be redone later.

7. Be prepared for estimation to take a long time – especially at the start!

In a recent estimation session I attended, the first estimate took well over ten minutes of discussion to arrive at. Some people were looking at the list of stories and starting to sweat and wonder if we'd ever make it through to the end!

This is normal, especially in a newly formed team, they will take time to speed up, but they will get there. Don't try and finish estimation in an hour, it's not going to happen unless you've got a week long project. The team need an adequate amount of time to not feel stressed and get used to estimates, it will pay off when you're able to speed through fifty stories in an hour and get an accurate release plan later on.

8. Calibrate several stories in advance with a smaller group.

Calibration is the process by which you arrive at the initial size of a story point. It's time consuming and challenging – we took an hour or so to calibrate four stories. If you're working with a mixed team of developers who are both experienced with and new to story points, it's worth taking the time with those who are more comfortable with story points to do the calibration first.

It's key to pick the right stories for calibration. Whatever scale you choose, find a story that fits each bracket – you may have to go through several to get there. When you're done, pin them up on the wall and refer back to them for the first few rounds of estimation: "Is this the same as that 3 point story on the wall?"

9. Use ideal days in the initial calibration.

To start calibration, use a scale like 1 ideal day = 1 story point – but only use it for the initial calibration! Once you have your scale, don't refer back to ideal days as it will muddy the waters – it's OK to use to get going, but after that try to just size against the other stories and forget about duration.

10. Triangulate with a sample of stories.

Triangulation, or cross checking the consistency your estimates, can happen at any point during or even after estimation.

You don't have to check every single story if you have a lot. One technique is to sample 5-10 from the middle estimates (e.g. 1, 3 and 5) and compare them. If they're reasonably consistent within and across the estimates (i.e. a 3 is about three times a 1) there's no need to compare any more.

A quick conclusion …

Like many aspects of agile, estimating with story points is not easy, but it is effective. I plan to write soon about going on to use the estimates for release planning, so stay tuned!

Sustainable pace

This post was originally published on my old blog: Spike the Poodle

I've heard a few people mention the dreaded "O" word on the project I'm working on (that's "overtime" in case you didn't guess) I believe very strongly in encouraging a sustainable pace instead of working overtime to get things done, and I think it's even more important on agile projects.

Here's a few reasons why, based on my experience:

  • Agile projects are planned based on a team's velocity. If the team had to work overtime to achieve a certain velocity, they'll have to work overtime again to achieve the same velocity. This means planning is based on a greater capacity than is in the team, which is not good!
  • The more time people spend working, the more tired they get. Tired people work slower, and make more mistakes, which ultimately means work takes longer. So the overtime doesn't really speed things up.
  • People need to take time out of work to spend with their families, or on their own lives. A healthy work life balance can result in better motivation, which ultimately helps team motivation, and the work goes faster.
  • In agile projects in particular, the iterations form a steady cycle. Unlike waterfall, where there can be a frantic, stressful time followed by a lull, in iterative development there isn't time to slow down. It's important to keep to a pace that the team can maintain without feeling burned out.

While I do think there's the odd occasion that working overtime can be the right thing to do – for example, pulling an all-nighter to get that important release out of the door – it's just not the answer for projects that are falling behind. It's going to end in lower quality, lower motivation … or both.

The power of positivity.

This post was originally published on my old blog: Spike the Poodle

I learned an important lesson this week about how powerful it is when people are outwardly positive about the project and work they are doing.

Having worked on projects in the past where the team were frustrated and had a tendency to demonstrate that quite vocally – something which I am definitely guilty of doing – at first, I really noticed the positive comments that were quite regular in our daily stand-ups:

"I had a really great meeting about how that system works …"
"The developers got together and now we all feel really good about building the new widget …"
"The BA produced some great diagrams that made the requirements much clearer …"

Every time it happens, it's a little boost to the team members, and helps keep up the motivation of the team in general. I particularly remember a comment about my diagrams, and it made me feel good :)

It wasn't until it was pointed out to me this week by somebody on my team that I realised I wasn't really contributing to the positivity myself though. People do notice – and in ThoughtWorks, they will tell you too!

So my resolution for next week is to try and say something positive and complimentary at least twice a day (n.b. "nice haircut" does not count). Try it – it's easier than you think!

A nice touch.

This post was originally published on my old blog: Spike the Poodle

On the storyboard for my current project, the project manager has pinned up photos of all of the team members. Each team member's picture is stuck on to the story they're working on, and there's a space for people who are on holidays. I'm not sure how common this is at ThoughtWorks – given that this is my first project :) – but this is something I'd not seen on projects before.

I think it's cool, and it's useful too. It's helped me remember who's who, having joined the project halfway through, and it's easy to see who's doing what (instead of initials). It made me feel like a real part of the team when my photo was added.

Sometimes the little things can really make a difference :)

Developers drive me nuts sometimes.

This post was originally published on my old blog: Spike the Poodle

"I don't know what server to use for the new branch …"
"CruiseControl is down …"
"The base build is broken …"

It sometimes seems to me as though the team use Scrum as an excuse not to have to solve their own problems. Broken build? Server stalled? No problem – holler "IMPEDIMENT!" and the ScrumMaster will come and sort it out for you.

What happened to self management? An impediment that's reported to the ScrumMaster should be something that you can't fix on your own. Many times a few probing questions helps the team member figure out the next steps ("Have you tried rebooting the server? Have you asked X if she knows the answer? Have you emailed team Y to see if they can help?") and nine times out of ten it is something they can do on their own.

Maybe teams feeling pressure to deliver their Sprint commitments feel that they haven't got the time to spend resolving impediments as well. Or maybe the same issues occur over and over, and they get frustrated (in which case, the ScrumMaster should be engaged to help solve the underlying cause).

The ScrumMaster, however, is not a general dogsbody – neither do they have the skills to fix every problem. To be successful, ultimately the team have to figure out how to support themselves as much as possible. The ScrumMaster needs to remind them of this as well!

Maybe it should be added to the team rules as a reminder …

I’m baaaaaaaaaack!

This post was originally published on my old blog: Spike the Poodle

I've been taking a long break from blogging, but I'm finally back! I wish I had a fantastic excuse, like "I've spent a year travelling around the world", or "the dog ate my keyboard" but sadly the lack of blog has been mostly down to a lack of inspiration and motivation.

So what's changed now? you might ask.

The main factor is that I've just joined ThoughtWorks – a company well known for their work in Agile. Oh, and apparently some of their people can be a little opinionated too (I should fit right in!) I'm hopeful that in between working hard on a bunch of new stuff, I might find the time and inspiration to keep the blog going this time.

I can't promise anything great. It's going to be a bit of a cocktail of agile posts, general work stuff and some personal bits all thrown in. Mmmm, cocktails …

Quality, Test Driven Development and Technical Debt

I really liked Mishkin Berteig’s recent post on why quality is not negotiable, especially the reference to paying interest on technical debt:

“As you accumulate debt, you have to make interest payments to maintain the debt. This shows up in the workarounds, the design cruft, the inelegant solutions, and ultimately in the slow down of the team in implementing new features.”

This is a great way to explain to the business why we’re investing time right now in becoming more Test-Driven.