The agile manifesto is well-known in the software industry. Although sometimes forgotten or misunderstood, the manifesto in itself is simple:

Individuals and interactions over processes and tools;

Working software over comprehensive documentation;

Customer collaboration over contract negotiation;

Responding to change over following a plan;

That is, while there is value in the items on the right, we value the items on the left more.

Given only the agile manifesto, how can we use this to create a complex product like software? I will try to lay out some steps you can take and use the agile manifesto for justification.

The very start

Where does work start on a complex product? Is it the exhaustive analysis of the market and the to-be product? According to the agile manifesto, documentation is important. However, working software is even more. But we can't just start making software. We are missing something: a sense of direction. What do we want to make? Who will be our users? How will we help our users?

Here's something we can do that follows the agile manifesto to get a starting direction: we'll look for some potential users and ask them, or delegates of them, to join us in a feedback meeting. This meeting will take place after a certain time, where we will present our goal through working software and ask whether we are on track with creating a product that helps and satisfies these users. For this, the users or their delegates will need to collaberate with us. We need to be able to ask them questions and they need to be able to provide feedback to us.

To get this collaboration, we might need to negotiate something. Think about it this way: what's in it for our users to collaborate with us? While the agile manifesto encourages customer collaboration, we might need some negotation here. Please note that this negotiation should never be about what we will make or by when we will make it, rather about how we can collaborate and what's in it for everyone. We really need our users so don't be greedy during these negotiations. Early access to the prouct or even free lifetime access are ways to persuade people in providing valuable feedback for our product.

The first goal is the hardest

We have found users or delegates for them. We have set a meeting in the future where we will come together and review our direction. The direction is... something. And we choose that as a team because we want ownership by everyone. We want collaboration, not just some people doing their 9 to 5 because that's what their contract tells them. We know the review meeting is planned, what can be done in the coming weeks so that we have valuable input for this meeting?

It is okay in this stage to craft a plan. Like the agile manifesto says, there is value in following a plan. There's just more value in responding to change. The entire team should feeld comfortable with this plan and there should be a clear goal as to what we want to accomplish. What will our working software do so that our users get something valuable from it?

This first goal is the hardest to come up with, but it is very important to have one. It should reflect the direction that we've chosen. It allows us to craft our plan: what work do we need to succeed at this goal? What is nice-to-have? What is completely unnecessary? Do we have all the necessary skills and knowledge to develop our first iteration or do we need some extra input? Who is good at what and how do we build the best possible software to meet our goal with what we know at this moment?

Inspect and adapt frequently

Starting work out of thin air is very hard, that's why a plan is very handy. History has thaught us that humans are very bad at estimating how much work something is going to be. So the chances are high that our team will not be able to execute our plan completely. Note that this is okay. Frequently, the team should come together and review the plan. Are we still on track to reach our goal? Can we adjust the plan to make sure that we reach our goal? Do we need to stop working on certain things and help each other out?

To establish a good connection with the team and to make sure we can adjust our plan as soon as possible, it is advisable to do this daily. For simplicity, some might tell you to do this at the same time every day and at the same place so that everybody knows when to review and refine the plan. In essence, it is important to have this moment and to adapt to changes.

In doing so, we'll be able to create software that satisfies are goal. We'll drop features and change scope along the way until the moment where we have our review meeting with our users and their delegates.

Changing direction

When the review meeting comes, it's important to have everyone in the meeting. The entire team as well as the users or their delegates. This transparency and openness allows us to require less documentation. While it is very useful to have some notes written during the meeting, first-hand feedback is always more powerful. So, time to begin.

Are we creating something that is useful? Is the competition so far ahead of us that it's no longer necessary to create the product? What is the impact the product has on its users? These are the questions you want answered. Sometimes these questions will not be answered because our users just don't know. This might mean that we are missing certain types of users, or that we can keep going in our current direction to learn more.

