Where to start if you want to organize yourself based on Agile ways of working?

I think we need a new name for this. To me, Agile is no longer just a way of working to achieve more agility. In my opinion it never was but that is how this way of working got popularized. The word Agile enabled a way of working that is more human to spread though companies. Innovative teams first adopted this way of working because it provided more agility, it provided a way to respond faster to change. That is where Agile ways of working first shined. But its value is much bigger than that. Any team can benefit from the principles and methods of Agile ways of working, even if you are not doing innovative projects.

Cut the work up in pieces with user stories

Agile created agility not by cutting the work into small pieces. That was also done by Taylor in his Scientific Management way of working. That is basic project management. If you want to do any project, any job, the first thing to do is to cut the work up into pieces. What a method like Agile Scrum did was cut work into pieces in a different way. It cut work up into user stories. User stories articulate the needs of a user. What that does is it takes away the focus from the solution. Most ways of working get stuck, are not creative, are not flexible because they focus on solutions. Someone has a problem and they ask you for a specific solution. In most cases, the one with the problem doesn’t have enough knowledge to determine what the best solution is. You want to leave that with the experts to get the best solutions. If you formulate the need in a user story, you open up space for creativity. A need can be met in multiple ways. With a user story, you spark the creativity of the one that needs to solve it.

But that’s not all. Because a user story can be solved in multiple ways, ranging from a Minimal Viable Product (MVP) to a full blown solution, this makes the chunks of work flexible in size. And that is wonderful news for planning. If you want to plan the development of solutions, these are relatively fixed blocks in your planning. If you want to solve user stories, the blocks of work are relatively flexible and easier to plan. There are typically multiple stakeholders that have needs so flexibility allows you to better meet the needs of the stakeholders. The focus on user story thinking also increases the chances that you find out different stakeholders have similar needs. And if you can combine needs into a solution, you become more effective.

The skill you need here is to learn to ask, to find better questions. If someone comes to you with a solution they want, asking why five times is a good place to start.

Prioritize based on a value and effort

If you asked the right questions and have cut the work up into user stories, the next step is to prioritize the work. If you want to avoid authority bias, the prioritization the needs of the Highest Paid Person’s Opinion (HiPPO), you need a shared vision to prioritize.

To prioritize, you need to be able to assess the business value of the things that can be done. There are many ways to prioritize work but one of the most used is the Weighted Shortest Job First (WSJF) method. This model starts with mapping business value against the size of the job:

This gives you a first segmentation of the different pieces of work that can be / need to be done. Typically you want to focus on the Quick Wins first because they create the most value with the least amount of work. The risk of this method is that critical tasks remain un-prioritized because they are too big for instance. The WSJF method adds time criticality to this to prevent you from postponing time critical tasks by adding the cost of delay. Cost of delay is a complex metric so I would start with the value vs effort matrix and then identify tasks that are time critical.

You see here also that you can turn big projects into quick wins if you can make the jobs smaller, the MVP thinking, you can create value quicker.

But to determine the business value, you need a vision. The business value is often hard to determine. A way to fix this is to do that collaboratively: to get together with all stakeholders and collectively determine the business value in a workshop. Anther way (that can be used alongside this) is to develop a clear, shared vision: what do we want to accomplish with this team and how does that tie in with the overall vision of the company? What is the purpose of the team? Why do we exist? The thing that gets us the closest to the goal has the most business value. In practice, I see these three methods of determining business value used together:

• How much money do we save or make if we build this?
• Can we collectively estimate what has a higher business value?
• Does this get us closer to the goal?

From the what to the how

On the other axis of the value-effort matrix is effort. If you have cut the work up into pieces, you also need estimates on how much work it is. After you have created a user story, you come to a proposed solution. That solution needs to estimated by the people who have to build the solution. They might need some additional requirements and acceptance criteria but you determine them together. The people who have to build the solution are involved in the design of the solution. A proposed solution can be a starting point, but the expertise of the people building the solution is used to determine possible solutions. A user story is the what, but the people building the solution are responsible for the how. This not only empowers the people that have to build the solution but also enables you to leverage their expertise to come to the best solutions. A good what, a good user story, sparks the creativity of the developers. Here the vision, the why, also helps to give context and help people see the bigger picture.

The vision needs to be determined with the stakeholders and users. The vision is typically that what provides value to the users (desirability), and what provides value to the business (viability), and what is technically possible (feasibility). So to determine the vision, the business stakeholders, the users and the engineers need to come together.

