Here at The Gartrell Group we use the agile approach to software development because it matches our personalities and seems to work well for us. In this short blog post, I thought I’d share several recent thoughts and passages on the Agile process from the past month.

This first piece has been widely popularized so perhaps you’ve already read it. It’s worth sharing far and wide in my opinion. I assume it’s anecdotal, but it feels quite accurate based on personal experience. It comes from the book Art & Fear by David Bayles and Ted Orland and was copied from here:

The ceramics teacher announced on opening day that he was dividing the class into two groups. All those on the left side of the studio, he said, would be graded solely on the quantity of work they produced, all those on the right solely on its quality.

His procedure was simple: on the final day of class he would bring in his bathroom scales and weigh the work of the “quantity” group: fifty pound of pots rated an “A”, forty pounds a “B”, and so on. Those being graded on “quality”, however, needed to produce only one pot – albeit a perfect one – to get an “A”.

Well, came grading time and a curious fact emerged: the works of highest quality were all produced by the group being graded for quantity. It seems that while the “quantity” group was busily churning out piles of work – and learning from their mistakes – the “quality” group had sat theorizing about perfection, and in the end had little more to show for their efforts than grandiose theories and a pile of dead clay.

Fascinating isn’t it? Reinforcing the spirit of Agile, the teacher inadvertently proved that refinement comes in cycles and that while valuable, specification does not trump implementation. Communicating complexity will require more than just one loooong perfect session.

The second piece has been shared widely as well and more-humorously adapted to the software design process specifically. I chose the version of the comic below given it’s explicit calling out of the problem at hand. Communication.

The more effectively a team communicates, the more productive and efficient they will be. The above is funny because it’s true. We’ve all seen projects that missed the mark by more than a little. What was missing? Communication. Knowing that it can be very hard to document complex systems and business rules, we prioritize communication and iteration to ensure that the design is true. We develop communication devices quickly (aka minimum viable products (MVP)) and frequently (think pots) to enable continuous kinesthetic and mutual interaction with what will become the final product.

Don’t be afraid of failure and keep on potting.