1.1. The Case For Agile: In The Beginning…
In February 2001, seventeen software ‘pundits’ attended a three day retreat in Utah. Here they discovered that they had very similar principles of how software should be built, how teams should work with and for their customers, and the values which underpin everything they do. Excited by where their discussions were taking them, they decided to document these values and principles. We know them today as the Agile Manifesto. The values of the Manifesto are as follows:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
There’s a high chance you’ve seen these before. Nevertheless, they are worth revisiting, if not only for the fact that they form the basis for upcoming posts in this blog series. A key reason this manifesto has endured is because it is open-ended enough to be applied to more than just the act of writing software. It is a call to all players: engineers, CEOs, middle-management and anyone else involved in the art of creating products.
Let’s take a brief look at each value in turn to get an understanding of the types of problems the seventeen signatories of the Manifesto were hoping to solve.
1. Individuals and interactions over processes and tools
Many organisations can fall into the trap of setting up processes to facilitate communication. Take for example a member of the test team who has verified a bug has now been fixed. Rather than being able to simply inform the developer that the change can be released, they must update statuses and provide supporting comments in workflow systems. The Manifesto recognises that such reliance on processes and tools cannot hope to scale across disciplines, teams and departments. This troubling reliance really reaches its nadir when the business suddenly needs to work in a different way to stay competitive. Unlike processes and tools, individuals — engineers and non-engineers alike — are the ones that can best respond to the changing landscape and drive the initiatives needed for the company to stay competitive.
2. Working software over comprehensive documentation
Traditionally, the act of developing software is driven by documentation at every stage. From contracts to specification documents to designs and requirements, and then eventually to Gantt charts and project plans, vast amounts of money and time can be spent before a single line of code is written. Agile looks to shift the balance the other way. As such, teams and organisations look to write just enough necessary documentation to create working software. Through this, the business and customer see benefit early.
Of all the values, this is the one which is perhaps most ripe for being rewritten: working software should not be the aim, but rather valuable software. Lots of software teams write will compile, pass acceptance tests and scale beautifully; whether or not users are willing to invest time and money into them is an entirely different matter.
3. Customer collaboration over contract negotiation
In a non-Agile setup, the business interacts with the customer to gather requirements, forecast completion dates and negotiate costs. The next time they interact, is when the software has been written and payment is being sought. In between all this, the actual product or feature is created. This period of silence between the business and customer bears clear risks: the finished product may not exactly match the requirements in the contract, leading to withheld payment and re-work. Or worse, the product may match the requirements perfectly but end up being entirely ineffective for the customer. Instead, this Agile principle looks to turn the customer into a collaborator whilst the software is being built. In this situation less emphasis is placed on lengthy, upfront negotiations and more on liaising with the customer as an ally throughout the development process.
4. Responding to change over following a plan
If there’s one value which most of us reach for when asked about Agile, it’s likely to be this one. On first reading, it’s easy to think this value encourages flexibility in the project plans we create to steer our work to completion. But, like the other values, there is a wider scope at play: a founder of a startup will do well to not be fixed on a rigid business plan and find ways to adapt to the learnings they gain, and a leader at a Fortune 500 company would need to ensure they are able to adapt to any changes or disruptions in their market to maintain a competitive edge. If instead, we stuck to a fixed plan of how we run our businesses, teams and development efforts, we would miss out on vital opportunities for innovation, growth and in many cases, survival.
However, this value comes with a warning: responding to change is important, but for it to be truly beneficial, the change must lead to a more valuable path. The tactics and approach required to recognise such routes and discard others is essentially what Agile methodologies aim to solve; we’ll discuss them further in future posts.
The Curious Case of Kodak
There are many examples of businesses who have stubbornly stuck to their plan, ignoring the changing landscape in which they compete, only realising their mistake when it’s already too late. At first glance, Kodak suffered this exact fate, but delving deeper into the story reveals a more interesting truth.
The common belief is that Kodak simply shunned the innovation of digital photography, focusing only on film and print services. But this belief doesn’t hold up to the facts. In 1975, it was a Kodak engineer who created the first digital camera prototype. In the 1990s, Kodak went a step further and invested billions of dollars into digital photography. They even acquired Ofoto, an online photo sharing site. But yet they still failed to turn this into a business model which would allow them to retain their competitive advantage.
The reason for this was because Kodak could not look beyond their vision to be the go-to destination for image printing. Sure, they invested heavily in digital, but it was to install digital printing kiosks in high street stores. Kodak failed to recognise that their existing customer base were users of film, and were unlikely to be the early adopters Kodak needed. And the photo sharing site they purchased? They used that as another channel to encourage customers to use their print services; had Kodak approached this differently, the world may have had an Instagram or Facebook-type service in the early 2000s.
Kodak’s failure to capitalise on their position as the leaders of the photography market in the 90s, saw them eventually file for bankruptcy in 2012. Although they re-emerged the following year, they did so as a much smaller outfit, and have never again reached the heights they enjoyed during their glory days.
Although much more can be written (and indeed, has been written by others) about the values of the Manifesto, and the accompanying principles, a valid question many of us might still have is: Yes, but why should my organisation adopt Agile practices? In order to answer this, it’s important to consider the state we find ourselves in today. And that’s precisely what the next post will cover — stay tuned!
About Agile Bites
Agile Bites is a series of posts written by Mohammed Rizwan which, when put together, intend to serve as a course for individuals and teams. Starting from Agile basics, we’ll move to more challenging topics such as Kanban’s work-in-progress limits and Scrum anti-patterns, whilst attempting to figure out exactly what an MVP is.
Follow Agile Bites to ensure you don’t miss a single post: https://medium.com/agile-bites
