scrum

6 principles for a productive agile development team

Posted on by will

“Being Agile” is more than following a checklist. It’s more than following the Scrum or Kanban handbook (in fact, it doesn’t even matter if you’re “doing” scrum or kanban at all!). Being an effective and productive agile software development team is about understanding and believing in a set of values, practices and principles.

Starting with our engineers, we tried to boil these values and practices down to a handful of core ideas. We wanted to share a common language and have a common set of checkpoints where we could track and assess where we are as a team, and give us guidance on where to focus to help us get better. We created what we call the “Agile Sliders”: a set of 6 guiding principles and practices for agile engineering teams.

  1. Code Quality
  2. Unit Testing
  3. Acceptance Testing
  4. Self-Organisation
  5. Pair Programming
  6. Code Ownership

Code Quality

  1. Thinks code as it is, is OK
  2. Understands and appreciates OO
  3. Identifies ‘smells’ in code
  4. Desire to fix smells and continually improve code
  5. Deals with technical pain and debt
  6. Uses solid OO design principles
  7. Understands the importance of fixing ‘broken windows’
  8. Understands and uses design patterns
  9. Encourages debate and learning

Unit Testing

  1. No Unit Tests
  2. Reluctant to write tests / low quality tests
  3. Always writes unit tests; tests the right things
  4. Always writes tests first
  5. Unit tests follow good OO principles
  6. Challenges the team when they don’t write enough tests

Acceptance Testing

  1. No Acceptance Tests
  2. Manual ATs done by devs
  3. ATs defined by devs with input from QA and Design
  4. Some automated ATs by devs
  5. Some automated ATs by devs in the build
  6. Outside-in development using ATs
  7. Run ATs locally before every checkin; fix breaks including other’s tests
  8. Call out team members who don’t write tests

Self-Organisation

  1. Needs micro-management
  2. Participates actively in plannings, estimations, etc
  3. Trusts team members
  4. Steps up to lead planning, etc without prompting
  5. Seeks out and gives feedback safely
  6. Team runs own standups, etc. Solicits feedback

Pair Programming

  1. No Pairing
  2. Reluctantly pairs when asked
  3. Willingly pairs when asked
  4. “Where’s my pair?”
  5. Pairing effectively in driver and navigator roles
  6. Asks team members why they are not pairing

Code ownership

  1. Mine / Theirs
  2. Willingly works on other code
  3. Not defensive about changes to code you wrote
  4. Seek out stuff you don’t know and work on it
  5. Go out of your way not to drive when working on ‘your’ code
  6. Encourages the rest of the team not to think of code as Mine / Theirs

Each principle exists on a scale representing a journey to an ideal state. In every retrospective we assess our progress against these scales. Did we get better? Stay the same? Get worse? The point isn’t so much to score ourselves, but it is a trigger for a conversation, and a tool for the team to use to challenge themselves on their journey.

We have also found that we can view progress from multiple viewpoints:

  1. The team as a whole, and
  2. Individual developers.

We’ve had some success linking these principles not only to team targets, but to individual performance targets as well.

We constantly iterate on our “sliders”, and we love feedback. Please leave any thoughts in the comments. I would like to expand the set of sliders to cover Product Owner and Experience Designer roles.

The Agile Team Values Poster

Here are the 6 principles and practices in a poster form. Click the image below to download a larger version suitable for printing. You are welcome to print it, change it, make it better!
Agile Team Values

A Scrum Master/Agile Coach job description

Posted on by will

I’m often asked for help putting together a job description for a Scrum Master, so I thought I would post an extract of one we’ve used recently.

We are a product team of developers, QA experts, user experience and visual designers and product owners who are looking for someone to help us get better at what we do. We’re pretty good at the basics of agile software development but can always use new ideas about how and where to improve. We’re less concerned about what it’s called (Scrum/Kanban) and much more excited about results, whether that means moving towards continuous deployment, using ATDD, or seeing our active users grow.

You are someone who leads by example rather than by dictate and you know how to bring out the best in people. You’re not afraid to deal with conflicts. You know when it’s good to say “No” and when to push for more results.