Whether or not we change direction is decided in this meeting, with everybody's consent. Also, the new direction is clearly stated and we will plan a new meeting in the future to review whether we need to adjust this new direction. The new meeting will be planned within weeks rather than months, because it is important to respond to change from any external factor.

Some notes on processes and tools

An important observation might be that we have not yet discussed processes or tools. We should, as a team. While individuals and interaction are more important according to the agile manifesto, there is value in processes and tools. We have worked out a way to come up with a plan together, to set and change a direction together, and to create working software according to our goals (and we did that together too).

However, in our organisation there might be processes and tools that we can or must use. And it's important to reflect on this. How have these tools and processes helped us? What can we learn from the past to improve the way we work? Can we improve our processes and tools to support our work even better?

These discussions need to be held, because without them we are stuck following a plan that somebody laid down for us. We don't mind following a plan, but we want to adapt the plan if we find better ways of doing things. Therefore it is useful to sit together with the team and review what tools or processes can be improved, brought in or dropped altogether.

Repeat

Now that we have a new direction and changed some processes or tools, we can sit together and find a new goal. We have a new meeting planned with the users or their delegates and we want to be able to find out whether our work is still going in the right direction. So we'll set a new goal to enable us to verify that. And we will create a plan so that we know how to reach this goal.

We will refine our plan daily based on the knowledge we gather during our daily work. When it is time to hold the review meeting, we will have working software that allows us to verify whether we are going in the right direction. We will ask the same kind of questions: are we still creating something that is useful? Is the competition so far ahead of us that it's no longer necessary to create our product? What is the impact our product has on its users?

We keep hold or change direction and plan a new review meeting. We sit together with our team to share what we learnt on processes and tools, and adjust if necessary. And then we repeat this all again, iteration after iteration.

Budget

Creating software (which is a complex product) often happens in complex environments. People work together as a team to create features or improvements. These teams can be co-located or work remotely. The budget needs to come from somewhere, so some company is backing up the team. But they want a return on their investment, and they want it sooner rather than later.

This can cause stress and make us resort to the old ways of working: setting deadlines for fixed scope that are impossible to reach; monthly (or more frequent) status updates to management to showcase where the money has gone and constant begging/negotiating for more budget.

Get delegates from management to join the review meeting. Add them so that they understand what we've created, as well as why we are changing direction all of a sudden. Don't be afraid to speak up to them because they are not afraid to do the same. But make sure they understand the review meeting is a collaborative meeting. It's not about negotiations!

Simplicity by rhythm

Planning meetings with many people can also be considered a complex task. If we want to make it simpler to plan these recurring meetings, a good idea is to plan them at a fixed frequency. This can be two or three weeks, depending on how fast you require a change in direction. If you don't know how fast you might require to change, a shorter cycle is probably a safer bet than a longer cycle.

This new way of working might be completely opposite to what the rest of the organisation is doing. If so, it is useful to have someone in our team to keep track on why we are doing what we are doing. Why do we make a plan and refine it daily? Why do we review our direction and our working software after some period of time? Why do we deviate from our organisation's processes rather than following the stream? It would be great to have someone in our team to coach the team, as well as the organisation that we need these steps to ensure we keep following the agile manifesto.

Did you notice

I have been talking about Scrum this whole time? Scrum is a lightweight framework to help create complex products. It's meant to support teams in dealing with changing markets, technologies and customer feedback. I hope this blogpost has shown you that it indeed follows the agile manifesto and that is meant as a guide to help you through your specific situation.

Yes, I know Scrum also talks about things like the Product Owner, Backlogs and Artifacts. Everything explained in the guide is either based on adhering to the agile manifesto, on adhering to the Scrum Values (Commitment, Focus, Openness, Respect, and Courage) or on making things simpler. For example, you don't necessarily need a Product Owner to follow the agile manifesto. Yet having this role explicitly makes it simpler for everyone and allows one person in the team to have focus on those specific tasks.

What do you think? Is there some truth in this or have I completely missed the ball?