Agile and scrum for non-IT teams

Agile and scrum were invented for software development teams, but these methods are increasingly used by non-software teams. We get more and more coaching requests to help many other teams, and together with these teams we discovered that you can adjust agile and scrum to work for any team.

Getting started with agile and scrum

When we help a team to work using agile scrum, we typically provide two workshops.

1. In a first workshop, we let the team learn and practice with plain vanilla scrum, so that they know how a software team or IT team would work and what all the scrum elements and practices are. This way everyone at leasts understands scrum completely, even if they do not think it applies to their project.
2. A few days later, we provide a second ‘kickoff’ workshop targeted to the specific situation of the team. We help the team get started, and the team decides on their preferred way of working. We will encourage them to choose practices that we think are useful, but ultimately the team decides how they would like to start.

In theory, our role is only to facilitate and the team is in control of their team rules. We help the teams make clear decisions and reach a common understanding of how they would like to work. In practice we do try do help the team with our experience, and make sure certain core agile rules are chosen. These five rules are proven to work for most teams and make sure that we get an ‘agile’ process: a process that does not have to be perfect, but can be improved along the way.

Rule 1: clear team

Agile was invented as a method for software teams to work better, and at the heart it is a method about teams. In many non-agile projects, there are too many roles and people that are needed but that are not truly involved. In agile and scrum, team-members are expected to work on one project only and attend all the meetings. As a reward, they get to vote, estimate and decide how to work. Other people are demoted to stakeholders: they will be updated often and can provide input, but cannot decide how the team works.

Rule 2: iterations

In Agile, teams planin iterations: rather than having one big plan that delivers a lot at the end of the project, the team delivers whatever they created every two weeks so that it can be reviewed and ideally used by the stakholders. This iterative way of working increases transparency and reduces risks. To use this way of working in non-It projects, some flexibility is required. Non-IT teams work on many different things and may deliver marketing material, interview reports, flyers, designs, text or other results. The project sponsor or stakeholders will need to invest some time to understand the role and format of each deliverable so that they can provide useful feedback.

Rule 3: Recurring meetings

One of the most useful ideas from scrum is the idea of making all meetings recurring. One-off meetings are often less effective since people are unsure about the agenda, participants and required preparation and because it is hard to plan such meetings. Rather than finding a silver bullet for all these issues, agile and scrum handle this by making all meetings recurring. Every meeting is planned in a fixed rhythm, with the same day, time, location and participants every time. This way no time is wasted planning one-off meetings, and everyone can learn from each meeting and prepare better next time.
Many teams opt to have all scrum meetings: a daily standup, a planning meeting, demo and retrospective.

Rule 4: timeboxes and flexible scope

Many projects have some degree of unpredictability. This is especially true for innovation projects. In classical project management, the scope of a project is fixed and one would postpone meetings if delays occur. For project sponsors this is frustrating: they only know that the project is delayed but cannot ask questions or provide support when meetings are postponed. In agile, the timebox for each iteration is fixed and meetings are not postponed. The teams create transparency by presenting the items they have completed and by explaining why some items are not completed. The project stakeholders know what is happening and can provide input for the next timebox.

Rule 5: retrospectives
In traditional project methods, there is an evaluation at the end of the project but not enough evaluations during the project. In scrum, teams discuss how they work together and how they can improve their way of working every 2-4 weeks. This meeting is useful for all kinds of teams: software teams, non-software teams and even non-project teams.

What to do differently

There are some aspects of agile and scrum that cannot be directly applied to non-software projects. For instance, one of the rules of the agile manifesto is: “Working software is the principal measure of progress”. This is ok for software projects, but does not work for other types of projects. Aspects that are changed by many teams are:

• User stories. Not every deliverable is easily expressable in user stories
• Storypoints. Some teams find estimation in points still useful. Others prefer to plan in more traditional ways.
• Definition of done. Different deliverables have different definitions of done. For some teams it works best to have acceptance criteria per item, not a general definition of done.
• Product owner role. In projects not building a product, it is harder to determine exactly who the ‘product owner’ is.

In practice, all teams make changes and this is ok. E.g. some teams use Lean Startup as a methodology. Ultimately, each team should decide on their way of working, based on their experience. The agile principles and scrum guide are a good starting point, but can be changed if needed.

Thanks to Stefan Leijnen for contributing to this article
Image: Scrum by Olga Guryanova via unsplash