Agile, Lean Startup/Lean Enterprise, Programming, Management

Avoid not trying

While preparing an introductory workshop on Scrum, we wanted to end our sections of presentation/retrospective with some general tips on the area discussed that would give a team that is starting out with scrum some help on things to try. And things better not to try.

I mean, Inspect and Adapt, yes, but it won’t hurt to avoid some common pitfalls.

Here’s the things we came up with, please let me know (below or on twitter) which ones you don’t agree with, and what important ones we missed!

User Stories

Try: Making stories small enough to be DONE within three days

Smaller also means easier to estimate, and easier to test. One of the most common things I find is Really Big User Stories. That makes everything hard.

Avoid: Working on less important stories before finishing more important ones

(De-)Prioritise ruthlessly before taking things into a sprint. During the sprint, don’t work on lower priority issues before the higher priority ones are done.

Try: Splitting stories vertically

If every story has a user facing component, (de-)prioritising parts of functionality becomes possibly. The earlier the user/customer can see the functionality, the sooner you can get feedback.

Avoid: Splitting stories by component

Delays getting feedback. Encourages work not directly related to functionality.

Try: Making stories specific by defining acceptance criteria for each one

You’ll know better what to do, how to estimate, how to test. And when you’ll be done.

Avoid: Making stories too detailed too early

You’ll add detail to stories in the course of the project, but doing it too early can mean

Planning

The whole team will gain understanding of what is expected. You’ll get better estimates. You can use a release burndown!

Of course, there are things that can help with this such as, ahum, having a clear vision, but you need to start somewhere.

Avoid: Not updating your estimates as you learn more

Estimates are estimates based on current understanding. If understanding doesn’t evolve during work, something is wrong. So estimates should also evolve. As you refine and split user stories, re-estimate them to evolve your planning along with your requirements.

Try: Fixed sprint length (of two weeks)

Fixed, for predictability, letting the team find a rhythm, ensuring problems (waste!) get raised. Two weeks, because one week is initially difficult for a team to do (but if you think you can, please try it!).

Avoid: Telling the team how much to take into sprint

You can’t expect a team to take responsibility for delivering if they don’t have control.

Try: Many (min. 6 – 10) small stories in a sprint

Failure to deliver the last story is much worse if it’s the only one. Or one of two. Smaller also means easier to estimate, and easier to test. It’s much easier to determine progress if you’re talking about ‘done’ stories, instead of percentages. (that was sarcasm, probably.)

Avoid: Stories that span multiple sprints

Just… don’t.

Try: Counting unplanned issues picked up in a sprint

If you get a lot of unplanned issues, you need to take that into account in your sprint planning. Count to get an idea of how much time you need to reserve for this!

Avoid: Picking up all unplanned issues raised during a sprint

The PO should de-prioritise anything that is not a crucial customer problem, and then put them on the backlog to be planned in later sprints.

Try: Reserving a fixed amount of time (buffer) per sprint for unplanned issues

Measure how much time you’re spending on unplanned issues. Reserve that time for them (so your planned velocity goes down), and work on Structural fixes so this time reservation can go down in the future (after you measure you don’t need all of it).

Avoid: Extending buffer for unplanned issues

Because the buffer is there for a reason. To make sure that the rest of your time can be spent on what you’ve taken into the sprint. One way to deal with the buffer thing (to avoid getting tangled in time percentage calculations) is to have a rotating role in the team that deals with issues that come up. Call him Mr. Wolf, if you like, because it usually isn’t the most coveted role to play. That’s why you rotate…

Scrum Master

Try: Highly visible display of sprint & release burndowns in the team area

Highly visible progress helps keeping focus. Whole team can see (and can feel responsible for) progress. And mostly, this is a great way to discuss any upcoming new issues with whoever is raising them: “Yes, I can see that this is important to you. Let’s look at what we’re working on right now, and what we need to delay to get that in…”

Avoid: Only updating a computerised issue tracker when completing tasks or stories

A physical task board provides continuous visibility and feedback. Seeing people moving things on a physical task board during the day simply encourages getting things done. Putting a post-it on a wall simply feels more real than putting a new issue into JIRA. There are so many ways in which the visible and physical are wired into our system, that there really is no way to replace that with a computerized tool.

Try: Taking turns during stand-up by passing a token

Sometimes stand-ups can devolve into a rote, going round, reporting status form. Break this by passing/throwing a token from one speaker to the next, in a self chosen order. This keeps things lively, avoids anyone dominating the stand-up, and makes people pay attention (or drop the ball:-).

Avoid: Reporting to anyone but the Team during stand-up

At all times avoid the stand-up becoming a ‘reporting to a project manager’ thing!

Try: Having a retrospective at the end of every sprint

The whole idea of Scrum is to continuously improve. You can’t do that if you don’t discuss how things went.

Avoid: Not executing improvement experiments generated in the retrospectives

Don’t just agree you need to improve. Do Something Already! At the end of the retro, agree which points you’re picking up, and ensure they’re taken care of in the next sprint. Also, with your action, try to indicate what the expected result of the action will be. Deciding whether your test was a success will be so much easier. Look into A3 problem solving when dealing with bigger issues. Or even with smaller ones.

Try: Highly visible display of top 3 impediments

And cross them off one by one as soon as they’re done…

Avoid: Stories that span multiple sprints

Yes. A bit obvious, perhaps, but this is happening often enough that I thought it worth mentioning.

Try: Having an impediment backlog for the team and one for management

Yes, impediments that managements should fix, should be just as visible (maybe even more so!)

Avoid: Having a very long impediment backlog from which no items are ever picked up

Agree what to pick up, don’t pick up too much at once (start with one at a time!), and FINISH them.

Team

Try: Making tasks small (< ½ day)

Seeing people moving things around on a task board multiple times a day encourages getting things done. Smaller tasks are easier to understand, less chance of different understanding. Much easier to hand-over tasks, work together on stories.

Avoid: Not moving any tasks (on the planning board) during the day

Seeing people moving things around on a task board multiple times a day encourages getting things done. Lack of progress should be spotted as soon as possible, and help given.

Try: Agreeing on a definition of done

You should all agree on what ‘Done’ currently means. Once you can stick to that definition, you can start working on improving it.

Avoid: An aspirational definition of done

Did I emphasise ‘currently‘ enough? You need to know where you are, and that should give you a starting point…

Try: Writing automated tests for any production issues

This helps understanding and replicating the issue. And it ensures the issue will not come back. Having the tests documents understanding of code and functionality that was missed earlier.

Avoid: Programming errors found after the sprint has ended

A User Acceptance Test can find functionality the user didn’t expect (understanding). A UAT should never find expected functionality that does not work (quality).

Try: Always doing a root cause analysis for any unplanned work

Production problems are not normal! Find out why it happened, and see how you can change your process to avoid that type of problem in the future. Note: that means agreeing ‘Let’s not make this mistake in the future’ is not sufficient…

Avoid: Not doing structural fix after root cause analysis

The change should be structural, in your process. For instance:

‘It was a simple programming error’, should result in changing you Definition of Done to require a higher code coverage for new code.

‘There was a mistake during the deployment’ should result into ‘Let’s automate deployment’.

‘We did two incompatible changes’ should result in ways to increase communication in the team, and better automated regression testing.