I’ve talked about Agile being a philosophy in other posts: Agile Philosophy. By this I mean that teams should use Agile as a way to view their project and processes, not as a “how-to” guide to implement. Implementation of Agile concepts is done through the team reminding each other of the Agile practices until seeing the project this way becomes second nature.
In the Agile Manifesto at least two of the four lines have direct reference to the need for good communication (“Individuals and Interactions”, “Customer Collaboration”), and “Responding to Change” is an indirect reference to that need. Because of this I started looking for a good way to summarize what Agile requires from us to make the communication work or a way to distill a part of Agile for easier consumption. Additionally, customers, sponsors, management, and others not directly a part of the software team often wants to feel that they have directly contributed the creation of the product or is “in the trenches” with the development team. This ends up causing an adversarial relationship with the team when it feels like those external groups are “butting in.”
One way is to look at Agile communication is that Agile is “welcoming.” Within Agile we should “welcome” conversation about our processes, “welcome” shifting priority in the product requirements, “welcome” opinions and new ideas, and “welcome” others into our processes. Agile teaches us that change should not be feared but rather “harnessed for the customer’s competitive advantage;” That seems to be inviting (or “welcoming”) change to me.
If it were that simple things would be great. We’d throw a big party at every meeting with everyone there, say yes to every change, and enjoy a celebration of the project. Unfortunately, life isn’t so simple. We cannot accept every change, or the project would never finish, be a mess of conflicting requirements, and potentially languish as demoware with never ending unfinished features. We cannot allow everyone to join our meetings as they would become unproductive from the choir of conflicting voices and personalities. And we cannot open our project’s inner workings to every stakeholder as that inevitably invites stress and needless worry from outside groups. So how do we become more welcoming?
Think of the door to a night club with a bouncer or some form of security. That bouncer is looking at each guest for reasons to deny them entry. What if, instead, the bouncer tested each person for their understanding of the club’s rules? “Before I let you in, no starting fights, you dance while on the dance floor, two drink minimum, and no harassing women.” If the basic expectations are clearly understood, then the club welcomes you in. We can make some of those basic expectations for our project.
- If you want to change processes, be able to show metrics or make recommendations for alternatives. This should help turn complaints into constructive process changes.
- Once a feature is started, even if it is deprioritized, it must be completed either through being finished or ripping the partial code out. With this, priorities can change all they want, but unfinished features can be avoided.
- If you are not a part of the technical team (developers, testers, dev Ops, team lead, etc.), you do not act on what you hear in meetings or read in chat until you confirm with the team lead that action at your level is needed.
This last bullet point is important and comes with a great story. My development teams enjoy using direct message and chat programs (IRC, Slack, Teams, RocketChat, etc.). They love having their own space to discuss the project in a frank and blunt way. For the longest time our functional manager wanted more information about the project but resisted signing up for the chat program. We finally dragged him in and taught him how to use it.
He loved it! He would not stop praising the team on how much we worked together and how much we hammered out every little detail to produce a better product. He trusted us and let our team work as we saw fit. Notice that is an Agile principle, “Build projects around motivated individuals; give them the environment and support they need and trust them to get the job done.”
Some time later he invited his management into the group chat, mostly to flaunt and heap more praise. That manager did not know the rules, and at the first conversation our team had about a “problem” he leaped into action trying to figure out how much it would cost, how to best inform the customer, what emergency plans were needed, and so on. The “problem” was really just developers griping about old code, wondering aloud if an edge case could ever occur, and what impact it might have. Our functional manager had to pull his boss aside and let him know to just observe and ask questions. That if we needed his help we will ask.
It could have been worse. The team’s communication wasn’t stifled, so they continued speaking bluntly by feeling safe in their own channel. You don’t want a customer or management making the team afraid to give honest, clear, and unhindered feedback. The lesson is that management, customers, and stakeholders external to the core team need training on how to work with the project team. On the team’s side, give them that training, help them understand, and welcome them in once they get it.
In the end it is up to you to make your project more welcoming; You’ll be more Agile because of it. Don’t be afraid to train your team on how to help each other and your management & customers on how to understand your team’s culture. Give them the resources and patience to better work with the team and the results will be better customer collaboration, better (and more productive) interactions, and everybody will be on board to respond when a problem occurs.