I recently entered a talk into a Lightning Talks competition for a local meetup - Agile North East. My aim was to quickly visit ten points about agile software development that people in the audience would recognise from their own experiences. I hoped that the points would resonate and inspire some of them to focus on a specific improvement for their own teams. I hope that this blog post can do the same for those who read it.

So, my name is Paul, I’m a Senior Developer at Scott Logic and these are Ten Commandments of Agile.

1. If you are going to do agile… do agile.

Have you read the Manifesto or any part of the Scrum Guide in the last three months?

The average reading speed for an adult in the UK is 250-300 words per minute. So the Scrum Guide would take just under half an hour to read. Surely it’s worth a lunch break.

Some companies use an “Agile Playbook”, to state, “this is how we’re going to do agile development!”. This happened at a company I used to work for.

Adapting agile to your own environment is fine, but you can bet that the company playbook doesn’t come from years and years of experience and betterment. Agile was born out of a desire for lightweight development methods, don’t weigh it down.

So this tweet may be familiar. It’s easy to let things slip, so try not to let that happen and call it out if it does. Agile will forgive the mistakes.

2. You don’t have to stand up for the Daily Scrum.

Why do we stand up for the Daily Scrum? Because someone decided that not being comfortable would keep everyone focussed. In this Dilbert Cartoon Dogbert is taking not being comfortable to an extreme by pelting Dilbert with office supplies.

The Scrum Guide doesn’t say anything about standing up for the Daily Scrum, but if it helps you keep to the time you’ve allocated then great. Would you need to stand up if you were dialling in?

Try to keep it simple. This will help reduce the interruptions and focus the conversation.

The Daily Scrum should not be a number of one to one conversations with the Scrum Master. Everything you say should be valuable to everyone in the room, and everyone in the room should listen to what is being said. This promotes collaboration.

There’s a quote from Stephen Covey that applies here: Most people do not listen with the intent to understand; they listen with the intent to reply.

Ever find yourself talking over someone? Maybe you’re thinking about your reply before they’ve finished speaking.

3. Thou shalt not covet your neighbour’s story.

Planning is fine! Committing to a prescribed amount of work as an individual, or team, is also fine. Assigning team members to stories that suit their expertise and experience is also fine. We may even say that sort of thing is good.

Bagsie-ing all the interesting stuff at the start of the sprint is not good, don’t do it.

From my own experience, I occasionally have to work on a legacy version of my project and there are frustrations in working on an outdated application. I sometimes look enviously at the development happening on a screen nearby, so I admit I’m guilty of breaking this one.

4. Thou shalt not steal someone else’s story.

The Scrum Guide states that, during the Sprint Review, the Development Team demonstrates the work that it has done. This doesn’t always mean that all members of the Development Team demonstrate their work. Others may take ownership of the demonstration due to the business structure.

This is not what normally happens in the daily life of the team where each team member describes their daily work, so why should it be different when reviewing the work?

Some pieces of work aren’t even demonstrable. You’ll know this if, for example, you’ve spent any time refactoring, or increasing test code coverage.

33rd president of the United States, Harry S. Truman said, “It’s amazing what you can accomplish if you do not care who gets the credit.”

People who feel like they don’t receive any credit for their work disengage and, in extreme cases, quit. Acknowledge all of the work that all of the people did. This applies to everyone, not just the managers and other senior level people reading.

5. Thou shalt close the Sprint.

Bit harsh of Batman, this, so don’t go around slapping people. But don’t let them keep the Sprint open, either.

6. Honour your testers as you honour your devs.

I’ve been developing software my entire professional life, and I’ve always wanted to have better tests and more of them.

Testing is an implicit part of development. Engaging with the testers will improve the quality of what the team produce.

7. Remember the Retrospective and keep it holy.

The Sprint Retrospective is the ceremony that helps you to improve as a team, so I believe it’s the most important.

In my experience, the Sprint Retrospective is always the ceremony that gets ditched first. Or it’s the one that doesn’t get scheduled when teams try and adopt Scrum.

Without the Sprint Retrospective someone would still be required to take responsibility for the team’s working practices.

Maybe the Retrospective gets ditched because it’s always negative. Amplify the positives at the beginning, then attempt to reduce the impediments later.

Maybe it gets ditched because people don’t think it’s effective. Look into how to improve your Retrospectives, there are loads of resources out there. I found this opensource.com article useful and Fun Retrospectives is also a good source of ideas for structured activities.

Refer yourself back to the quote about listening above and think about it at your next Retrospective. Are you really listening to understand what’s being said? If you’re not listening properly, how do you know you’re improving the correct thing?

Here’s something my daughter’s teacher told me.

The fish has a short term memory, the dog medium term and the elephant never forgets. If you think about how effective your Retrospectives are consider how the fish would view recent improvements. How would the dog view things you improved 5 Sprints ago. Are the things the elephant remembers that you’ve improved since the start still going well, or do they need to be revisited?

8. Thou shalt not use epic stories as categories.

This is, perhaps, a bit specific to a certain ticket management system.

It’s human nature to want finish things, and it’s even better to finish something big. All stories, even epics, should be completable. Don’t just file a UI story under the Front End epic, give the team the satisfaction of completion. You can always create another epic.

9. Thou shalt get things done.

We touched on this a little with the last commandment.

I really like the principle “Working software is the primary measure of progress”. Developing something that people end up actually using is satisfying. Any work you undertake doesn’t add any value to your product until it has been released to your users.

If getting stories done is an issue, then focus on that, but take time to think about it over 2 or 3 Sprints and experiment with solutions. Remember Agile will forgive the mistakes.

10. Thou shalt not be that guy.

I remember walking out of a meeting about adopting agile practices and on the way back to my desk a guy said, “well, that’s not going to work here!”. Well, it’s definitely not going to work if you’re not going to try. Don’t be that guy.

I heard a story about a team who were playing planning poker over instant messaging, and one guy didn’t provide any estimates. When asked why the guy said, “I’m not doing estimates today”. How does that help? That guy had to work on stories estimated at that session. Don’t be that guy.

But we’d never be that guy, would we? We’d never derail the Daily Scrum with business chat, or use the Retrospective as a whining session, or break any of these commandments, right?

Closing prayer

I’m Paul, and those were Ten Commandments of Agile. I could have written a blog post about each commandment, so if one stood out for you take it away and look into it a little more. And remember, Agile will forgive the mistakes.

Thanks for reading. Amen.