by Nick Entin, VP Research & Development, Certified ScrumMaster
Today many software development companies are switching to Agile Processes and, particularly, to Scrum, for various reasons. Polarion also switched to Scrum for internal development. Why?
There were several reasons, some of them specific to the company (size, area of business, customers, etc.), and others quite general. In this blog I'll focus on what played a role for us; I won't try to describe how we would do "if".
The first, and probably most important, reason was transparency - customers are demanding something, Product Management defines requirements, Development Team is committed to fulfill them, but when it comes to the project end, results are not exactly as expected, there are delays in delivery, if the release is rescheduled, then typically there are still unknown risks and nobody can promise if new date is really realistic or not. We needed to find a way to improve this situation.
The second reason was the nature of features to be implemented. Modern technologies are changing so rapidly that planning 2 years in advance makes no sense - in 3 months there might already be an Open Source component, which might be easily integrated into the product without much internal effort. Or a competitor could come out with a "killing" feature, which should find some counterpart in our product in the shortest possible time. So flexibility in changing priorities and reshuffling the list of requirements is mandatory. There is actually not so much space to have reliable predictions.
Scrum allows us to find answers for what we need to do to build quality software faster. We've switched from a defined and predictive development to an empirical iterative incremental. This is exactly what Scrum is about.
If you want to learn some more about Scrum, I would recommend you to take a look on
Let’s quickly review some of the important values of Scrum:
Empiricism – this is the way to manage development and deployment of complex products
Empiricism is dependent on frequent Inspections and Adaptations – this allows people to check and reach goals
Inspections provide full Transparency: people involved know about the state of the product exactly as it is, not guessing or relying on statements like “we’re right on time”
Iterative development provides the possibility to generate visible Increments of functionality, thus progress is counted not by time or money spent, but by concrete results.
Self-organization – all participants of the project are committed to the common goals and it’s natural for human beings to do things better and faster when they can work in whatever way is most efficient for them, rather than being told by somebody how to do things. Integrity of the team is raised, pushing productivity and motivation upward.
Delivery – last, but not least, many great projects with very capable teams have failed to deliver anything. Scrum allows to teams to minimize risks along the way. Even if project is going to die, it’s better to know this, cut the losses, and kill it earlier, isn’t it?
In the next post in this series I'll talk more about iterative incremental development and how we implement it here at Polarion Software.