In addition, we’re looking for someone to act as a galvanizing force for our whole wider team in terms of sharing Agile knowledge across the company. Whether it be organizing 1-day open spaces for our agile community, or organizing cross-team workshops, the goal is for you to establish an Agile center of gravity around our team.

Your main responsibilities will be:

  1. Act as Scrum master for 1-2 scrum teams with a focus on guiding the teams towards improving the way they work.
  2. Facilitate sprint planning, retrospective and sprint demos
  3. Assist the product owner with keeping the backlog groomed
  4. Ensure cross-team coordination
  5. Reach out to the larger company network for impediment removal
  6. Maintain relevant metrics that help the team see how they are doing
  7. Coach and mentor other scrum masters in our product team. Ensure that our ways of working are consistent across the teams.
  8. Liaise between the developers and User Experience/Visual Designers. Foster better communication between the disciplines.
  9. Act as a project manager when necessary. Take responsibility for managing dependencies between our team and third parties or between our team and other scrum teams.
  10. Strengthen the presence of our team as an Agile centre of excellence. Actively contribute to the company’s Agile and Lean Community. Keep the rest of the company network aware of our activities.

Qualifications:

  1. Knowledge of the software development life cycle
  2. Certified scrum master/scrum practitioner
  3. Knowledge and/or experience of Kanban
  4. Excellent communication skills in English in written and spoken form
  5. At least 3 years experience working in an agile environment, preferably in a variety of situations

Feel free to use this, re-use it and copy it. I hope it’s helpful!

What would you add to make a better Scrum Master job description? Share your tips in the comments.

5 reasons Agile is like a cult

Posted on by will

As readers of this blog will know I’m a big fan of agile and lean software development principles and practices, but have you ever noticed how cliquey the agile scene is becoming? How almost cultish?

Here are five reasons the Agile scene is turning into a cult:

You’re either one of us, or you’re not.

Agile is like a cult - you have to believe.

You will read the bible, go to church and believe in God, or you will go to hell. Period.

You will use Scrum or Kanban and believe in Agile, or your software will be buggy, over-budget and crappy. Period.

You will respect, honour and awe the founding fathers.

Agile is like a cult - the founders will be honoured.

You will honour, awe and respect the founding fathers. The Scientologists have, for example, loopy L. Ron Hubbard, the science fiction author-turned prophet who continues to convince millions of normal people that Earth is a colony founded by aliens. The followers of the People’s Temple in the 1970s honoured, respected and awed their founding father, Jim Jones. 909 of them swallowed poisoned Kool-Aid in 1978.

You will honour, awe and respect the agile founding fathers. The more often you can use this image in a presentation about agile the better.

You will respect the sacred parchment.

Agile is like a cult - you will have faith in the sacred document.

Cults always seem to have a sacred parchment, original manuscript or some other artifact that serves to both prove the validity and authenticity of their beliefs, and also lay down the groundrules for how your soul will be saved.

We have the Agile Manifesto…

You will follow the strange rituals.

Agile is like a cult - there are strange rituals and secret handshakes.

Secret handshakes, rituals, traditions, sacred artifacts: these are the cornerstone of any self-respecting cult.

Standups, sprint reviews, sprint plannings, a 3-week lunar cycle…

You will read, follow and respect the rulebook.

Agile is like a cult - you will follow the rulebook.

The path to spiritual salvation is in the bible.

The path to software salvation is in the Scrum handbook.

7 reasons your Scrum Master may be underperforming

Posted on by will

What do you need to have a great and effective scrum master on a team?

The Scrum Master is, I think, one of the most misunderstood roles on the scrum team. It’s a critical role to ensure your team will perform at their best.

An effective Scrum Master is not just anyone who wears the Scrum Master hat for a few hours per week. I think an effective Scrum Master should have (at least) these three things:

  1. An understanding of what it means to be a Scrum Master (it sounds obvious, but evidently sometimes it’s not). A Scrum Master course is the minimum here, I think. It also includes understanding the agile manifesto, understanding lean principles and the mechanics of software development.
  2. An innate, natural desire to learn, improve and be better.
  3. The support of colleagues, the team and the organisation to be able to do the job.

