![]()
Scrummin’ the system: How a whole industry could profit from transparency
Friday, 12.03.2010
Scrum brings a lot of transparency into software development projects. So what could this mean for an IT industry that is still shaped by unrealistic expectations, as the following quick survey (published in Weave magazine, issue 1.10) exemplifies?

Around 660 business customers were asked how long they thought the development of a website would take. (Tage = days, Wochen = weeks, Monate = Months).
So could Scrum have a role in contributing to starting IT projects on a more realistic and therefore productive basis? When Scrum is described as “agile/ flexible” this is meant in comparison to other development methods. Scrum allows for a flexible development and can be used to sustainably raise the quality of a software. However, like with other development methods, if the customer changes specifications in an ongoing project this will have an impact on project costs and time. The difference with Scrum is that in such cases where the project needs (user stories) are being redefined the consequences in terms of time and costs are more measurable. And what’s more measurable is also easier to adjust, and that again is flexibility. This measurability Scrum brings is therefore highly beneficial to the project.
So very similarly to making visible problems within the development team, Scrum also works that way regarding the specifications made by the customers. Detecting and tackling such problems early on boosts the quality of a project. All this requests a good deal of readiness to take responsibility for project results thus made transparent. But if the producer and the customer together weather this a whole new level of cooperation can be reached.
From what I see this hasn’t spread very far yet. To many market participants less transparency is still the modus operandi and the grey area is leveraged by all sides to shirk responsibility.
In the web industry there is still considerable lack of transparency and many market participants try to please unrealistic customer expectations rather than committing to good projects. First, this practice gets in the way of the producer being able to fully realise his knowhow about a project, the ROI is minimised. Second, any time-cost-quality-relation runs a high risk of getting busted somewhere along the way. Last, such practices negatively affect the credibility of the industry as a whole and prevent a learning curve from developing, as the customer has no chance of learning for the future but through assumptions about what went wrong. Given such practices it’s no wonder so many IT projects keep being frustrating and unsuccessful.
Conclusion
My view is that Scrum-based development can make an important contribution here, if a critical mass of producers committing to it can be reached. Not only could the overall quality of the products be boosted, but on a much more general level enhanced transparency could contribute decidedly to establishing more realistic, better-informed market practices.