One of the most powerful principles that Agile ways of working promote is co-creation. By trusting the development team to come up with the how, you empower them, spark creativity, and have a better chance of coming up with a technical solution that fulfills the business needs.

Once you have the solution design, you can let the development team create estimates on the effort it takes to build a solution and plot the work on the effort-value matrix. This will create the priority of the work that needs to be done.

Iterations

In Agile Scrum, we call this list of prioritized pieces of work the backlog. This is a dynamic list. Priorities can change, new pieces of work can be added. So this list needs to be managed constantly. To find the right balance between changing priorities and a stable work environment for the development team, people generally use iterations of a couple of weeks (they are calles sprints in Scrum). This means you plan the work that fits in one iteration, that is typically between one and four weeks but can be anything, before you take a look at the new work and new priorities. This creates focus and clarity for the team to work on but also ensures agility if new work and priorities come up. The new work can be planned for the next iteration. Because you have the estimates for the pieces of work, you can plan what fits in an iteration. So the backlog is dynamic but the content of an iteration is fixed.

Roles and rituals

To work this way is highly collaborative and everyone is equally important. There is as little hierarchy as possible. To get started with this way of working, you can sit together with the team to talk to the stakeholders and users, to cut the work up into pieces, to determine the value versus effort and plan the iterations. If you get further along with this way of working, the need for roles will come up at some point. Who is going to talk to the stakeholders? Who will create the user stories? Who will manage the backlog? Who will make sure the process goes smoothly and everyone gets they say and is happy? Who will analyse the business needs versus the technical possibilities? Who will organize the meetings? All sorts of questions will come up if you start to work like this. These tasks can be divided any way you want and should be determined by the team. Scrum has some roles defined that can be useful as a starting point:

• There is a product owner role that talks to the business and users to collect their needs.
• There is a business analyst role that analyses the business processes and technical possibilities.
• There is a scrum master role that organizes the process and makes sure the process is as smooth and effective as possible.
• There is are developers roles that build the solutions.
• There is a tester that tests if the built solutions work the way they are supposed to work.
• There is a designer role that designs how a solution looks, feels, and works.

These roles can be combined and switched but they are a good starting point if the needs comes up to organize the process a little more.

This way of working also needs meetings. People need to come together to determine the pieces of work, the planning of the iterations, the insight into the progress, the ways the process can be improved. In Scrum there are some meetings, rituals, determined that can be used to organize the process:

• There is a sprint planning meeting at the start of every interation to determine what pieces of work are picked up in the next iteration.
• There is a daily standup in which all team members share what work was done the day before, what they are going to do today and if there are any hold-ups.
• There is a refinement meeting to look at the user story and the proposed solution to come to a more detailed solution design and acceptance criteria.
• There is an estimation meeting to determine the effort a piece of work will cost (usually called poker session).
• There is an evaluation meeting after each iteration to a talk about what went good, what could be done better and to determine action points to improve this in the next iteration.
• There is a review meeting for which the stakeholders are invited and in which the solutions are shown to determine if they meet their needs.

Don’t do Agile, be Agile

The most important thing to understand about this way of working is that it’s not about the roles and the rituals. That is doing Agile. It’s about understanding why these roles and rituals exist and playing with them to create a co-creative, empowering process, to create a clear way of working that works for all involved. It’s a way to manage the questions that come to a team both towards the stakeholders that come up with questions and towards the team that needs a clear and democratic and empowering way to deliver value to the organization. If you do this well, this is a wonderful way of working. To do it well, you need to be able to see the system and how it affects behavior of people. The user stories, the priorities based on value and effort, the iterations, and the roles and rituals are the basic building blocks of this way of working. You can start small with this and develop this way of working by constantly reflecting on the process. If you have multiple teams working like this, you can also learn from each other. There are things you can read about this way of working like the Scrum Guide but its a practical skill that needs to be developed by constantly improving and learning so an Agile coach is a good idea if you want to grow faster.

Thank you for taking the time to read this essay. I hope you enjoyed it. If you clap for this essay, I will know I connected with you. If you follow me here on Medium, you will see more essays pop up on your Medium homepage. You can also subscribe to an email service here on Medium which will drop new essays right into your inbox. You can also connect with me on LinkedIn to see new articles in your timeline or chat with me there.