If you tell me you are an Agile team, I assume that you are following, or at least trying to follow, the values and principles outlined in the Agile Manifesto. And I can easily verify how true you are being to those values and principles and to what extent you are achieving agility pretty quickly. Usually a 5 minute conversation about your team is enough to know where you lay on the agile spectrum. The Agile Manifesto creates a sort of measuring stick against which you can evaluate the agility of a team.
Even if your team isn't practically perfect, the values and principles from the Manifesto are your goal. I know that you are doing your best to embrace agility, but sometimes the real world gets in the way.
While participating in the "Architecture and Collaboration" panel at Saturn2012, Rick Kazman made an interesting comment that I let slide at the time. In response to the difficulty of getting stakeholders together to talk about architecture, Rick commented, in summary, "It turns out this is pretty easy. We all have the same goals. People want to make the system work."
This got me thinking about my development life, with and without Agile. Sure, everyone has the same goals – or do they?
The Agile teams on which I've worked had a clear goal, a clear purpose – to deliver value to our customer in the form of working software, quickly and predictably. Every decision that we made, no matter whether we were stuck in the weeds of a difficult technical problem or discussing high level methodology concepts, was made with this goal in mind. It always comes back to the software and how our actions would affect our ability to help our customer.
The teams on which I've worked that were not Agile, on the other hand, have always felt rudderless in retrospect. We had the same general goal of delivering software, but the focus on value was lost somewhere. The end result was usually disastrous. Little or no focus on quality. Process was either non-existent, which made the team unpredictable and unreliable, or so onerous that it actually prevented effective work. Some of these teams had fallen into the trap of jumping on the agile buzzword bandwagon without truly believing the values. Others were simply ignorant of the ideas.
On both the Agile and non-Agile teams, everyone did indeed have the same general goal of making the system work, as Rick pointed out. The teams that didn't actively embrace Agile ran into problems with how they went about achieving that goal. Without a common set of core values guiding the team, team members lacked the tools necessary to reach the goal effectively. It was like knowing we wanted to go north but not having a compass to show everyone the way. One person would use the stars, others the sun, and still others the moss on a tree.
The Agile Manifesto is a guide, a compass, a rough measuring stick, a rallying point for teams who want to build great software effectively. The Agile Manifesto for software development gives teams... attitude. And it's a flag for letting others know what your team stands for and how your team chooses to work.
I'm not saying your team is hopelessly lost if you don't subscribe to the ideas behind the Agile Manifesto. I've been successful with and without practicing it. The difference between the teams that were successful and the teams that weren't, was that the teams that were successful had a core set of common values uniting the team while we worked toward our goal. Embracing Agile's values and principles makes it easier to start this conversation and is a great starting point.
The big problem is that most teams who aren't Agile don't bother thinking about this kind of stuff.
Without a set of core values and principles, how the project ends up is anybody's guess. No guide, no compass, no measuring stick for understanding how well your process is working for your team. There is nothing for your team to rally around other than perhaps some corporate sayings or a strong personality on the team.
So this begs the question. If you are not Agile... what are you?