A software delivery team could diligently follow agile methodologies and ceremonies but, in the end, woefully fall short of their own expectations of materially improving speed, quality and agility.
I have found one of the primary causes for this has little to do with technology, process or skills. It is about the lack of practice of something that is intellectually simple to understand - truth and transparency.
Understanding what is true is essential for success within a software delivery team. Being transparent about everything, including mistakes and weaknesses, helps create the foundation that leads to improvements. Being open with each other during agile ceremonies - stand ups, planning, retrospectives and post mortems ensures that important issues are apparent instead of hidden. It enforces good behavior and good thinking, because when we have to explain ourselves, everyone can openly assess the merits of our logic.
I have found low performing teams have a culture of holding back information related to work status, quality, productivity, technical debt, etc. In fact they don't usually have a clear view of where they stand on these measures of software delivery performance.
If we are handling things well, openness will make it clear, and if we are handling things badly, openness will make that clear as well. When openness is practiced and more people can see what is happening - the good, the bad and the ugly - the more effective they are at deciding the appropriate ways of handling things. Learning and empathy is compounded when everyone has the opportunity to understand why a person or group did what they did, whether good or bad in relationship to achieving team outcomes.
Practicing openness is not easy
This takes some getting used to. It is difficult because while we might instinctively understand the virtues of openness, we tend to react with a flight-or-fight response in conversations of improvement, especially when some of our own behaviors are examined. Additionally, openness if unmanaged can lead to team members getting involved with more things than they should, simply because they are now part of the conversation. But these challenges can be overcome through practice and coaching.
Giving all members of the team the right to see things for themselves, by being open with each other in matters related to software delivery, is better than forcing them to rely on information processed for them by others. Openness will force issues to the surface - the problems people are dealing with and how they are dealing with them - and it draws the whole team and the organization around it to draw on the insights and talents of all its members to solve them.
While concealing truth and transparency might make individuals happier in the short run, it wont make the team smarter, happier and will impair software delivery performance in the long run. Thinking solely about what’s accurate instead of how its perceived pushes the team to focus on the most important things.
What about client-contractor situations?
In client-contractor situations where the team is building software for an external client, the inclination for the contractor to “want to look good” is especially high. This might encourage the desire to filter out the bad stuff and only report the good stuff until absolutely necessary. I would say doing this only gives teams a false sense of security because when the reported status is consistently “good” and problems occur, it is detrimental to the team’s credibility because the client will see the mismatch between what has been reported to them and what reality shows. This is bad for business and impairs the longevity of the client-contractor relationship.
So team members should not insulate software delivery challenges from their clients. Keep in mind that communicating with openness does not absolve the team from fixing the problems or improving — just because the client is aware. What I am saying is that our clients being proactively aware of the challenges and seeing teams work through them, learn from them and succeed actually helps forge long lasting client-contractor relationships.
Openness needs to be encouraged and cultivated in a methodical way. When done so it is so liberating and effective in driving improvements that it becomes hard for teams to operate any other way.
All I can do is borrow ideas from great thinkers in different fields and combine and apply them in interesting ways to my field of work. Each of my posts here is the result of applying what I have learned from the extraordinary professionals below. Whether you are a technology leader in an organization or if you are a consultant like me trying to help their clients be more successful - I would highly recommend reading the references below, which I have synthesized into my work and my writing.