The goal with a sprint is not to break a big chunk of work into smaller pieces of work, that you like Lego blocks put together according to an already created drawing. If you do that, you haven’t understood why we work in sprints, or for that matter, not even what agile development is.

Whenever you find yourself using sprints as Lego blocks, the chances are great that you started the project with a big hairy audacious plan which you then break up into smaller pieces that are small enough for a sprint. You see each sprint just as a small part of the plan. Like a jigsaw puzzle piece waiting to be placed at the correct place.

But if you work like this, you really don’t understand what agile development is about. It is never about what you code. It is never about creating a platform, a website, or an app.

It is solely and without exception only about solving problems.

In agile, we take a huge step back from technical solutions, and instead focus on what problems the customer has and what we can do to change how they work so the problem goes away.

We focus 100% on what to do.
We focus 0% on technical solutions.

We ask:

• Who is the customer?
• What problems does the customer have?
• How can we change how the customer works to solve the problem?

The entire agile process is just an extension of these questions. Now that we know who the customer is and what problems they have, we can break the problem down into smaller problems. And these we break down further, until we have problems that are small enough to be solved in a sprint.

We start the sprint by asking what problem we are trying to solve this time, and when the sprint is finished, we check with the customer if we actually did solve it.

But shouldn’t we write code?

Now, you are asking yourself, when are we supposed to write code then? We have to choose an architecture, what language to code in, and all that…

Yes, you are right. And Scrum has of course not forgotten about it. It is just moved to where it belongs. After the problem has been defined. We’re not ready to solve any problems before we know what the problems are. And that is what the sprint is for. Remember that the code is the solution.

Then the sprint starts, and the team throws themselves over the problem and starts solving it with code. It is they who sits on the expertise on how to implement solutions, so it’s only fair that they have the responsibility.

The team does more than write code, they solve problems

I have a hunch that many of you who are used to old school project handling where each person has a role, like developer and architect, sees the team as a collection with developers that churn out code. But nothing could be further from the truth!

A team is actually a problem-solving unit. It is a group of people that makes dreams come true. And with that in memory, let me ask this, can a group of developers handle that? To deliver a solution that the customer can use?

No, of course they can’t. And that’s why the team doesn’t only consist of developers. A scrum team is made up of all the competences that is needed. Architecture, coding, quality assurance, infrastructure, legal and so on. And yes, one person can have may of the competences, and several persons can have the same competence. Together everyone contributes with their competencies towards the solution.

So, how agile is your project?
Do you solve problems, or do you just chase a dream?

— Cheers

Image by fauxels