When you work on developing a product on your own, you work from an internal set of rules. These are guidelines that you’ve honed over the years as the best way to be productive. But there’s a big difference between working on your own simple project and coordinating one with a team. With teams, it’s best if there’s a good process in place — and in our world, we typically follow an Agile process.

Seeds of Development in the Agile Process

You can see the seeds of the Agile process in your own individual process for getting work done. When you work on your own, you know what has to be done, setting out to achieve a set of self-imposed goals that are both intuitive and manageable. No problem. No coordination, no meetings.

At some point, you’ll probably need a task list because you won’t be able to remember everything you planned to do. You’ve just created the backlog.

When things get rolling and the project grows, you might bring someone on to help you out. You’ll have to coordinate everything, dividing tasks between the two of you. It all starts out casually, with just a tap on the shoulder from your new colleague saying, “I’m free now. What should I do?”. You’ll give an answer and they’ll get to work on the next task. You divide the tasks so that your path of work does not collide with theirs. You’ve just invented the task assignment.

Both of these process elements add value to the development process.

• The backlog serves as both a history of what you’ve done and a roadmap to what lies ahead.
• The task assignment keeps the project and the people organized.

So far, so good — as far as making sure the process is lean and efficient. We haven’t added too many management layers and the process is still simple and intuitive. But what happens when you need to plan, add more people, and create roadmaps? And what happens when it’s time to meet with stakeholders and show them what you’ve done so far? This is where inexperienced teams might take the wrong path, veering away from Agile and more toward bureaucracy.

Next, we’ll continue unfolding our simple project, taking it from two people to more, and incorporating additional layers to the process. This should show you how you can organically build an Agile process for your team, making sure that each step adds value, not bureaucracy.
Let’s continue.

Unfolding Scrum Development, From Planning to Roadmaps

Now let’s say your product is coming along nicely but you’re noticing that one of you is taking a lot longer to complete their tasks than the other. This is creating a bottleneck because the faster worker gets stuck waiting for things to move forward. So you plan and agree on a schedule to keep things rolling along at an acceptable pace.
This allows each of you to plan your week, which becomes especially important when you start scheduling meetings with stakeholders for demos. Maybe you create a special backlog just for each week. You’ve just invented sprint planning.

Since you’re now a team of at least two people, you find it helpful to meet at least every couple of weeks and review the project’s status. These meetings are an ideal time to review and fine-tune the product backlog, just to make sure everyone’s in agreement on everything. You’ve just invented Backlog Refinement.

All the while, your stakeholders are wondering what you’re up to. At the end of each sprint, you want to show your stakeholders that you’ve achieved the goals you set out to achieve. And if you haven’t met some of those goals, you figure it’s better to be transparent now, so that later on, if bigger problems arise, they’ll know why. They’ll also see how close you are to producing a deliverable. You’ve just invented the stakeholder demo.

At some point, you’ll be very close to “completing” various deliverables. But you’ll want to gather your group and review and review everything before you declare anything ready to show outsiders. After a few reviews, the team might discover that their process needs some tweaking or their methods need some adjustment. You’ve just invented team retrospectives.

Finally, there will be more sprints as you work toward the release date, or the state of being “done” (although we all know that software is never really “done”!). Now that you’re deeper in and you’ve had feedback, you can more easily envision the work that you still need to do. You might even have various projects going at once, each contributing one piece to the overall product. There are a lot more dimensions to think about now, so you start visualizing the Big Picture, imagining all the moving parts and how they’ll come together. Based on this, you’ll schedule your future sprints, perhaps juggling those multiple initiatives, keeping track of which goals are required at each point in time, and how that relates to sprints. You’ve just invented the roadmap.

Each Step Adds Value, Not Bureaucracy

You might notice that not at any point you have added bureaucracy — you truly added each “rule” only because it added value to your process. It helped you and your team to go faster and it prevented mistakes. You now have a full-grown process in place. And it is agile, since every part can be replaced if it doesn’t add value. Every part adds and so it justifies its own existence.

None of these processes is bureaucratic. Each exists because it adds value. In fact, any process should be removed when it doesn’t add value anymore — or when there’s value subtraction.

What’s more, team members are involved in each step of the process, collaborating and making decisions together based on the trust they’ve built in the group. In a nutshell, that’s the opposite of a bureaucracy, where a disengaged workforce is simply being told what they need to do, when to do it, and how.

So we hope that this has helped you see that you can be agile and you can have lots of processes — these things are not mutually exclusive. If you’d like to hear more about the Agile process and how we see it at Making Sense, check out this recent post that’s about Software Architects and the Agile Manifesto.