Why the Agile Manifesto Still Matters

A problem I have seen for many years, that I try to combat with the training and coaching I do, is the lack of appreciation for the relevance of the Agile Manifesto’s Values and Principles, even to the point of people “doing Agile” and not being aware of these fundamental ideas at all. The following is a brief attempt to highlight why I believe the Manifesto still matters, despite opinions, from within the Agile community itself in many cases, that something new is needed as the Manifesto is somehow passé. I simply do not believe that a team or organization can achieve all the benefit from an Agile approach and not be familiar with and pursue the Manifesto’s Values and Principles, replacing it with frameworks and practices and not knowing the greater guidance behind them.

Individuals and Interactions

One of the first things I asked about the Agile Manifesto, when I got the chance to speak to one of its creators - Alistair Cockburn - was whether there was any conscious ordering to them. I was told no, and that was more than a decade ago. Martin Fowler, more recently, said the same thing. Both, however, said they were glad “Individuals and Interactions” was the first item. I couldn’t agree more. My experiences starting from over two decades before the Manifesto was written convince me that the effectiveness of how individuals interact is likely the most significant factor contributing to the success (or failure) of any effort. When I ask people in my training classes to list the things that characterize their most memorable work experience, the answers fall heavily into how people interacted.

So many things in the Manifesto and its principles depend on some aspect of the interaction between people. There’s customer collaboration; business people and developers working together; motivated individuals; being trusted; face-to-face conversation; team reflection; adjusting behavior; self-organization; the pace of sponsors, developers, and users; welcoming change; and satisfying the customer. The other aspects of the Values and Principles are certainly amplified by the impact of how people interact.

I believe employing this idea, especially in a team context, needs to get off to a firm start by members of the team early on, developing an understanding, or at least an appreciation, of how one another views important aspects of working together, achieving quality, and improving productivity. This is why I think teams need to share the following activities together:

• Training – Too often, teams do not go through their Agile-based training together, but as individuals in separate classes. A good trainer can use that training to help teams not only learn the Agile fundamentals, but to engage in specific activities to help them develop such understanding.
• Team Formation – Even worse than training done individually, is skipping the time to accomplish deliberate team formation which would produce such understanding. This would include things like: (1) creating a set of team working agreements covering how planning, daily meetings, iteration reviews and retrospectives will be handled; (2) specifying a Definition of Done; (3) understanding one another’s views on design, quality, collaboration, shared responsibility; (4) considering how trust can be grown within and for the team (e.g., by learning how they can get past conflicts and commit to one another’s success); (5) what they can learn about one another beyond just their ability to contribute technically, and (6) what kind of team “culture” they want to encourage.
• Learning Iterations – It will likely take teams new to Agile development at least 3-4 iterations to begin to “get it”, that is, to begin to experience what “being”, rather than “doing”, Agile means. Giving teams that time immediately rather than pressing them for velocity and long-term predictability, is another opportunity to develop such understanding.

Customer Collaboration

As part of the Learning Iterations, the teams can practice collaboration either directly with stakeholders and end users, and/or through an intermediary such as a Product Owner who represents stakeholder and end user interests. While effective team interaction depending on everyone on the team may be assumed, it is not always as easy to assume strong customer interaction will be possible to create a collaborative atmosphere. The obligations and pressures customers and product/project management personnel may be under and how they have come to manage such obligations and pressures, can make it difficult for them to see how they can devote the time to form a collaborative relationship.

If direct engagement with the customer cannot frequently occur, then an effective representative for stakeholders (e.g., Product Owner) is a necessity to provide the connection between the development team(s) and the customers/stakeholders. Agile teams, by extending themselves to be collaborative, can provide the opportunity for customer/product/project representatives to engage as fully as possible in the relationship. Especially early on, this will mean recognizing that extra time may be required for the team to work on relationship building and determining how best to do that, while still being committed to the frequent delivery of working software.

I think one way to make this collaboration easier is to focus on how the team can welcome change. Now, when I have asked people about that 2nd Principle, a number have admitted that probably no one really “welcomes” change in requirements, especially “late in development”. But it seems to me that the second sentence in that Principle is the key. Just how can an Agile team “harness change for the customer's competitive advantage”? Foremost, they do that by not resisting change, but by being clear about what the consequences of change would be and giving the customer options for how their desire for change could be handled. This can all be done collaboratively and not through traditional Change Control Boards and formal change requests, if the customers/stakeholders or their representative will devote the time to replace documents with real-time, face-to-face conversation.

