Agile development and especially its most popular framework Scrum are building the fundament of a lot of software development companies. I assume that most of you are already familiar with Scrum so I’ll only give you a short summary here.

Scrum is a subset of Agile Development which is a bundle of principles and methods that revolutionized the software development process in 2001 and is based on the Manifesto for Agile Software Development. Agile Development is based on multidisciplinary, self-organized teams that create usable software increments in time-boxed periods called sprints. In contrary to other software development processes like the Waterfall method Scrum welcomes changes and is based on iterations. As a result you reduce uncertainties in planning, are able to quickly react to changes and save a lot of money by not wasting time in unnecessary meetings.

Scrum was created as a method for software development and in most companies is exclusively used as such. But when you take a deeper look at the Scrum methods the thought comes to mind that Scrum might not only be a tool for software development but maybe also for a lot of other work processes in a company.

Let me show you how implementing Scrum principles can improve work in almost every team:

1. Time-boxing

In Scrum everything is time-boxed. Whether it is the length of the sprints (2 weeks are very common) or the duration of the daily Scrum meetings (15 minutes). It’s obvious that time-boxing saves you a lot of time but it also forces you to prepare for meetings, focus on important things and plan your work in advance. I recommend to establish time-boxing for every recurring event that disrupts your actual work like team or status meetings and maybe even replying to emails. Just think about how much time you could save by having a time-boxed slot 2 or 3 times a day when you reply to mails instead of being ripped out of your work every 10 minutes.

2. Sprints

Sprints are a time-boxed periods where the actual work is done. If you establish sprints you have an easy way of tracking progress and you can change the direction of the project as often as necessary without already having half of the work done. The most common timeframe for sprints is two weeks because that gives the team enough time to make significant progress but is still short enough to react to changes. So instead of having a team meeting every week or month just stick to the Scrum sprints with the corresponding meetings I’m going to introduce later and you will see that your work becomes a lot more structured and you will actually know what you have done at the end of the month instead of wondering where all the hours went.

3. Backlog

The product backlog in software development includes all the features a piece of software needs to contain. If you are not developing software you can just think of it as a milestone in your roadmap or as an internal project your unit or team is working on. For example a sales team in a marketing company can have „Improving First Customer Contact“ as an internal project or milestone for the first quarter of the year. Their backlog might look like that:

Re-design leaflets

Improve company presentation

Introduce guidelines for first phone calls

Establish regular trainings

etc.

It’s obvious why having a backlog is a great thing, isn’t it? It doesn’t matter if you call it backlog or roadmap or simply todos but if you know what you want to achieve and what your working on it’s much easier to keep track of your progress and report to your boss.

4. Plannings and Dailys

In software development the planning meeting (time-boxed: 8h) is used to define the scope of the next sprint, move stories from the product backlog to the sprint backlog and discuss what needs to be done in the next sprint. When you transfer this to a more general level you can use your planning meeting to look at your general backlog/roadmap/todo list and discuss which tasks are next and assign them to the right people for the job. Now you have your sprint backlog.

The sprint backlog of the sales team can now look like this:

Write case study for e-commerce project

Correct typos

Add picture of CEO to front page

Interview e-commerce project lead

etc.

Now you know what everybody is supposed to work on. To help you plan your work, keep your team members in the loop and get help with potential issues you can use daily Scrum meetings (time-boxed: 15 min) where everybody talks about his accomplishments since the last daily and what he is up to until the next one. One of the huge benefits of dailys is that you can can get help with problems almost immediately instead of putting it off for as long as possible. In the sales team, for example, Mike has a problem with taking a picture of the CEO because he is on a business trip and Mike can not finish his task. One of his team members suggests to use a stock photo of the CEO instead and now Mike is on track again.

5. Reviews and Retrospectives

After every sprint you want to know what your team achieved, show results to team members and your boss and talk about improvements for your next sprint. In a strict Scrum environment their are two separate meetings: Sprint Review for demonstrating the usable software increment and Sprint Retrospective for talking about improvements and impediments. Depending on what your doing, how big your team is and how much time you can spend you can decide to have only one meeting for both. In my example, the sales team can now show the re-designed leaflet with the case study, the interview and the picture to the whole team and the boss and gather feedback. This is also a good moment for the boss to give the team credit for what they achieved.

In the retrospective, they might discuss that it took an unnecessary amount of time to grant Mike access to the stock photos and decide to ensure that everybody has access before the next sprint begins (impediment is resolved).

As you can see, almost every team and department can benefit from integrating those basic Scrum principles in their daily work, regardless of whether they are developing software or not.

The only thing you really need — and in my opinion also the most important requirement when it comes to Scrum — is a self-organized team. All those methods and principles will not work if your team members aren’t confident enough or simply aren’t allowed to make decisions on their own, aren’t organized enough to plan their work and don’t live teamwork.

Take a look at your work environment, your team and projects and decide if you give Scrum are shot. I promise it is worth a try and you will be surprised by the effect it has on your and your teams work.

I’d be happy if you share your experience and let me know what worked for you and what didn’t.