I was working with a customer this week, and talking to them about how transparency in a development organization can be such a good thing. It brings me back to my long time observation that transparency implies accountability, since teams can no longer hide behind a lack of information. I also wrote a quick bash script that will produce a list of the changes between two different baselines, a set of rudimentary release notes. You can check that out here.
The performance and status of teams should be available to executives, stakeholders, and the teams themselves. In fact I would argue that it MUST be available to all involved. In sports we keep score, and keep numerous statistics to help the team management accurately evaluate the performance of it’s athletes. These statistics are then often utilized by the athletes (or the team management) to justify salary increases and decreases, trades, and the building of professional reputations. Would it make sense to have an athletic contest and NOT allow the teams and participants to know the score? Yet this is EXACTLY what many development organizations do to their teams, having them develop software without giving them access to the ways that they are being measured. It doesn’t make sense, and it is not productive.
To continue with the sports analogy, we keep these statistics even though we all agree that these measures are not the perfect measure of the worth of an athlete. In software, organizations and individuals often use the fact that the metrics and measures are not perfect as an excuse to avoid measurement completely. Software teams need to be more transparent, and need to embrace transparency and a variety of software development metrics and measures.
Software organizations need to encourage measurement of their teams, and leverage these efforts to finally measure their true worth to an organization. All too often software development is seen as a “cost center”, a bunch of strange tech nerds buying expensive machines and software toys. Organizations often view the software organization with dread; they cost money, and seem to be a huge source of risk (identity theft, loss of corporate information, lost productivity, etc.).
In order to fight these perceptions, software teams need to determine their worth to an organization in terms their business partners understand, revenue and profitability. Allow the business to make their requests, and make the internal software teams “bid” on these requests like any outside software development organization. The business can then make intelligent decisions about where to get their software from, deciding based on cost, technical merit, and quality. If the internal software development teams wins this “bid” process, then pay them for their work. Consider it an internal “fixed cost” contract, and treat them like a profit/loss center. If outside vendors or consulting groups win the bid process, then the business is able to realize their benefits in a more cost effective way. Profit motive will work like it always does, rewarding the teams and groups that do things most efficiently.
Software organizations need to see the future, because they are at the leading edge. I read a great Forbes article on the WikiLeaks founder Julian Assange. The point made by him is that transparency forces businesses and governments to be accountable. He believes that organizations can avoid the embarrassment of these disclosures by being ethical and transparent. I am not endorsing or criticizing the methods and points made by Assange in the article, the key to me was that the “transparency genie” is out of the bottle. In the information age, transparency is going to be the expected environment. You can either embrace change and find ways to identify and leverage the opportunities it presents, or you can fight reality. Software teams need to lead their business organizations because they understand the technology, and might be able to identify opportunities more quickly. This is something that would deliver true business value to their organization.
Rational Team Concert and Jazz allow you to have this type of transparency and visibility throughout the entire software development effort. When you look at how IBM is using RTC to help make our development of the Jazz based products more transparent, you can see what I believe will slowly become the standard for software development in the future. Go out and look at Jazz.net. Once you register, you can see all of the various bugs, problem reports, and development activities that our development team is working on right now. We base our internal reports and metrics on the status of the development artifacts that are visible in real-time to the rest of the world. Our customers are able to see the real time status of their bugs and enhancement requests.
What benefits do we see from this transparency? Our customers are seeing us as being more responsive, and we have been able to forge high trust relationships with our customers. Our software development efforts and new features can be more closely aligned with what our customers tell us is important. Since our software development teams are transparent, they produce better quality software that is more closely aligned to the needs of our customers. Our defect rates have dropped, and all of our high level business measures of team performance have improved. Everyone in our organization is accountable for improving our products, and improving on our customer satisfaction levels. That includes me too!
All of this is due to improved communications, improved transparency, and the use of Rational Team Concert and the other Jazz based products. It can be concerning to jump into this type of model, with huge amounts of transparency, but in the end it is where our business culture is taking us. The transparency genie is out of the bottle, and the people and organizations that thrive in the future will be those that embrace these cultural changes.
Dan Toczala's Blog 