If you have been anywhere near a television on Sunday afternoons or Monday nights between August and January you have no doubt heard the sounds of football players and coaches “speaking” to each other. I cannot count the number of times I have been able to read the lips of the slightly ticked off coach and been glad that we did not have the audio to compliment it. For those true football plans you have also seen the quarterback call an audible. This is when the quarterback has already called a particular play in the huddle and the team members have lined up and are ready to execute the play, however the quarterback sees something in the defense that could possibly cause the play the stumble. The quarterback may also see a defect in the defense and want to exploit it, and there wants to change the play at the last minute. You may also see a wide receiver at times running with his hand up in the air, signifying that he is open and ready to receive the pigskin.
This type of communication is paramount in football. I have just named a few different communication scenarios, but there are many more. In project management and specifically Agile, communication is just as important. If you have been part of waterfall team, you are all too familiar with the non-communication method, and delivering what the customer “asked for” but not what they “needed”. I have been part of teams where the customer has specifically said “well, that report is no longer needed because of the way we do business now” and our team commenced to moving it into production because, hey, that’s what they asked for and it’s too late now to start changing requirements. Does that make sense to anybody? That doesn’t work in any other parts of life. Imagine not being able to take a different class in college or being able to change your major because it’s not the same one you picked as a freshman. To put it in football terms, imagine coming to a game with every single play laid out in order and you could not change it, and the fact that the defense is changing, or someone gets hurt doesn’t change your game plan. You will lose! And the same thing happens on a project, most times you will lose if you take this mentality, communication is key!
Agile as a methodology has a manifesto. This manifesto is crucial to understanding the foundation on which Agile was founded. The agile manifesto is 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. Let’s look specifically at the customer collaboration over contract negotiation piece. Many teams spend more time covering their backside with sign off sheets and emails and change control meetings than they do actually building the software. I am not saying that there is no value in any of these things, but its usually done in the spirit of when this goes wrong, I need my butt covered therefore I need you to sign this unchangeable contract for us to begin so that we cannot be held liable if you decide to change your mind. And we wonder why so many software projects go south. We began with the end going wrong in mind! The truth is, the customer doesn’t always know what they want at the beginning of the project, they may have an idea, and that idea may change and evolve over time, like most ideas do, and that’s ok. Agile as a methodology is setup to deal with the evolving idea. Talk to the customer often and embrace the change that they bring, stop resisting it, plan for it and become the partner for the customer. Spend time understanding their ever evolving needs and wants and work to respond to those and in some cases anticipate the change. You can only achieve this through constant collaboration, so do that, do Agile!