Agile

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.

Customer Feedback is important

Posted on by will

We all know it’s important to think of our users first, and that user feedback is important; however all of us have to deal with products, processes and systems in our day-to-day lives in which the user was likely at the bottom of a long list of other priorities during the design phase. Anyone who has been through customs in an American international airport as a non-US citizen can understand what I’m talking about.

In Beijing International Airport, however, they appear to value feedback from travelers. Attached to the booth under the window on every customs desk is a small box with 4 buttons. The text above the buttons reads: “You are welcome to comment on my work”, and you’ve invited to press “Greatly satisfied”, “Satisfied”, “Checking time too long” or “Poor customer service”. In full transparency the custom officer’s identification number is shown directly on the display.

Collecting user feedback at Beijing International Airport

Collecting user feedback at Beijing International Airport

It would be interesting to know what they do with the results: whether they use the outcome to performance manage the staff member, or to identify patterns of satisfaction across different demographics of traveler. Either way, it’s refreshing to see an area that appears to be traditionally nonchalant about user satisfaction take an interest in what people think for the purpose of making the system better.

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“.

Software update cycle: faster every day

Posted on by will

My Atari 2600 never got a firmware update. Not a single one. Neither did any of the game cartridges that came with it.

In the early days of software, ‘soft’ware was really just a different kind of hardware. It was built, packaged and shipped exactly once. If you shipped it with a bug, that bug would stay there.

‘Softer’ storage types (tapes, floppy disks, etc) and better distribution allowed software companies to release new versions more often. Many years between major versions became one or two years, but updates to a specific version were uncommon.

The internet shortened the cycle even further – turning one or two years to months for many software products, and allowing automatic updates of existing versions to fix bugs, patch security holes, and so on.

Seamless and fully-integrated update and application management technology, like the App Store for Mac, can bring the cycle down even futher – changing months to weeks between updates.

What happens when the cycle is even shorter? Then you get web products. Sites like WordPress.com or Amazon can push an updates to production servers multiple times per day.

How fast are you?

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.

SCRUM User Stories: As a User, NOT As a Manager

Posted on by will

The success or failure of a piece of software, or any product for that matter, is how well its users are satisfied, and how well it solves their needs. In the world of web software, adding functionality is rarely the differentiating factor that will lead to the winning product. More likely the winner is the product that solves the user’s problem in the simplest, easiest and most delightful way.

In other words, product design is all about the user: solving their needs the best way possible. Every single line of code you write should help the user solve their needs better and easier…

… which is why I am often confused when I see user stories like “As a product owner, I want…” or “As a manager, I want…” Or worse still: “As a data centre, I want…”

Who ever asked a data centre what it wants?

User stories start with “As a user…” for a reason: the process of writing a clear sentence that starts with “As a user” forces you, with each product decision you make, to consider and understand how what you are about to do allows you to solve the user’s needs in a better, more efficient way. If you can’t do that, then you have to question why you are adding this user story at all.

Avoid stories that start with anything other than “As a user”. That’s why they’re called User stories. If you can’t work out what a user gets out of the deal, it probably isn’t worth it.

Move fast

Posted on by will

The world moves fast. Your competitors move fast with it.

Users move fast, too. Users are more fickle than ever before. This month’s UK WIRED magazine rated Twitter as “tired”. This for a service that’s only five years old with a still-growing userbase. Ouch!

In the world of web products, building and releasing beautiful and delightful products and user experiences is only half of the battle. The other half is winning (and keeping) your userbase. Your product could have a net promoter score of +80, but if it still only has 10 users, is it really successful? If you build it, they won’t necessarily come.

Users want stability and reliability. Once they have settled in to a product that solves a particular need, it’s that much harder to get their attention to yours. At the same time, and perhaps contradictorily (who said human beings were simple?), users also crave the new. New updates, new versions, new features. News, blogs and social channels thrive on the new.

The web has sped up business dramatically and continues to speed up software product innovation. It’s a race to the bottom – at some point we won’t be able to go much quicker – but we’re not at the end of that race just yet. The strategy to compete in this space, I think, has two major components:

1. Work fast. Build fast, iterate fast: improve fast.
2. Be ready for when we hit the bottom. When we can’t go faster, on what track will the next race be run? Which race can you win?

Important note: fast doesn’t mean chaotic and unplanned.