I think that in many organisations achieving effective development transparency relies on a certain maturity and understanding of software development extending from the development team all the way to executives, which makes achieving transparency complex. On the other hand I can’t think of a better way of achieving that maturity and understanding than adopting a transparent philosophy. It’s just important to understand that it’s not something that can be achieved overnight in many organisations. Especially the big ones!

I think that marketing, in particular, is sometimes an inhibitor to some software development best practices and could be dangerous if you don’t manage it correctly. Just an example, the Jazz Project sometimes seemed to me a vaporware project. Two years announcing a project (hey, I want this kind of planning for my projects) and nowadays there is no product available (ok, it will be a product next month). Some days, I felt that they were teasing me.

But I believe long-term roadmaps are not the most important thing in transparency. There are lots of open-source products where you don’t have visibility on which are the future developments plans, and this does not prevent them from being mass adopted and being a successful model of collaboration between customers and providers. I believe it is more important to feel that your requirements will be taken into account and that you can influence the direction of the project. One book I always recommend about this topic is “Outside-in Software Development” (BTW, from IBM).

With regard to external facing companies, I believe it certainly depends on many factors like the type of business you are running, the confidence on your team, etc. Not every company will be wishing to show publicly their detailed roadmap for the next two years, as they could quite easily miss the targets with marketing consequences, their competitors could basically grab their roadmap and copy it or improve it or just use it as a weapon for targeting their own customers, … It is really a complex subject. Companies like IBM can do it as they have market ubiquity and plenty of resources to research, innovate and counteract their competitors, but not all the companies have such resources.

If we get scared of all potential problems that could arise, then we will never do anything. In this case, I see more advantages than hitches. So, let’s be positive and try it, and if I fail, then just another lesson learned

There are lots and lots of organizations and people that do not share your view of “internal customers” (no matter if the have fancy mission statement that state the opposite); they make work days a pain, progress a drag, and change and improvements impossible. They run their businesses as small monopolies, and holding back info is critical to maintain the status quo. It’s not something driven by power greed or laziness, just by some tribal us-vs-them feeling.

So transparency is about choosing the right side, about making the workplace something more enjoyable, about giving the transparent team the gratifying challenge of having happy customers instead of the boring challenge of keeping alive a power silo. Most people love helping others and being useful, and transparency empowers teams to get that feeling.

Of course, not everything is nice and comfy. If you open up your development process, you get some of the problems that OSS projects get: you need to deal with a flood of tickets, or occasional rude assholes that previously did not have access to the development team may get annoying or…

I’ve always been a big fan of transparency, but having just read Ricardo Semler’s book I guess I’m (still) more vocal

Soooo (apologies for such a long comment!), a transparent developemnt process behind the firewall is possible, is good for the team, is good for the corporation and it is The Right Thing. Go for it! Good luck!