I’ve seen a lot of different kinds of scrum teams, and some common themes appear when thinking about under-performing Scrum Masters. Here are some sings that you might not have the most effective Scrum Master:

  1. Your Scrum Master is responsible for 7 different teams.
  2. Your Scrum Master is just one of the developers who has the responsibility to send the calendar invites to the standups and take notes in the retrospective.
  3. Your Scrum Master is just someone from your QA team who puts cards for bugs on the story wall.
  4. Your Scrum Master cannot describe the Agile Manifesto.
  5. The only contact your Scrum Master has had with scrum or agile is the two-day CSM course (or worse, none at all).
  6. Your Scrum Master is not able to realistically change the process within which your team works in order to respond to feedback in retrospectives or improve the way of working for the team.
  7. The Product Owner or business owners ultimately responsible for the team and the product are the kind who want all the benefits, such as predictability, increased output and accountability, without changing any of their entrenched, old-school, waterfall processes.

I’m sure there are others, but if you see any of these in your scrum team, you might want to take a look at your setup. Note that these things are not always a problem with the person acting in the role, per se – many of these issues stem from organisational misunderstanding of the role as well.

Who cares if you’re doing scrum or not?

Posted on by will

Have you ever heard the question: “Are you doing Scrum? I mean, really doing scrum?” Or: “If I take the Scrum textbook practices, but change one or two things to suit my business, software or people, is that still Scrum?”

At the Agile Lean Europe Unconference in Berlin yesterday there was quite a bit of talk about what Scrum is, and what it actually means to ‘do’ scrum. There was an open space on the topic, where one of the participants said, in response to the above questions: “the answer should be, Who cares?”.

There’s a concept borrowed from Japanese Zen practices called ‘Mu‘. Mu is the third possible answer to a binary (yes/no) question.

“Are taxes good or bad?”

The answer is they are neither good nor bad. The real answer is larger than the context of the question that was asked. The answer is ‘Mu’. What Mu is really saying, is, “un-ask the question”.

Another example: think about a single bit in a read-only memory module in your computer. When the power is off, is the state of the bit 1 or 0? The answer is: it is neither. It is in a Mu-state.

Back to the original topic. “If I change this or that from Scrum, is it still Scrum?” The answer is Mu. It doesn’t matter if it is still scrum or not. What matters is if you are delivering high quality software. If you are measuring that software and iterating. If you avoid waste and decrease time-to-production. If your team is happy, self-organising and efficient. Who cares if it’s “scrum”?

* Note: Robert M. Pirsig speaks about Mu in his amazing 1974 book, “Zen and the art of motorcycle maintenance“.

SCRUM User Stories, Part 2: User value over business value?

Posted on by will

My last post about User Stories and putting the value for the user first in any product decision generated some great discussion on Twitter. As with anything there are some varying views on the topic, and as one example I was pointed to Liz Keogh’s post on user stories.

Liz argues that User Stories should be better named “Stakeholder stories”, as the things you build are addressing the needs of varying groups of stakeholders, only some of which are the end user.

In the creation of any product there are of course many stakeholders who need to be satisfied: the CEO, shareholders, investors, marketing people, the legal department, and so on. In the design of the business, of course the internal stakeholders have the most important requirements. What sort of market are we going into? What segment will we serve? What problem or user need do we attempt to address with this product?

But when you start designing the product that the user will have in their hands, then the user needs to be at the heart of that design solution. Here, the user needs have to come first.

But what about all the stuff that you have to build into products that users don’t want, or even hate? Stuff like CAPTCHAs during registration processes, or advertisements? If the user’s needs come first, why does this stuff exist? To answer this, let’s take a step back and look at where user stories come from.

User Stories are not immaculate conceptions: they don’t just appear out of the blue, but they are thoughtfully created to address needs of the product and the business. On other words, they are derived out of the product vision and the surrounding business model.

If your business model involves monetisation through advertising, then you have a problem to solve: “how can I enable advertising in my product?” It’s clear that the user is not at the heart of the decision to enable advertising, but business models are complex and have to satisfy many stakeholders and solve many problems. At the business strategy level, the end-user is only one of multiple players, and the user doesn’t always come first.

