Effective communication isn’t easy. Even when you may think that everything is going right, when outwardly observed, you may find your process has some gaps in communication. In this post we are going to review the concept of Individuals and Interactions through the lens of transparency and communication. The objective is to have you analyze your process and find ways in which you can improve your interactions.
Transparency to enhance interactions
One of the key complaints that spurred the need for agile development is the issue of transparency. Prior to agile, work would be handed through various stages of the development life cycle with no particular view by one team in the work of another. Design rarely got involved with testing, development rarely interacted with operations, and customers didn’t see anything until the final release of the product. It is easy to see, then, that transparency was an obvious concept that was missing. The inputs or requests went into a metaphorical black box and nothing was seen or known until that box kicked out an output. Most of the time this output was wrong.
When the Agile Manifesto was created, a key value of this new paradigm was a focus on individuals and interactions over processes and tools. The idea being, that if we focus on individuals and interactions, the communication level within an organization would naturally increase. If you are interacting with stakeholders or customers on a daily basis, then there is no way that a customer or stakeholder could say that their requests or needs just get put into a black box. They have become a part of the process from start to finish. They’ve been given full transparency into what the technical team is doing to meet their requests.
Openness in Scrum
Various agile frameworks codified the importance of individuals and interactions and echoed that importance in their own values. For example, Openness is a key value in the Scrum framework. The entire scrum team is open to showing anyone interested where they are in the process. Information radiators like scrum boards, or burn down charts are made freely accessible and available to stakeholders to foster this principle of openness. There are daily stand up meetings where work items and plans are discussed for each day. Anyone in the organization can join on the stand up as an observer to eliminate the black box of development.
Scrum is no different from other agile frameworks in creating values that focus on individuals and interactions.
Transparency in Kanban
Rather than the term Openness, Kanban uses the value of transparency to eliminate the development black box. Like Scrum, anyone should be able to walk up to a Kanban board and see exactly what everyone is working on. There is no question where a feature is in terms of development. The framework provides this information naturally. It answers questions on demand simply by walking up to it and seeing it. Additionally, it encourages interaction as questions on the board should be answered by any one working on the team.
Whether it is Kanban, Scrum, or something else, each framework will value transparency in some way.
The real problem is in interactions
Now, you can be working on an adequately agile team that responds to change, but you may still run into issues where there isn’t “transparency”. What is happening in those situations? If you are following Scrum or Kanban, there shouldn’t be any transparency issues right? Wrong. Transparency issues still persist if you are not following the value at which Openness and Transparency tie to — individuals and interactions. What is the point of having a Scrum Board or Kanban board if no one looks at it? The information radiators are there to encourage interaction, it isn’t there to make your office look cool. Further, communication doesn’t necessarily translate to a meaningful interaction.
What you are communicating is just important as how
If you find people raising concern of a lack of transparency, and yet you are sending out status emails, you have sprint boards, weekly touch-point meetings,etc., you may be sharing the wrong type of information. One thing to remember is that the information you find valuable isn’t necessarily what your Stakeholder wants to know. When you are working within your development team, the information important to you is the most granular thing that you can think of; because that is where they are doing the work. But, in the eyes of your stakeholders, they might be one or two levels above you in terms of information. From their perspective, user stories and bugs may have less meaning than a feature or an epic.
Structure is important
So, the question then becomes, are you organizing your backlog for work, communication, or both? Often times, I’ve found that to really have things working well, you talk to your team in terms of user stories and your customers in terms of features, and your executives in terms of epics. Organize your work so you can talk through it at those levels. But, balance your efforts so as to not waste time constantly organizing your work items.
Improving interactions
If you have the “what” taken care of, you still have to work through the “how” of interactions. Since everyone is different, there isn’t a silver bullet approach to how you can tackle this problem. This is where experimentation comes in. Someone in your organization needs to have the time and ability to openly observe the quality of your communication with individuals. This is another reason why the role of coach is valuable within an organization. Someone needs to pay attention to these factors and be able to facilitate change, and leaders need to invest in that change and model it for the rest of the organization.
The correct amount of communication is a balancing act between how, what, and quantity. But, the objective should never change. It should be to build meaningful interactions. Get feedback on how your communication is going. Do this via direct feedback or have some one independently observe your interactions. Then, experiment with new things until you find what works. Finally, don’t be expect change. Things may only work for a season. As your company or team evolves, you must as well.
Thanks for reading,
David Bjarnson
Agile ↑
Curious about agile certifications? Read this post here!
