Transparency: Implies openness, communication, and accountability
Agile has always espoused the importance of transparency within the development team, but it is also important to be as transparent as possible with your customer. In fact, the use of transparency can build the foundation of your customer relationship.
At Near Infinity most of our projects are consulting efforts where we build software for other people. In these situations, our customers place an enormous amount of trust in us, and it is incumbent upon us to do everything that we can to earn this trust.
Most Agile development methodologies have clear roles that serve to simplify the development process. In Scrum, the development team is responsible for delivering complete, tested, working software each iteration. The product owner is responsible for making decisions about which features should be developed at what time, and for deciding when there is enough new functionality in the software to make a release to production.
For anything not related to feature development the product owner is the decision maker on the project, but many times the software developers have more information about the state of the software than the product owners do. This puts the development team in a position of power. As we all know, with great power comes great responsibility. You have the knowledge that your product owner needs to effectively drive the project to success. You should share as much of this information as your product owner can stomach - whether it is good news or bad news. Especially when it is bad news.
Too many times in our industry, development teams will hide bad news from decision makers, hoping that they can adjust resources or shuffle the order of features that need to be developed in order to make up schedule time. We rationalize this by saying that our customers wouldn't want to know all of the "implementation details" and there is no reason to get the customer involved with something that may not even be an issue. This idea of the development team insulating their customers from development issues is flat out wrong. Nothing good can happen from this. In software development, we almost never make up schedule time and things don't magically get better because we shuffle around resources.
So instead, share the bad news. You may think that it makes the development team look bad, but it won't. Software development is not an exact science. Pretending that it is can be a recipe for disaster. A good product owner will know this and should expect some setbacks during the course of the project. Sharing these setbacks shows your customer that you are their partner in this effort. It gives your product owners the valuable information that they need in order to make the critical decisions that will affect the overall success of your project.
As software developers, we want to prove our expertise. This is our profession; we are supposed to know what we are doing, right? (Right!) So then doesn't admitting our mistakes and pointing them out to our customer make us look incompetent? Absolutely not. The truth is that by owning our mistakes and exposing them, we look more confident in our abilities. It shows your customer that making mistakes is part of the development process and is normal. Confidently owning mistakes, learning from them, and addressing them with better solutions shows your customer that you are experienced and you know how to deal with adversity. It shows that you can be trusted to make decisions that will benefit the project and the customer, and that you are not just looking out for yourself.
It is easy to fall into the trap of always wanting to please our customers. This is a very shortsighted view of software development. If you aren't concerned with repeat business, then by all means, always tell the customer what they want to hear. The truth of the matter is that sharing information that upsets your customer is almost always the right thing to do. It may mean having an awkward meeting or a tense few days, but it allows your customers to do their jobs more effectively, to plan appropriately and it better enables them to meet their expectations in the long run.
Don't mistake honesty for transparency. Customers expect honesty. They expect truthful responses to their questions. Transparency goes one step further. It means sharing information when you don't have to. It means sharing information when things go wrong. It means partnering with your customer in order to deliver the best software possible in order to return value to the business.
Being transparent isn't always easy. Just remember, the most important time to be transparent is when it is the hardest.
0 TrackBacks
Listed below are links to blogs that reference this entry: The Agile Attitude Part 1: Transparency.
TrackBack URL for this entry: http://www.nearinfinity.com/mt/mt-tb.cgi/527



Leave a comment