So you have this problem: you have to enable advertising. How do you solve it? Do you slap a full-screen takeover banner for some random personal hygiene product on your start screen? Probably not. Do you enable Google AdWords to show advertisements relevant to the content in a meaningful way? Getting warmer. Do you study the user’s interaction on the page to determine where the advertisements should be placed and how they should be visually displayed to ensure that users understand what is a sponsored link and what is your own content, to avoid frustration and confusion from the end user and maximise the meaning and value they get when they interact with the advertising? Better still.

What is at the heart of each of these decisions? The user. This is where the user comes first – in the design of the solution to the problem. In the User Story.

User-centric design doesn’t absolve you (regrettably) of the need to be aware of the business context or the constraints of your business or industry: it merely proposes that the user is at the heart of how you solve your product problems and how you work with the constraints. Keeping the user at the centre of your user stories by insisting they start with “As a User…” helps you stay focussed on the people who will be interacting with the stuff you’re building.

Better SCRUM User Stories: Connect the story with the real user value

Posted on by will

Everything you do to your product has a reason. There’s a reason that button is blue, or that message contains those words. There’s a reason you display that data or that notification.

Every reason is, at its heart, about the user.

This is why I like using user stories to talk about specific product developments and changes: writing stories reminds us that at every step of the way, everything you do is about your user. Every time you want to change something or add something, you need to understand ‘why’ – why are you adding what you’re adding, and why should the user care.

Connect the user story with the real user value. What the user wants. Not what you want, what marketing wants or what your boss wants – but what the user wants.

Here’s an example of a user story that came across my desk recently:

As a user, when I hover over search results in the search list, I want the pins on the map to change colour.

What’s wrong with this user story? Firstly, it’s a bit ambiguous – which pins?

As a user, when I over over search results in the search list, I want the pin representing that search result to change colour.

Ok, it’s a bit clearer. But is this what the user really wants? I don’t think users have a pin colour problem. What they have is a problem of identifying where the search result is located on the map. The colouring of the pins is a solution, which should be saved for the story specification or acceptance criteria. What the user wants, I think, is this:

As a user, I want to quickly understand where each search result is on the map relative to the other search results.

Clear. But why? Why does the user really want this? Understanding the why helps us understand how to solve their problem. That’s where the second, and often forgotten, part of the user story comes in: the ‘so that’ part:

As a user, I want to quickly understand where each search result is on the map relative to the other search results, so that I can get a feeling for where the place is relative to me or some other point.

Now we are at the core of what the user really wants, and we can go on to design a solution that solves this user problem. This process of story refinement gives us a better understanding of the true motives of the user: the ‘why’.

If you find that you’re looking at a user story that contains more problem specification than solution, keep refining until you get to the real user value; what the user really wants.

Better scrum user stories: Split stories horizontally, not vertically

Posted on by will

Teams often run into trouble in a sprint when they’re trying to work with poorly split stories. Stories that are too big, too small, confusing or that mix the problem with the solution…

We should split stories into small, discreet chunks of functionality. A single story should generally be the smallest discreet piece of functionality that adds business value. What is sometimes forgotten is that a single story should also have a complete user experience flow – it should bring the user from a determined start point to a complete, useful end.

When splitting large user stories down into smaller ones, remember to ensure the story captures a complete user flow. When splitting, think splitting horizontally, not vertically.

A horizontally split story will show a single flow, or path, through a user journey. (For example, a payment process that covers the simplest functionality, a single payment type, inability to modify your order, etc. The options are very limited, but the user is able to reach a useful end – ie, they can pay for something.)

A vertically split story will show multiple paths through a flow, but will stop before the flow can reach a useful end. (For example, a payment process that covers, at once, all the different payment methods that you ultimately want to support, but not the surrounding user flow.)

The problem with splitting vertically instead of horizontally is that vertical ‘strips’ have the entire complexity of the full, complete solution, but you lose the ability to test the whole flow properly. It is also far more tempting to dive into a pie-in-the-sky architecture discussion because to build all the full options for this one strip requires an understanding of all the inputs and outputs of the flow – most of which probably don’t exist yet.

An incomplete flow not only adds no user or business value to your product, but it’s very difficult for teams to build effective solutions for incomplete flows. Think and split in terms of thin, horizontal flows, and increase complexity with additional horizontal ‘layers’ (additional stories).