Agile practices provide a significant benefit to the effectiveness of internal communication on software teams. Born out of a need to improve the software development process, Agile provides a framework for communication between the members of engineering teams as well as between engineering teams and business stakeholders.
There is no reason that such benefits need to be unique to the software industry, however.
As a developer working on internal communications software, I see many ways that Agile methodologies and internal comms overlap and can add significant benefits. Let’s explore …
1. The Agile manifesto
Every distinct software project is unique and relies on some level of innovation for success. As a result, traditional waterfall-based management processes don’t work well because they seek to define a recipe for success upfront.
Good innovation requires flexibility and the ability to change as discoveries are made, and change is encountered. The Agile manifesto, written in 2001 by a group of renowned and respected software engineers defines four principles:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
You might notice these principles are almost entirely about internal communications rather than software specifically. I believe the internal communication practices in any business operating in a space where innovation is required will benefit from understanding them.
2. Productive meetings
In general, meetings are the bane of software engineers. They are disruptive to the flow of development and can severely impact productivity if there are too many of them. Of course, meetings are also an absolute necessity. They are the lifeblood of internal communication, and without them, there is no way we can work collaboratively or know work priorities.
So, when should we have meetings, and how do those meetings relate to the agile manifesto?
A popular Agile-based approach is called SCRUM, and it prescribes that teams should work in short iterations of one to three weeks. Several regularly scheduled meetings should occur during those iterations to facilitate optimal internal communication between the team and the business:
The Daily Standup:
This is a short daily meeting when a team and one or two business stakeholders get together to answer three questions for each other:
- What did I accomplish yesterday?
- What do I plan to accomplish today?
- Any roadblocks are impeding my progress? This meeting directly addresses the first and fourth agile principles. Team members speak directly to each other once per day and respond to changes promptly. Perhaps most importantly, the communication that takes place here ensures problems are addressed early and often.
The Demo:
At the end of each iteration (1-3 weeks), the team meets with key business stakeholders to demo what has been accomplished. This is an opportunity for two-way communication between all team members and the business, incorporating the four principles:
- The meeting facilitates direct, person-to-person communication over tools.
- Demonstrate working software live rather than sharing documentation. A picture is worth a thousand words, right?
- Collaborative discussion allows for new ideas to be introduced and for old ones to be changed rather than adhering to a pre-defined contract
- Change is both expected and encouraged in advance of the next iteration
The Retrospective:
Also scheduled at the end of each iteration, the retrospective meeting allows the team time to get together to celebrate successes, reflect on what worked well and what didn’t over the last few weeks. The goal of the meeting is to come up with a handful of action items to improve the team’s process. As with the standup, this meeting promotes individuals and interactions over processes and tools. It is about helping the team respond to change and take appropriate action regularly. If a process that was working three months ago is no longer working, then it can and should change. Retrospectives are a chance to make sure that happens.
Backlog Refinement:
A software team’s backlog is an ordered list of work not yet started. Once per iteration, the team will meet with the business to discuss future work and prioritize it. Priorities may change regularly, so this meeting allows for regular two-way internal communication with the company to discuss, in an open forum, what needs to be done and when.
The goal of these meetings and the Agile methodology in principle is to encourage regular, face-to-face communication within the team and with the business in general. All stakeholders are involved to ensure no one is accidentally left out, and everyone has a voice. All teams and companies can benefit from this internal communication style, not just those in the software industry.
3. Iterative internal communication
Agile methodologies encourage and embrace change. They support regular, in-person touchpoints that include all stakeholders on a project or product team.
One weakness I have observed in many organizations outside Agile methodologies is that internal communication doesn’t happen frequently. This leads to frustrated employees and knowledge gaps that result in inefficiencies within the business. An iterative approach to internal communication that encourages everyone’s involvement and promotes regular discussions about changes can benefit both companies and employees when tasked with dealing with a changing landscape.
Tips for using Agile software development for internal communications
In general, software teams and software companies are already familiar with Agile practices. Many businesses outside of the software industry are unaware of the benefits of internal communication that can come from such practices. Here are four tips to keep in mind when moving forward with Agile methodologies:
1. Read the Agile manifesto and think about adapting the principles to existing business processes and practices. Questions to ask are:
- How often do people in your organization talk face-to-face?
- Are the organization and its people to change?
- Do you collaborate with your customers? Is it through layers of bureaucracy or via direct collaboration?
- How often do you use visual tools to show your customers and people how your product works?
2. Think about adopting one or more of the SCRUM meetings discussed above, especially the daily stand up for your team or teams. Solve problems quickly by opening up direct communication lines between everyone.
3. Take an iterative approach by focusing on making smaller changes over shorter cycles whenever possible. Get everyone talking after each iteration, reflect on accomplishments, and adjust as necessary.
4. Embrace change. Change is inevitable, and if you’ve built your business or team with the agility needed to respond to it quickly, you have the best chance at successfully handling it.