Welcoming Change

Whenever a team is brought a request for change, they should consider what that would mean to the cost, schedule, or existing planned, but not yet developed, functionality. They then present the options to the customer. Can the budget and/or schedule be increased/extended to allow the additional work to be done along with the other functionality the team had expected to be able to deliver? If not, then does this new change take higher priority than other work planned, which means that, to stay within the budget and schedule, lower priority work cannot likely be addressed.

Another way is through application of the 9th, 10th and 12th Principles by growing “technical excellence”, practicing “good design”, pursuing “simplicity”, and reflecting “on how to become more effective” and pursuing ways to grow their effectiveness. This will prepare a team to be able to adapt to change better, including by having more easily adapted software and fewer defects, eliminating waste due to rework. (One team I worked with, for example, took Bob Martin’s Clean Code book and, as part of each retrospective, one team member prepared a short presentation on a chapter. They would then try to practice those ideas in the next iteration. It took them many iterations to get through the book, but it helped them produce higher quality code and do so in a manner that made it easier to accomplish.)

I should also point out that the ability to frequently know the stability of one’s software will increase productivity, improve quality, and reduce risk. This is why emphasis is placed on growing build and test automation capability for teams and development organizations. I do not believe I have worked with any organization that achieved the kinds of quality and productivity goals they hoped for by adopting an Agile approach that did not invest in growing their automation capabilities. If you can make changes and have little to no time elapse between making that change and verifying its correctness, people will be far more confident in accepting and making changes.

Self-Organization Requires Trust

Sometimes I find this the hardest of interaction aspects of an Agile approach, both for people on teams and the rest of the organization. It is difficult to talk about trust because, at least at the outset of such discussion, many people do not want to admit to the lack thereof. But to allow a team to develop self-organization means people outside the team have to have trust in the team and people in the team must have trust in one another. This does not happen automatically.

While people do not start by distrusting one another (hopefully), it is hard to really trust others with whom you have not had some level of positive interaction. You can give and get theoretical “benefit of the doubt,” but that can fade if problems surface and people have not developed trust with one another. I believe, again through experience with hundreds of team situations, that trust on and of a team will allow the team not only to overcome many problems they encounter, but also avoid even having those problems to begin with. An important aspect of this is being visible about what you do, how you do it, and when you are having difficulties. It can be easy to “hide” in traditional environments and often for long periods of time before issues must be unavoidably faced. This cannot happen if an Agile team is to be successful.

There’s a third aspect of trust beyond teams being trusted and people on teams trusting one another, and that is people trusting themselves. If you have worked in an environment where much of what people do is defined, specified, or even controlled, by others, being put into an Agile environment can be a shock to some. They are not used to the regular visibility noted above nor are they used to being given as much responsibility for decision-making that self-organization and self-management require. It can be easier to not care as much about outcomes if your view is that you just do as directed and someone else is responsible for what was decided to be done.

If people on a team can trust one another and themselves, their willingness to try things, extend themselves, and be open about what is happening will grow as they feel supported by one another. I once worked with a team and was asked to facilitate their first retrospective. We did a standard round-robin brainstorming approach and I asked them to tell me first what they liked about working in an Agile fashion (since they were all new to it). I have never forgotten what the second person who spoke said, and I repeat it often in my classes:

I believe I can walk up to anyone else on the team and ask for or offer help and not have to worry about the reaction I’m going to get.

This was not something the person was apparently used to. I think this is a wonderful expression of how I would hope people on an Agile team come to view their interactions.

All of the above is why I believe the Manifesto still matters and why I emphasize its Values and Principles in the training and coaching I do.

About the Author

Scott Duncan has 46 years of software experience, including 14+ years in the Bell Labs-Bellcore-Telcordia environment and 4 1/2 years as enterprise coach and trainer for 144 Scrum teams in the US, India, Israel, UK, Germany, France, and Canada for Hexagon PP&M. He has also been an internal ISO 9001 auditor and CMM assessor as well as a member of ISO & IEEE Standards Committees for 15 years. Since 2004 he has been exclusively devoted to Agile coaching and training (including 2 years as a Scrum Alliance Board of Directors member).