Agile has fostered a fair bit of change in how software development happens. Change in what people value, how people work together, and changes in openness and and candor. For a long time, software was a black box, or close to it at least. A business feeds in some sort of information about the problem they are trying to solve in the form of requirements, and maybe six months later they get something. That something may or may not have solved the problem. If the problem wasn’t solved, the cycle begins anew.
One of the things that really stands out from the agile principles is the openness. The way software development is done in the various flavors of agile is optimized for sharing and communication. Scrum has people openly talking about what problems they are having, and open work spaces have people sitting next to each other to facilitate more talking. Reducing barriers to getting working software in the hands of the customer is the theme.
Openness at Wikipedia
Wikipedia takes this idea to the next level. At any point in time, you, or anybody really, can go the their wiki and see what features are being worked on, what features are in the queue to be worked on next, and how testing is going. You can even get on the developer email distribution lists if you choose to do so. Wikipedia is, to use the words of Wikimedia Foundation Test lead Chris McMahon, radically open. I think that is a good thing.
This isn’t a terrible uncommon thing to see in the open source space, OpenOffice and Firefox share similar models. I’d like to see these values move into the private-for-profit sector of software.
Taking it to the next level
This model could work really well for some companies, especially early stage companies with few customers. Sharing feature queues, maybe parts of the bug tracking system, or including customers in weekly demos could create a sense of responsibility in the company creating the software and trust in the company buying the software.
Product demos could be extended to include customers and potential customers at whatever interval they are already being done internally. This would give a picture of the release far better than any project schedule or product roadmap could ever hope to communicate.
No company or developer wants a large public (at least to its customers) list of problems. Openness could encourage people to fix problems quickly and quietly so that they aren’t immortalized on a tracking system.
One place this would work really well is a company with some dedication to the developer community.
I’m looking at you Twitter and Facebook.
Many companies are now dependent on APIs developed and curated by other software companies. Facebook and Twitter are two of the big ones. Products have to integrate and struggle to keep up with API changes due to a closed development process.
Being able to sell your product in an environment where your company is open and honest about its development practices is an incredibly powerful thing.
There are some big differences in my examples. Wikipedia is a free product offered for the good of humanity by a not for profit company. Private companies are driven by competition and sometimes trade secrets. Creating this sort of open environment could potentially harm the business.
There are of course scenarios in some business domains or with customers/clients that are more difficult than others where this might not make sense. If your business is at risk of airing ‘dirty laundry’ or sharing a competitive edge, then maybe this sort of openness won’t help your product.
It sure does seem like something good to shoot for though.