I’ve been part of teams that practice Agile software development methods for quite a while now. My own team at work has been doing things in an agile manner since about 2008. Before that I was a co-founder of the Agile SIG (Special Interest Group) at work for several years, attempting to bring agile into the organization from the grassroots level. I’ve been trained for the role of Scrum Master by Ken Schwaber and Jeff McKenna. I started a group of retrospective facilitators at work as well, in the hopes of turning the organization I was part of into a more consciously learning organization. Before the job at my current company, I practiced eXtreme Programming in a startup. This is (I think) my first blog post exploring some aspect of Agile software development methods.

Over the years I’ve come to realize what it is about agile that makes it work. Agile is basically a mitigation strategy/technology that addresses the human tendency to fail at communicating effectively. Let’s look at this from the perspective of a model I learned about in high school from my language arts teacher – the basic human communication model. This model comes in various forms, but I like the one from my high school years. It’s one of the few things that have stuck with me from that time:

The Sender and Receiver in this case are people (although this model applies to pretty much any communication situation and is used in computer-communication model discussions as well). The Context on each side is complex. It’s made up of a person’s knowledge, cultural upbringing, state of mind, experience, financial situation, family circumstances, and many, many other factors. The Sender intends to convey a Message to the Receiver and the only way to do so is by Encoding the Message (in a way that the Sender hopes the Receiver will be able to Decode) and to pick a Channel for transmitting the Message. The Sender’s only way to verify if the Message reached the Receiver is by some Feedback mechanism, which actually just reverses the situation of the diagram. There are lots of ways that the communication can break down. For example, the Sender might pick an Encoding the Receiver isn’t able to Decode; the Channel might garble the Message so it becomes unrecognizable; or the Receiver might be in a Context that prevents the Message from being Decoded properly. Other communication breakdowns involve the Sender making unstated assumptions about the Receiver’s Context, the Sender picking a Channel that is inappropriate for carrying all the meaning necessary for Decoding the Message, or the Receiver not being receptive to the Message coming through the Channel.

When building software, the central thing we do is to turn ideas in our head into instructions for a computer to execute. If this were a solitary exercise, there wouldn’t be much of a problem: you have an idea; you think about how to translate it into something the computer can do, taking into consideration your skills, the computer environment, your choice of software technology stack, programming language, experience, etc., etc.; you sit down for a few hours, weeks or months to design, write code, test, deploy – and you’re done! In terms of human communication there is none, so the model doesn’t really come into play.

The trouble doesn’t start until you’re working on something that takes more than one person to accomplish in a reasonable amount of time. Unfortunately, most things undertaken in software these days are of this nature. This means several things. One, there will be human communication going on! Two, the kinds of communication will take many different forms and concern many different topics. And now we’re squarely in the domain of the communication model.

Just thinking of the number and kinds of things that will need to be communicated between people can make your head spin:

• How many features will the software have?
• What are the features?
• How will we know that a feature is done?
• What technologies will we choose to implement the software?
• What computing systems will we support?
• How will we construct the software so it is robust enough, yet easy to change in unforeseen ways?
• What are the major parts of the software?
• How will the parts communicate?
• Will the user be able to understand it and use it as intended?
• Will we be able to deliver the software on time?
• What does on time mean?

And these are just some technical questions. There are others as well, more business related:

• Will the software have value to customers and users?
• Will the customer pay for it?
• How much will the customer pay?
• Will the customer be made mode productive by using the software?
• How will we deliver the software to the customer?
• How will we know if we’re building the right thing?
• How will a customer be able to provide feedback on the software?

Pulling off almost any kind of software effort requires answers to these questions, and more. The nature of software development is one of producing ideas and mental constructs that can be turned into instructions for a computer to execute. If more than one person is involved in this activity, those ideas and mental constructs have to make their way from one person’s brain to another’s, so the people can collaborate to get the software built within some time limit. Agile software development methods bring to this process more formal opportunities for people to interact, increasing the likelihood of this communication happening  regularly and at varying levels of complexity, timescale and team composition.

Let’s take Scrum as an example. Scrum sets up a framework for communication and feedback like this (from high level/long timescale to low level/short timescale):

• At the Sprint level (usually every 2 weeks these days, but Scrum originally used 30 days) –
  Sprint planning/review meetings and Sprint retrospectives. These provide opportunities for medium-term communication and feedback on the production of a usable increment of software functionality.
• At the Backlog grooming level (usually at least once a week, but not specified by Scrum) –
  An opportunity for communication and feedback about user story details that concern upcoming sprints.
• At the Daily Scrum level (every day at the same time) –
  What happened yesterday, what will happen today, what’s getting in the way? This is an opportunity to quickly gather feedback and communicate about nitty-gritty day-to-day details.

Scrum’s official rules (found in the Scrum Guide) were recently updated (in July and October of 2011) to allow for more freedom in selecting practices and experimenting with new things. So, as of the latest edition of the Scrum Guide, Release Planning is no longer part of the official Scrum rules. If it had been, I would have argued that Release Planning and the Release Retrospective provide the highest level of overall communication and feedback loop that Scrum puts in place. Since many people still use Release Planning as a tool, I think the point still holds.

Many people mix in good technical practices as well, which add things like:

• Pair programming –
  Instant, real time communication and feedback on the construction of ideas and expression of those ideas in code.
• Continuous integration –
  Feedback on code quality, feature readiness, etc. on a daily basis or more often.
• User story estimation (part of Sprint planning) –
  Feedback and learning about what a software feature is supposed to do, how it will be implemented, what its acceptance criteria are, etc. Often summarized by a relative size called “story points” based on the Fibonacci series of numbers, which are useful because people are somewhat better at judging relative sizes than absolute sizes.

Human communication tends to break down in unexpected ways. Agile software methods give people plenty of opportunities to communicate and get feedback, helping to mitigate the breakdowns that occur in the complex context of team-based software development.