Is Your Agile Team Taking Every Opportunity for Communication?
A few years ago I was at a Cowboy Junkies concert, and the lead singer gave the following advice to an audience member who had just become engaged: “Keep talking.” Perhaps this stuck in my head because my (now) wife and I were planning our wedding at the time, but it struck me as good advice for a group of any size.
The first principle of the Agile Manifesto expresses the importance of “individuals and interactions,” and agile projects are based on the idea that the key to a successful software project is communication. There are many ways Scrum teams can bring this value to life, not just through standard events, but also through coding and testing practices.
Scrum events such as the planning meeting, daily scrum, sprint review, and sprint retrospective are well-defined points where team members (including the product owner) communicate. These are not the only times communication happens, nor should they be. In addition to ad hoc conversations, the processes of coding, testing, and delivering software are also important opportunities to communicate.
The code itself, including code and configuration that automates deployment and other processes, is the best form of communicating what the system does. Code written using style conventions that the team can easily understand is the best way to make a system understandable and adaptable. Having a process that lets someone else see the code before you are done, such as pair programming, also provides a forum to discuss coding decisions. The tests that go along with the code provide context that the raw implementation may not expose.
Integration tests (ideally before implementation starts) allow you to create high-fidelity descriptions of functionality that ensure that the development team and product owner truly understand each other. It’s also a way to help the team understand when a feature is “done.” Unit tests, in addition to helping with design (when using test-driven development), also provide a way to communicate with future developers about when a change might violate a design decision.
Committing code to a repository can provide context about why a decision was made (via the commit message) and indicates the scope of the change (by the files grouped in the commit). An appropriate pull request or review process can provide an explicit opportunity to discuss design designs, especially if you do not use pair programming.
Communication is hard work. It is also essential to a group—whether a family or a team—moving in the same direction. While I do know couples who have kanban boards in a highly visible place in their houses, talking is often enough for family projects. Teams building software have opportunities to communicate not just by in-person interactions, but also through their code and their release process.
If you’re not considering coding, tests, and the delivery process as opportunities for a conversation, you are missing an important chance to leverage individuals and interactions. These mechanisms and the processes around them can be valuable communication tools, rather than simply an obligatory step.
If any of your tools and processes feel like overhead, you should consider why—and make appropriate changes to leverage the power of these interactions.
