Product Management
Translating the Agile Manifesto
Looking at the Agile Manifesto as a guide rather than gospel
About ten years ago, Agile Software Development was the hot phrase in many tech industries. Agile is a set of methodologies and practices used by builders of software that suggests a flexible and iterative approach. The core values of Agile include valuing individuals and interactions, building working software, customer collaboration, and responding to change. These values enable people and teams with various backgrounds and skills to find a common ground in software development, in order to tackle large, difficult engineering challenges.
Although Agile can trace its roots back for several decades, the methodology really started to gain traction at the turn of the 21st century. In 2001, the Agile Manifesto was famously created in Snowbird, Utah. And later in 2009, the Scrum Alliance was formed which established certification programs for practitioners of Agile. Numerous other entities have been established, while many books have also been published on the topic of Agile methodologies. The sheer volume of individuals that are currently practicing Agile means that there is a great deal of variation among teams.
I have worked in four different organizations that practiced some form of Agile. It’s fairly common these days. However, each of the four organizations have used different aspects of Agile, with varying degrees of discipline, in order to build products. The important thing to understand about Agile is that there is no one size fits all when it comes to adoption. Despite the widespread use of the framework, most teams would not be successful if they were to implement every element of Agile to the letter. Just as Agile preaches flexibility, so too should teams and users incorporate a flexible approach to Agile.
Austin Govella wrote a compelling piece on rewriting the Agile Manifesto. The premise is that the manifesto doesn’t take into consideration the real-world circumstances that all teams must navigate. However, rather than rewriting the manifesto, let’s take a look at some of the ways Agile’s core values can be interpreted and applied:
Individuals and Interactions
Individuals and interactions over processes and tools means adapting your practices for the people involved, rather than allowing processes to overrule logic. Given the best practices and software tools available to teams that utilize Agile, it is easy to allow the processes to overcome the best fit for the people. Instead, you should aim to build a culture of interactions and open discussion in order to foster a truly Agile organization. In my experience, it is important to have a strong development process in place, but it is equally important to know when to bend the rules. For example, measuring velocity of the team can provide visibility into the team’s performance, but if you find yourself taking up significant time to measure the metric, it can be counterproductive.
Working Software
Working software over comprehensive documentation means placing an emphasis on building a product or feature that works, rather than perfecting the elements that surround the software. In development, while there is always a need for more documentation, the nature of iterative, flexible building means that keeping documentation up to date is difficult. Instead, focus on delivering value through the product. I have often used this technique when trying to prioritize my backlog or when debating the value of work with my team. Bring your thought process back to the end user and the need for working software, and you will be successful.
Customer Collaboration
Customer collaboration over contract negotiation means fostering a working relationship with your users, instead of trying to milk every last penny out of your users. I personally don’t encounter this challenge often, but the spirit of the manifesto is still relevant. Products are build to create value for users. Users should be included in a collaborative manner to help improve the product. A successful product that addresses customer needs will be able to be monetized. While you certainly don’t want to ignore the business model or the contractual needs of a product, it is more important to engage users and create a product that meets their needs, rather than negotiate over the nuances of your business relationship with your users.
Responding to Change
Responding to change over following a plan means being ready and willing to change the product roadmap in order to best meet the needs of the customer. Changing costs can be high, but a roadmap is never meant to be a static plan. Many product managers fall into the trap of trying to create a product vision that is a perfect plan for the future. This happens then the demands of delivering a successful product on time are high. One former CEO told me that he expected my roadmap to change over time; if it didn’t, that would be more of a failure than missing a deadline because of change. Agile is predicated on using new information to promote change, quickly and frequently.
The framework that the Agile Manifesto provides is simply a starting point for your team, from which your own team’s processes can be derived. There are a number of ways to adapt Agile to meet your needs, but adaption is the most important piece. The manifesto states it clearly in the very first core value: individuals and interactions over processes and tools. Agile is a process, it is a tool, but it is not more important than the individuals that practice it.
Let’s continue the conversation on Twitter or in the comments. For more on product management, follow Trust the Product on Medium.
