As a young software start-up, there are two things we do every day: learn a lot, and a stand-up. The first one more or less happens, the second one has become a habit almost as unavoidable as breathing. Every now and again, these two things collide and we learn about stand-ups – and about how we organise our work.

Stand-ups are very short team meetings. They are part of a very popular method to organise software development which is called agile scrum. This is not a post about agile scrum. This is a post about motivation, and how to maintain a high level of motivation within an agile development team.

So here is how we do it:

1. Don't Be Dogmatic

But be sufficiently dogmatic to reap the benefits of a good process!

Make of that what you will: pick advice (also the advice in this post) only to the extend that it suits your situation, and apply it intelligently. And whatever you do, never be dogmatic just for the sake of it – people come first, (almost) always! (What a dogmatic thing to say.)

2. Add Everything You Do to the Sprint

The fourth principle of the agile manifest says: responding to change over following a plan.

It is a good principle.

In my first ever scrum project many years ago, I was inoculated with the belief that the scope of a sprint, once planned and started, is sacred and not to be touched. Systems like Jira support this belief by warning you that “Sprint scope will be affected by this action” if you dare to try to add a task to an active sprint – making it sound like a rather serious offense.

So initially, we tried not to change the scope of a sprint once we had started it. Several things happened:

  • A lot of work was done that was not captured in tasks. This led to false velocity measures as not everything the team did was captured and estimated, especially since the amount of uncaptured work varied between sprints.
  • Tasks that were not captured in tickets and added to the sprint were not always discussed during stand-ups.
  • Tasks that were not captured in tickets were seen as distractions – and ultimately as a burden.
  • This led to the devaluation of specific types of tasks which tended not to be plannable – such as ad-hoc responses to customer requests, which ended up being seen as a hindrance to the “real” work people were supposed to do which was captured in tasks, leading to rush jobs on customer requests and frustration on both sides.
  • Motivation was low as we ended sprints with very low numbers of closed tasks.

Allowing for the fact that no team works in a vacuum, it makes sense to allow space for things to come up. So we did. Everyone was encouraged to capture all their activities in tasks and to add them to the board. Guess what happened:

  • We learned a lot about what people spend their time on. Things appeared in our task list that we simply had not been aware of.
  • Team members who had had a consistently low velocity before (low number of tickets closed during a sprint) suddenly became champions as they started to put all their activities into tasks.
  • We discovered entire categories of activities that we had never captured in tickets before, such as meetings. This had led to people feeling like meetings were “not work”. Adding meetings to the sprint planning, and estimating the effort required for them, led to a better appreciation of the effort involved in meetings. Willingness to attend meetings increased as this effort was acknowledged and people could reward themselves with closing a ticket afterwards.
  • Motivation increased a lot for a number of tasks as they became visible on the board and appreciated by the team.
  • Estimation quality improved as a larger proportion of activities was captured in tickets. Team velocity became more stable.

My personal learning was to never underestimate the motivational power of ticking things off a list. I used to do that when I was a student: I would make to-do lists for everything, even housework. Sometimes I would put things on my to-do list that I had already done, just for the pleasure of ticking them off. I loved to look at the list at see how many things were ticket off already – oh how productive I had been! Back then this made perfect sense to me. Somewhere on the way, I lost that insight – until I rediscovered it when reflecting on our sprint planning.

3. Under-Commit

Add about 20% fewer tasks to your sprint than the team usually is able to achieve.

Why?

  • It is a great motivation boost to finish a sprint – to be able to actually close all tasks. The likelihood of this happening increases a LOT if you just put fewer tasks in the sprint.
  • Going back to the point about things that happen: planning less than you are usually able to achieve leaves more room for things that come up. It is easier to respond to urgent requests and to add tasks to an active sprint if you know that you will still be able to deliver your scope.
  • Quality of the delivered work increases as people are less pressured to finish tasks just in time at the end of the sprint.
  • Allowing the team to pick and choose tasks at the end of a sprint if they have completed their entire scope leaves room for your team member’s private priorities and preferences.

The last point in particular can have surprising effects on both your team member’s motivation, if they are able to finally work on that one thing that has never been prioritised, and also on the quality of your product, as your team member’s intuition about what makes sense adds to the quality of what you do. Not all team members are always able to assert their opinions about what should be done in a sprint during sprint planning. Leaving room at the end of the sprint for your team member’s personal choice of tasks can balance these effects. This is especially valuable if you have a mix of introverts and extraverts in your team.

It sounds like a fairly simple principle. Nevertheless we found it surprisingly difficult to implement. When we started to do this, the sprint planning sessions became a bit frustrating as we realised how few things we were able to add to the sprint. It is a bracing experience – as it often is when you are forced to accept the facts of life: the day only has 24 hours, and there is only so much you can fit into them. Staying true to your team’s velocity may be difficult, but it is worth the effort.

4. At Least One Carrot per Sprint

