This is the second of a series of blog posts introducing agile to people who haven’t worked in this way before. It’s based on my last three years of reading, learning and practising agile ways of working. I’m no expert, but I’ve got a few ideas that may help get you started.

A table with notepads, laptops and drinks with people gathered around it Image by StartupStockPhotos from Pixabay

So you’ve got an empowered team. You’re expected to deliver valuable work early and often. There are groups of people around you ready to collaborate on your work. Your employers have given you the space to respond to change.

Now what?

How you work in an agile way depends on the people you’re working with, what you’re working on and the broader context you’re working in. Agile ways of working will look different in government compared to media, banking or retail.

But there are some common principles. I’ve taken some from Government Digital Service, AgilePM and the Agile Manifesto because they make sense to me in my context working in local government.

Work in the open and communicate often

The running theme throughout agile ways of working is communication. Agile is a team sport that needs regular social interactions to work well. So keep communicating until you think you’ve communicated too much. And then communicate some more! This will help build trust in a new way of working and make more formal, forced communication unnecessary.

This will help you demonstrate the work is under control to senior leaders. Understand their specific communication needs and work with them design something that doesn’t burden you.

Avoid using only one or two communication mediums. People will engage with different information in different ways. Don’t underestimate the power of a well-timed, informal conversation. Experiment with what works best in your context.

See also: Grumpy Old Person Agile and Don’t ask forgiveness, radiate intent.

Focus on user needs

The primary question any agile team must ask is “What are the needs of my users and stakeholders?” They should be always in your mind, if not working with or very close to you. Where the users are outside your organisation, or far away geographically or structurally, you might need some dedicated people to do user research.

Avoid getting requirements from a small group of highly paid people (managers or consultants) or making them up yourself. They are probably not your users.

See also: Learning about users and their needs and Research heresies

Do less and be on time

A hallmark of many agile methodologies is the idea of being on time. This doesn’t mean doing everything you set out to do by the deadline. Rather, it is about doing what you can in a defined period, usually called sprints. At the end of a sprint, you should look back, review what happened and use what you’ve learnt to plan the next sprint. Some teams will schedule the release of things to the user around these schedules too. These sprints tend to be two to six weeks long.

This behaviour encourages teams to do less and focus on getting the most important things done first. It lets teams focus on a defined set of work without losing their ability to respond to change.

Avoid the same work being planned for each sprint repeatedly. It may be too big to be done in a single sprint, meaning that either the work needs to be broken down or your sprints made longer. It could be that the work just isn’t important enough, so you may need to stop planning to do it!

See also: Principle 2: Deliver on Time and The Sprint

Deliver value early and often with small progressive changes

Agile ways of working assume that what you need to do is uncertain, unknown or unknowable. This means that you need to learn and improve as you do the work. Part of the manifesto is to deliver value often.

Combining these two ideas pushes us to deliver value early, often and in small progressive chunks. This means you can gather feedback with which to learn and improve what you do next. By doing this, we minimise the risk that we’re doing the wrong things.

To achieve this, you need to divide your work into small chunks that can be delivered quickly and provide value to your users. Do this regularly and often to build trust and keep learning. Because each change is small, it will have less impact and lets people acclimatise better.

You can communicate this through a show and tell – so even if you’ve not delivered a “thing” (like research), you can show progress and get feedback.

See also: Iterative and Incremental and Making sense of MVP

Collaborate as a team and outside the team

Your team needs to collaborate on their work with each other. Typically this means working regularly in the same space as one group (notwithstanding global pandemics!). Ideally, you’ll be in small groups of 5–9 people to feel like you’re a single unit. They must be empowered to make decisions within reasonable constraints.

To make sure you create something sustainable, your team should include someone from the operational team that will be responsible for the thing you create.

To make sure you keep that focus on user needs, your team should include people who represent the users of your thing. This could be internal users, the client or user researchers to represent external users.

Realistically, your team can’t possibly include everyone with a stake in the work you’re doing. There will be people whose expertise or consent you’ll need at only certain points. These people tend to be in central functions, like IT, Audit, Finance, Procurement, Legal, Governance and HR. Bring them into the edges of what you’re doing, keep them informed and get them involved when they need to be.

Avoid being too demanding of your organisation too soon. People need time to be comfortable with delegating authority. Those central functions are busy, so don’t overburden them with collaboration. A new team will need time to settle, so build this up over time.

See also: Here are the 7 skills you need to collaborate in government and Introducing multidisciplinary teams at the Croydon Digital Service.

These common principles will help get you started with agile ways of working at your place. You’ll need to introduce them in a way that makes sense for the people you’re working with, what you’re working on and the context you’re working in. Just like the work, you should review how you get on regularly and make small progressive changes to make it better.

This is part of a series of blog posts introducing agile to people who haven’t worked in this way before.

  1. Agile: a common sense way of working, rebranded
  2. How to work in an agile way
  3. When not to use agile
  4. Making it up as we go