Bloggo back to the blog
G(r)ood testing 18: Scrum and time-to-market, the efficiency of Agile-->
I get many questions about the effectiveness of SCRUM. “To what extend does an organization benefit from SCRUM?”, they ask me, “What are arguments for or against the adoption of it?” Good questions. Promoters of agile state with great enthusiasm that agile is characterized by hyper-productivity and drastically shortened ‘cycle times’. Another advantage that is being emphasized is that SCRUM enables teams to deliver solutions in a short time. This is confirmed by Martien van Steenbergen also: “with Agile results are guarantied: you get working software within budget .”
But how effective is Scrum testing really? Hennie Huijgens  claims in his book that in comparison with a standard waterfall project, SCRUM projects are 34% faster and 27% cheaper. On top of that, he continues, the delivered software delivers significantly fewer errors. But what is faster? How is development speed related to the time-to-market? I believe this later determines the real benefits of agile. I think we are still lacking studies that provide us with an unequivocal answer. This is not surprising at all. SCRUM is not a out of the box, solution, and needs to be tailored to the organization. Therefore there are large differences in how the various agile projects are run. This makes it hard to come up with a generic all true answer.
Scrum adoption rates
Earlier this year I posted a discussion question on LinkedIn where I asked forum members to share the adoption rate of SCRUM testing within their organization. I received many responses. Funny enough these were answers didn’t explain how many teams in their organization were working with SCRUM. Most forum members emphasized the SCRUMButt or SINO (Scrum in name only) implementations. My conclusion: many teams are doing SCRUM just not quite right. If SCRUM is effective when done right, will it be effective for teams that dot not yet get in their hyper-production mode? Will the solutions they deliver me made available to their customers in a timely manner?
SCRUM: the most effective method?
You could argue that Scrum is not always the most effective development method. If you really know what you want to build and oversee the complexity of the project than the traditional waterfall is more effective. But in practice, organizations mostly do not know what they want to build and there are many uncertainties. Then an agile approach is clever. For where traditional projects get stuck, an adaptive approach brings you further. In comparison with the ideal situation agile might be more expensive. Agile developers do a lot of refactoring. With each code refactoring you throw away some beautiful code. The approach at least provides you with some working and useful code. The greatest strength of SCRUM lies in chunking: cutting the work into small pieces. If you work in sprints and if each iteration delivers a small chunk of working software, you ensure that your project always yields something. With SCRUM you are a price winner, but of course this only holds when you actually release your software.
What about the time-to-market
The actual time-to-market is determined by the release scheme that the organization has. Unfortunately many organizations that work with SCRUM, are not able to frequently deploy the code – developed, tested and done-to production. The reasons for this are multiple. Some real life examples: It may be because the output of different teams need to be integrated but not all of the teams work agile. A classic example is the app or web development. Frond-end adaptions can be processed and released quite quickly, but the back-office organization, in general, operates with a slower heartbeat. The deployment moment of integrated solutions is determined by the later and the deployment is delayed. I have been on a project where it was impossible to deliver and test the required data migrations in increments. This forced the whole project to release everything at the end. A big bang release rather than an incremental one.
In other organizations the releases are held up by acceptance tests and deployments that just cost too much time and effort. Testing is not yet automated and the deployment process complex. Some of these organizations have reduced the number of releases to a minimum. So rather than speeding up, they are in fact slowing down their IT delivery. But just as often the operational organization is the bottleneck. Firstly, I notice that the business finds it difficult to indicate which chunks provide value to their customers. It is a change in mind-set, and they have trouble with defining the Minimal Viable Product (MVP). On the other hand, the operational organization must be ready for the new products as well. Think of the help desk that should be able to answer questions about the new product options or sales that must sell the new products. We are talking about organizational readiness.
Time-to-market and SCRUM
A Scrum team regularly delivers small pieces of software. This can be very beneficial when these chunks represent real business value and when they are deployed towards production. The first requires that the business can identify a MVP that makes a difference to its customers. The second requires that the organization is able to incorporate the new product options in its processes. The time-to-market therefore depends not only on how well the development team has implemented its SCRUM testing, it depends on the weakest link in the entire software development chain.
 Argumenten kaart Agile adoptie – Martien van Steenbergen (2010)
 SCRUM werkt – Hennie Huijgens (2011)