As the 20th anniversary of the signing of the Agile Manifesto has arrived, it makes me look back at how the world has changed over the past 20 years and what it may look like over the next 20.
First and foremost, the use of Agile has grown well beyond software. Some may argue that it has always been bigger than software, however, that was the original focus of the Agile Manifesto, just look at the title of the Manifesto, “Manifesto for Agile Software Development”. Not only has it grown beyond software, but it has also grown beyond commercial organizations as well. We hear agile government, agile schools, agile marketing, agile at home, agile HR, etc. driving the discussion of agile or at least agility. Agile has become a boardroom topic for many organizations. You can even find amazing stories about how people are using Agile techniques and Scrum to help people and families manage ADHD. One such example can be read here.
Should the Agile Manifesto Change?
I would argue that creating a new Agile Manifesto is not needed and actually would be more harmful than helpful. The ideas stand up both over time and outside of software development and anyone should be able to take these ideas and apply them to their context. For example, the principles of the Agile Manifesto may be applied slightly differently:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
Individuals and Interactions of Processes and Tools
As I think about where we are today, this may be more important now than ever. We are trying to break silos, just look how people communicate now compared to 2001, those of us who remember. We type, we text, we instant message, we video conference and often opt for speed and ease over quality interactions.
We can get a quick Slack message out to a colleague and get their response and react to it without a conversation to ensure that we are on the same page. Many years ago, I wrote that, “A picture tells a thousand words, however everyone sees a different thousand words,” and today I would say, “Every instant message has 10 words, and every person reads it how they wish.” This causes breakdowns in communication and interactions and leaves things up to interpretation including tone, intent and more.
Now, look at recent events. People and the world move faster than tools and technology companies ever can. COVID-19, for example, quickly pushed people to have to work from home and children to be educated from home. We could not wait for technology to be fully in place to handle it. We had to think about the people and what was best for them and evolve the technology to meet their needs. In many cases, we didn’t know what their needs were and how they could or would collaborate. Adding to that, forcing collaboration in a certain way could become destructive rather than productive. So, we needed to evolve the technology to meet the needs of the users rather than the other way around.
I would suggest that we go back to this item of the Agile Manifesto and remember why we are placing a priority on it. Remember, the people are who we do things for, and we find ways to learn from the people and interact with them in the end. So, be sure that we understand what they are saying, thinking and wanting and don’t assume.
Working Software over Comprehensive Documentation
Remove the word software and we can apply this to anything we do today. We need to drive toward having something that is “tangible” as that is what people often find most valuable vs. just a lot of words describing it. Having a piece of marketing collateral quickly to review vs. a bunch of disconnected ideas or concepts, applying an idea into something we can share rather for feedback, etc. It doesn’t mean that documentation isn’t important or needed, just consider getting something concrete out there quickly rather than iterating and iterating on some description.
Thinking back to my early days as a Product Owner, I was accountable for data modeling product called ERwin. Now this is a software example, but I think it can be applied to anything. Rather than writing long requirements specifications, I would open up Visual Basic and create examples to share with stakeholders for feedback and give them simple ways to use it. Rather than reading the description, they had the ability to click, dropdown and experience the ideas vs. imagining what I really meant. Not only did this lead to more conversations, but it also created less rework.
Now apply that to marketing, for example. Rather than spending months iterating on a message, get it out there and test it, get feedback on it in context and continue to adjust or refine it. Every time you read something you will find ways to change or improve it. Rather than reading it and reading it and then editing it and editing it, get it out there for real feedback and see if it works and what needs to be changed. Often, I see the longer you wait, the more difficult it is to understand rather the easier. We just get in our own heads and start to assume what people will think instead of asking them.
Customer Collaboration over Contract Negotiation
Building on the previous topic, “Working Software over Comprehensive Documentation,”- this is not just about getting to feedback and clear understanding rather than over iterating on thoughts and ideas, it is also about ensuring you are getting feedback from the right people and that the engagement with stakeholders is framed in the right way. We do not pay for work, we pay for outcomes, for example. In one contract I worked on, we contracted for a small set of Sprints and could add more Sprints over time. This allowed us to get to work and continuously refine what was being built rather than build some comprehensive contract that wasn’t set in future reality and was just based on a single point in time.
The Sprint Review is a great place to see how people are doing and review how many more Sprints you need. Contracting for a solution for a problem that is unknown, or even worse contracting for the artifacts that comprise the process that is going to be used, does not work when you don’t understand much about the problem you are solving or the solution you are creating.
This stands strong today, if not stronger, because things are changing so quickly. We are learning throughout the whole process about potential outcomes and what may be needed to meet them may change. Working in an agile way means that we are constantly inspecting and adapting what we are doing and how we are doing it. So, if we are going to achieve agility, how can we put a contract in place that assumes we already know everything that we are going to do? Defining how you work with others within teams and across them needs to have flexibility and describe more about how you will work, rather than what will be delivered. Just saying that is not what you asked for might make you feel better, but it does not solve the ultimate problem and deliver the value you seek. You need to have abilities to change, evolve, extend or end agreements depending on feedback that is received.
Also, it is important to build the need for customer collaboration (customer can mean many things) into the contract. Enable customer feedback as part of the agreement and empower the team working via that agreement to change and adjust course based on that feedback. It doesn’t mean you don’t have a Product Goal, but it means you have the ability to shift, pivot or change over time and expand, reduce or end the agreement based on what is learned.
Responding to Change over Following a Plan
Work can be complex and often deals with many unknowns at the start, which you learn along the way. Plans are valuable but only up to the point that they are right. If they are too forward thinking and concrete, they can create as much waste as they do value. Thus, they provide direction rather than detail and expect that they will change. Form a goal to strive for and allow for setting iterative goals along the way, knowing that the end goal could change as well as you learn. If we are following the ideas behind each of the principles, then we should already be responding to change over following a plan automatically and have this built into everything that we do.
I am listening to the radio while writing this blog which helps me think and write. My listening is the story here, but it gets me thinking to a conversation that I had with someone a few years ago about their talk radio show. They were using Scrum to deliver their show, the show was their product.
As part of that discussion, we talked about their Sprint which was a week long, they set a Sprint Goal for what they wanted to achieve within the Sprint, including the messages they wanted to get out, the guests that they were going to have and what they knew about things that were happening within that week. They didn’t, however, know everything that would happen along the way. Would there be some big news story that required them to replace one guest with another, would a guest not show up or take them down an unexpected path? It didn’t mean that they didn’t have a plan and each morning in their Daily Scrum they would look at the Sprint Goal and how they were on their way to achieving it. What it did mean, however, is each day within that Daily Scrum they would discuss things that may have come up since the last morning that could impact the Sprint Goal and adjust what they were doing to meet it.
Now you may be saying to yourself, does that mean they are changing the Sprint Goal each day and the answer is NO. What they did was stick to a focus point by using the Sprint Goal to do so and put everything into that context. Now that doesn’t mean that something like what happened on September 11, 2001 would cause them to cancel the Sprint much like we would do in a software project, but that is the exception rather than the rule. Keeping a focus and then responding to changes can still get us to the same goal without having a predefined path/plan.
Putting it another way, many of us use Google Maps or Waze to get from point A to point B. Our goal is still to get from A to B, but how we get there may change along the way. Waze knows about an accident or construction and takes us a different route throughout the trip. The goal is still getting to B, but how we get there changes.
Use the Agile Manifesto Concepts as a Guide
Responding to the changes, obstacles or feedback along the way not only helps us get to a goal, it helps us achieve success with higher quality, deliver more value and better meet the needs of who we are delivering for. Yes, the Agile Manifesto was based on software development, but that doesn’t mean we cannot use it as a basis for anything and apply it to how we work or what we do.
Here are some things I take from the manifesto:
- Have a goal for why what you are doing what you are doing and ways to measure the impact of what you may be doing no matter what it is.
- Be willing to accept feedback. Feedback can be difficult to accept, especially if it goes against your initial thinking, however, consider that feedback with an open mind and get out of your comfort zone of what you know and learn from those providing the feedback. That said, don’t just change based on one person’s feedback for example as it may be an anomaly vs. the norm, so be sure to consider all feedback and interpret it.
- Try and get tangible results to get that feedback based on reality vs. interpretation.
- Don’t lock yourself into a plan that cannot be changed or adjusted as you learn.
- Assume that change will happen and be prepared and set up to succeed when the unknown occurs.