Revisiting the Agile Manifesto Principles

Summary:

The Agile Manifesto was published in 2001. As it’s name suggests, it was a declaration of the motives and views of the seventeen signatories. It was very much a protest against top down management of IT projects whereby the deliverables of said projects were communicated to software development teams with little consideration given to the teams opinions and the needs of the end users of the software. Over the past 18 years, much has been written about what Agile means. The purpose of this article is to go back to the drawing board and hopefully remind readers of what the original 17 authors meant by Agile. Unfortunately, there is too much misinformation being circulated.

What exactly were the Twelve Principles of the Agile Manifesto? My comments in italics are my interpretation of the Principles.

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

Think back to the days when software was updated via CD or disks rather than over a broadband connection. Releases were done, at best, once a year. Bloated software was the norm; far too many features were included that the customer/end user did not want. By calling for early and continuous delivery, the signatories recognised the value of getting software out more frequently to garner feedback on what were the most important features.

Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

This principle is often misunderstood. To some it suggests requirements are loose and not clear at the beginning. Please remember that requirements before Agile were never 100% complete and accurate. Every ‘t’ was not crossed. Every ‘i’ was not dotted. The documentation took months and months to complete and often ran to over 1,000 pages. In Agile environments, if a change/feature is suggested that will add value to the software, it is recommended to take it on board. But, it is also recommended to not add scope by sacrificing a lower priority feature. As always, the focus is on what adds most value to the customer/end user.

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

This principle was quite radical considering when it was written. To deliver software every 3-4 weeks is very ambitious even today. Particularly if you are a large organisation with millions of customers. But it has held true. Delivering software 10 to 12 times a year is very conducive to steady feedback from the customer. Why wait a year to get feedback on your product? It seems crazy to think that now.  The most agile software companies such as Amazon and Facebook have continuous delivery pipelines in place so that they can update their products several times a day.

Business people and developers must work together daily throughout the project.

This again makes a lot of sense. How can developers guess what the business people want? How can the business people guess what is technically possible to build? It is crucial to a software project’s success that the business folks, who represent the end users/customers, should engage daily with the development team. In Agile, this is achieved through user stories which articulate user journeys.

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

This is fundamentally about culture and people management. Micro management is counter-productive. If a team say they need one week to complete a piece of work, ask where you can help and remove any impediments to their work. Senior Management should not be blockers to productivity.

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

This principle is unfortunately being ignored too often. Far too many software teams are not in the same location. Too much work is being sent offshore which means communication is more over Skype than in person. Team meetings should ideally be face to face and no laptops or phones should be checked during the meetings. I say ideally but understand teams can be working on projects across multiple locations. In this case, best strategy is to keep teams together in the same office. Do not have half the team in one location and the other half in another.

Working software is the primary measure of progress.

The thought behind this is related to how quickly software gets into the hands of the end user. If there are 50 enhancements on the product roadmap, get 20 to the end user, get feedback, and then consider what priority to deliver the remaining 30. Better still, refine and reprioritise the product roadmap based on feedback.

Agile processes promote sustainable development.The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

This touches on what the Japanese term ‘Kanban’; just in time manufacturing pioneered by Toyota. A constant pace is desirable so that work is done at an even pace. Peaks and troughs are to be avoided. Furthermore, it is a complete misconception that Agile/Kanban means pushing workers to steadily reduce the time they spend on tasks. Rather, task workflow should be smooth and tweaks here and there on optimising them are encouraged. The ‘continuous improvement’ of Scrum teams is a separate matter which I will discuss.

Continuous attention to technical excellence and good design enhances agility.

In any line of work there is the much talked about Growth Mindset and Fixed Mindset. Ideal employees should always be pushing themselves to grow both professionally and personally. The signatories of the Manifesto believe, in my opinion, that a team member who is always looking for ways to improve the team is a happy person and will excel at their work. The reality however is that some people are not open to change and want to stick with the status quo. These team members must not be allowed to slow down the pace of innovation and change.

Simplicity--the art of maximizing the amount of work not done--is essential.

To quote Leonardo Da Vinci, “Simplicity is the ultimate sophistication.”

Google may be the best example of simplicity. It’s search engine is the epitome of minimal design. Even today, Yahoo’s home page is very cluttered by comparison. One of the biggest traps software teams fall into is over thinking and building a product. Because they have budget and time remaining, additional features are added that have little value to the end user. This is not an agile practice and should be avoided at all costs.

The best architectures, requirements, and design emerge from self-organizing teams.

What does self-organizing teams actually mean? Basically, teams of developers, Business Analysts, UX Designers, Testers and Architects being guided by an experienced Agile Coach in organising their work. For example, early collaboration on discussions about new software features and going back on forth to elaborate requirements. Deciding who should do what and when.

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.

This is a recurring them in Agile. In Scrum, the most popular Agile process framework, Team Retrospectives are held at the end of sprints. Sprints are time boxed periods where the team focuses on delivering the highest priority features next. Typical frequency is 2 weeks though there is no ‘law’ on this. Retrospectives by their nature encourage reflection on what things went well, what did not go well and what can be improved. Punishment is not the name of game. Growing together as a team is.

Given the above, I hope the reader is clearer on what the 17 signatories of the manifesto were frustrated about and why they issued this ‘call to arms.’ As to how well companies are executing agile enablement/transformation in 2019, I plan to follow up on this article with a second separate piece based on my 15 years’ experience of working in Agile environments.

All feedback welcome!