by Emily Richardson Hemphill | 3 Minute Read
To start things off, happy 22nd birthday to the agile Manifesto – the manifesto that is the core of Agile. Most everyone agrees with it, and almost everyone wants to achieve it. However, just saying it does not mean you are practicing it.
Have you ever really sat down and thought “how do we practice the manifesto?” I am going to break down the manifesto and how it is used in practice but first, let’s review the manifesto:
The Agile Manifesto
As documented on agilemanifesto.org:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
While there is value in the items on the right, we value the items on the left more.
Individuals and Interactions Over Proceses and Tools
Value Overview: Often in practice, you will see this value come to play within a few roles such as the designer or the product role. However, to make it happen, there must be an environment that allows opportunities to have interactive and meaningful interactions. More often, individuals get the requirements and go straight to writing user stories. To truly embody individuals and interactions over process and tools, it’s prudent to have discussions about who the user is, how we relate to them, and what’s valuable to them. The best way to do that is to interact with the user or user group and understand them, their desires, and create a space to collect those observations.
In-Practice Example: Fred runs an ecommerce site for a large home décor store. He received feedback from a customer via email to add a button to copy the site’s address, so they do not have to repeat it via e-mail. Instead of taking the feedback and creating a requirement, Fred decides to reach out to other users and learn more about the current process. Once he gets the feedback, he reviews it with his development team and realizes that the button may only be a band aid for the problem, but they can automate the process, which will not only fix the issue but also create a better overall experience for the user.
Working Software Over Comprehensive Documentation
Value Overview: As the world is adjusting to Agile, we are beginning to see a working product much faster than before, but how do we ensure we truly practice “working product over comprehensive documentation?” Prior to the work even getting to the engineering team, the product team must help define testable narratives about what’s valuable to the customer, so when the iteration completes, they are validating the working code or product that the customer wants. As the work progresses through the development process, it is important that the team keeps that narrative in mind. It is the entire team’s job to ensure that they are not just building working software to build working software, but that they are building working software because they want to know something at the end of the iteration to help inform what they will do next so they can ensure to deliver value to the customer.
In-Practice Example: Let’s go back to Fred and the (not so needed) button. The documentation around the request was detailed: it had the placement, the design, and the action the end user wants to take. The team again, could have used this documentation and implemented the button. However, they wanted to ensure the customer had superior quality software, not just software that works, iterating on the idea testing it through user interviews and iterative development they were able to deliver a much superior solution.
Customer Collabortaiton Over Contract Neogtiation
Value Overview: Contracts are generally broken down into detailed tasks with specific dates and with the expectation that those dates and tasks will be met and completed. However, this approach can bring up a couple of concerns. One concern is your plan likely will not be perfect and will not predict everything that comes up. Two, you may only get the exact requests in the contract, rather than ensuring those working on it will ensure they deliver what’s truly valuable to the customer. So how does one work around this rigid contract? It is important to create vivid narratives about what success will look like and give the team enough time to know how to get things done and effectively plan out the time it will take based on frequent interactions with end users, and observations of their working product.
In-Practice Example: If Fred had taken that requirement and the details that came with it, the team would have implemented it just as asked. Fred and the product team would not have collaborated with the end users and the team would not have collaborated on how they could carry out the goal. This also would have affected what would have been delivered and that superior product and streamlined process would have never been delivered.
Responding to Change Over Following a Plan
Value Overview: I’ll never forget when I first read this value. I thought “wow, I don’t need to plan a thing.” I was young and naïve and quickly learned it is not about “following a plan,” but embracing change into your processes and identifying when a change needs to be made, and what direction you should be going. Responding to change does not mean, “I have an idea let’s go do that” but instead replacing the implicit ambiguity of a highly detailed plan that’s generally, dare I say it, out of touch with reality, with a process that allows flexibility, adaptation, and redirection when needed.
In-Practice Example: As the team began to implement the automated process, they ran into an issue. They realized that although they talked through everything, they missed an issue that couldn’t have been known until they started working. Instead of halting all work, they collaborated, adjusted, and determined a new way to implement the same streamlined process. This approach allowed the team to not get blocked due to an unknown issue but instead, pause, evaluate, and change direction.
As Agilists, we are more likely use the Manifesto in our daily life, but it is nice to sit down and think through “do I actually practice this?” In conclusion, I know as an Agile practitioner I hear it, I talk about it, and I often share it – but a lesson to remember is not just the values themselves, but the principles and how we can understand and apply them in our everyday execution practices. So, with that said, Happy Birthday to the Manifesto! I’d love to hear how you practice the manifesto, leave a comment below!