Ideally, all your team members love their jobs and are happy about any of the tasks they will work on during a sprint.

Unfortunately, ideally rarely happens.

As so many things about working in an agile manner, this is also about accepting the simple truth that there are many things that need to be done that nobody likes to do. The least we can do – the least we should do – is to make sure that there is at least one task in each sprint for every single team member that they are really looking forward to. We call this the carrot.

We try to do the carrot last. We try to only touch it once we have completed all our other tasks in the sprint.

Depending on how much we really want the carrot, we sometimes say it’s okay to eat it halfway through the sprint as well. This goes back to not being dogmatic: the carrot can be used as a tool, a motivational kick you can use whenever you need it. The main point is that everyone should have a carrot, at least one, in every single sprint.

5. Do the Most Painful Task First

Some tasks are like going to the dentist: stressful even to think about.

As humans, we try to avoid stress.

A good way to organise work is one that recognises our humanity and helps us deal with our natural shortcomings.

This learning came after many months of dragging the same handful of tasks from one sprint to the next. There was always a very good reason why it was not possible to complete all tasks in the sprint. And why it was always the same tasks that were left over was also quite clear: they were unpleasant to do.

When we decided to always do the most painful task first, these tasks suddenly melted away. We finally started to make good progress on topics that had been blocked by individual unpleasant tasks before. Almost as a side effect, we noticed that motivation spiked: these tasks had been like rainclouds hanging over our heads, sometimes for weeks and weeks. Now, they were rainclouds over our heads for the short period between sprint planning and starting to work on the first task. And once they were done, the rest of the sprint was sunny.

Putting off unpleasant tasks, pushing them to the end of the sprint, is a great way to gradually suck out motivation throughout the sprint as you get closer to not being able to avoid those task any longer. The total amount of pain felt in dragged out anticipation of that one stressful task is a lot bigger than if it is done right away.

We decided to go one step further and add an estimate of joy to each task – this should capture how much we want to do this task (or how little). In this way, we can order tasks by their joy estimates – that’s the order in which we should work on them. If we stick to this order, sprints become more and more pleasant as we progress, increasing motivation with each closed ticket. In addition, we learn about our joy and pain thresholds, much in the same way as we learn about our velocity by estimating story points.

We are only just starting to do this and we will see if it helps – if it doesn’t, we will stop doing it. For now, talking about and acknowledging the fact that some tasks are unpleasant already feels like a relief.

Bottom Line

The beautiful thing about agile methods is that they are not dogmatic: they invite you to reflect on your own process during the sprint retrospectives, and to change your process if it needs to be changed.

The result is that every team has their own style of agile, and that style keeps changing as the team and circumstances change.

That is a good thing.

If the only conclusion you take from this text is that it is a good thing to fidget with your agile methods, then I am happy.

What Is a Stand-Up?

Stand-up is short for daily stand-up meeting, which is part of a project management methodology called scrum. Scrum is one of many flavours of agile project management methodologies, which have become the de-facto standard for project management in software development.

Agile project management is based upon the principles of iterative improvements and cross-functional self-organising teams. The term agile was coined in 2001 through the publication of The Manifesto for Agile Software Development which laid down four core principles:

  • Individuals and Interactions over processes and tools
  • Working Software over comprehensive documentation
  • Customer Collaboration over contract negotiation
  • Responding to Change over following a plan

Scrum lays out a specific methodology on how to apply the agile principles to daily organisation of software development. The scrum methodology defines different roles of people who are active in a development team, and describes a number of activities which should be conducted regularly to organise and plan work.

Scrum in bullet points:

  • Project teams are cross-functional. This means that they are made up of people with different skill sets and as a team should be able to deliver all activities that are required to deliver a project.
  • Project teams are 3-9 people. If a project requires larger teams, it should be broken down into smaller sub-projects which can be delivered by a team of 3-9 people.
  • Each project team works with a product owner, typically the customer, who works closely with the team to define requirements on a continuous basis.
  • Projects are delivered in sprints. Sprints are time boxes, which can be anything between one week and one month. The most common sprint length is two weeks.
  • At the beginning of every sprint, the team meets for sprint planning, during which the team defines the to-dos for the next sprint – together.
  • During the sprint, the team meets every day for a short (15 minute) stand-up meeting where each team member briefly says what she did since the last stand-up, what she plans to do until the next one, and if there are any blockers or problems that might hinder her progress.
  • At the end of the sprint, the team meets with the product owner for a sprint review, during which the team shows what they have achieved during the sprint.
  • Goal is to always have a working product (software) at the end of each sprint, with new features which can be demonstrated to the product owner. This drives frequent releases and the development of minimum viable features. Through this, the entire team and the product owner can “see and touch” the result and it is possible to change direction and make changes during the process.
  • At the end of the sprint, the team meets for a sprint retrospective, during which the team discusses what went well during the last sprint, and what could be improved. In this way, the team improves their way of working together continuously.