Some Thought On Agile, Scrum, And Design

Saying Agile doesn’t work is like saying a pencil doesn’t work. Agile is a tool. And the goal of any tool is to enhance human capabilities. I have seen Agile fail. Failing to deliver. Failing to deliver quality. If the goal is to deliver the best possible product within the best possible budget, Agile is an excellent tool. But not a simple one. There are a couple of underlying concepts that need to be thoroughly grasped for it to work.

Value creation

One is value creation. Building stuff costs money. Ideally the returns are higher than the investments. At the core of any project is the business case. The goal of a project is to maximize business value.

There are two challenges with creating business value:

• One is that business value is hard to determine.
• The other is keeping it at the center of all decisions despite the fact that it’s hard to determine.

One thing that should be kept agile is the business case. Most Agile practitioners keep the investment fixed during a project. This is practical but unwise.

First of all, upfront investment decisions are made up out of guesswork and assumptions. So sticking with those decisions as the project advances and knowledge grows and assumptions get validated, is not a smart thing to do. Before you start, you have no clear picture of what your money buys.

Secondly, if the money axis is fixed, the business case, learning about the value that can be created with a project, is out of sight and out of mind. Less learning about the most important aspect of the project, value creation, occurs.

Business value is complex and made up out of many moving parts. There is direct revenue from the product or service you are creating and many different ripple effects that are harder to quantify. Products and services operate in complex systems of value creation. Soft things like learning, motivation, mental models, communication value etc that spawn from a project have effects on the system of the organization and its environment. One project leads to another. One project enhances another. Synergy effects occur. Measurable and immeasurable effects occur.

It’s good to keep reflecting on both and build the business case as you do a project. If it’s just about finishing a project on time and budget, you not only missing out on creating value and work under the assumptions that Agile wants to validate, you also frustrate the whole principle of Agile.

Assumptions

Assumptions are key to understanding Agile. The key to Agile is learning. Each project starts with a hypothesis and assumptions. You need test the hypothesis and validate the assumptions continuously. This sounds more like Lean Startup than Agile but I believe you cannot do one without the other. If you are not rigorous in learning, in testing your assumptions, why be Agile?

Business is about risk management and you need to learn as fast as possible to take bigger risks. If you don’t learn, the only way to minimize risking by sticking with known best practices and pray they work for you. If you are able to be truly Agile and learn, you can take much bigger risks because you know more. Risk is about unknowns. Agile is about learning. Risks are expensive. If you fail, you lose money. If you fail and learn, you create a better product or service and make more money. Key to understanding Agile is understanding the relationship between costs, risk and learning.

Transparency and trust

Agile works so well because it is transparent. This starts with admitting at the beginning of the project that you don’t have all the answers but have total faith in you and your teams ability to find them together. Pretending to know is the enemy of Agile. If you are open about what you know and what you don’t know, you can learn more and thus create more value.

Being transparent and open also means allowing other people to come up with good ideas and questions. A good Agile project is an environment of trust where everyone feels safe to speak their mind. It is also pretty democratic. Of course there is the PO but the best Agile teams are the ones where everybody is the PO, everybody feels responsible and the PO is only an emergency fail-safe system.

If everybody can see what the others are doing and how they deliver value, trust is created. In a system of trust, finances can become Agile as well because the budget holder can see more transparently what the investment will get him or her in terms of value. Admitting mistakes, being open to input and being honest are all parts of transparency that need to be honored. This is how co-creation can flourish. This is how high performing teams are built. This is what empowers people on a team.

User centeredness

One of the ways that Agile creates value is that it puts the user central to everything that is built. Agile works with user stories that are written from the perspective of a user. They are also tested from the perspective of a user.

Most people understand that being user centered is key to creating value but putting this to practice is hard. User centeredness is easily misunderstood and easily killed.

User centeredness is not simply asking what the user wants and building that.

User centeredness is no excuse to have no product vision of your own.

User centeredness is no excuse to let business and technological concerns fall off the table.

User centeredness exists at the tension between user needs and product vision, between user needs and business and technology needs.

A risk of user stories is that they are seen as a safe guard against building the wrong things. Just having user stories doesn’t guarantee that user will like and use your product, let alone that it will generate business value. Trusting user stories to make your product good is a common mistake.

User stories are also very unspecific. That is a strength and a weakness. The strength is that is allows room to move, to built things in different ways in order to react to progressive insight and budget decisions. The weakness is that they are so open to interpretation by the builders that they run the risk of missing the mark completely. User centeredness is something that must be monitored constantly by the entire team.

MVP thinking

User stories become powerful when you embrace MVP thinking. Minimal Viable Product thinking. MVP thinking is not about making the minimal product that just barely works. MVP thinking is about thinking what is most important and about smart ways to achieve goals with minimal investment.

Thinking big is good. But most people don’t think big enough when it comes to value creation and possibilities and think too big when it comes to user stories. User stories have in them the flexibility to build them in large and expensive ways and in small and smart ways. Thinking about how to built a user story is a constant creative endeavor in an Agile project.

It starts with thinking in terms of delivering working products per sprint. The question of what is the minimal functionality we need to have a working product is a question you need to ask every sprint. How small can you make each user story? How smart can you solve each story in relation to the other stories? It’s constantly redesigning the product based on progressive insight and progress in the project.

The whole idea that developers can built a product based on a design is totally not Agile. Designers needs to be on board constantly to redesign aspects, functions. If you do not incorporate progressive insight into redesigning your product, you are not leveraging the power of Agile.

Rules are for fools

The first principle of Agile is people over processes and tools. Everyone that is using Agile Scrum as a straight-jacket is transgressing against the first rule of Agile, the core, the fundament. Agile Scrum has rules, it’s a method. But blindly following the rules is not Agile. Using the rules to bend a project to your own will to stay on budget and deliver on time at the expense of quality is not Agile. Tools should always be in the service of people and the goal of projects: to deliver quality, business results. Following the rules of methods like Agile Scrum is easy. Using them as a tool to create high performing teams is hard and requires deep understanding of the underlying concepts and the ability to improvise and mix it up with other methods. I am also just scratching the surface here.

“Rules are for the obedience of fools and the guidance of wise men.” — Douglas Bader

Thank you for taking the time to read this article. I hope you enjoyed it. If you did, don’t forget to hit the clap button so I know I connected with you. I will dive deeper into the topics of Design Leadership in upcoming articles. If you follow me here on Medium, you will see them pop up on your Medium homepage. You can also connect with me on LinkedIn to see new articles in your timeline or talk to my bot at dennishambeukers.com :) You can also find me on Instagram.