Interestingly, we at WebCollage have been recently hiring engineers to our Development Center in Tel Aviv (here’s a short promotion to our careers page). Perhaps not surprisingly, many of the people we interview have touched the Scrum development methodology in some way or form. Given the ubiquity of Scrum, it’s surprising how little discussion there is on why Scrum misses the mark when it comes to developing SaaS applications or web applications in general.
Like many software organizations, we had used Scrum in the past, and here’s why we feel it’s not the right tool for SaaS vendors.
Scrum in a Nutshell
In a nutshell, Scrum is a project management methodology which bundles several concepts and tools:
(i) iterative development (a sequence of iterations, each delivering value); (ii) a timeboxing approach (planning iterations with a fixed duration rather than varying their duration based on the deliverables); (iii) a planning, collaboration and role framework (more below); and (iv) reporting and tracking tools.
Iterative development and timeboxing are now somewhat prevalent outside of Scrum, so these days Scrum boils down to its planning and collaboration framework. In essence, Scrum advocates building teams of all-around developers. These developers conduct a short planning session at the beginning of each iteration with a “product owner”, and then self-manage the development and testing towards a committed goal at the end of the iteration. Inaccuracies in planning and other people issues are handled by the (all-around) software developers filling in for each other. Scrum further ensures that no new requests come in during an iteration, which helps align the committed scope with the committed timeline.
Is Scrum adequate for the construction industry?
There’s nothing in Scrum that makes it truly unique to software development. So, one may consider whether Scrum can be used, for example, in the construction industry. Based on the Scrum approach, a construction team would sit down at the beginning of the monthly iteration with, say, prospective apartment residents, and listen to how they plan to utilize the apartment (called stories in the Scrum vernacular). Then, they would commit to a certain scope (say: build one floor out of two). Then, they would work as a team to complete the elements required for that floor: flooring, windows, plumbing, carpentry, and so on.
If the Scrum approach is feasible, one may ask why industries other than software haven’t adopted similar methodologies. After all, they’ve been around for a while, and had plenty of time to create optimized practices.
Some of the reason a Scrum-like approach isn’t used in non-software domains relates to the the “soft” aspect of software. Specifically, it is much easier to change the first page of a web application than to change the first floor of a 20-story building.
But another fundamental reason—more specific to Scrum—is that it is unrealistic to expect a construction team to be truly cross-functional. The plumber is unlikely to be good at carpentry, and vice versa. (This isn’t universally true, but I doubt that Scrum fans would want a plumber to, say, install carpentry in their own apartment.) As a consequence, if all team members were to tackle a project together as a team, inter-dependencies (for example, windows cannot be installed until flooring is complete) would create huge inefficiencies because team members would have to wait fo other team members to complete. Human issues (sick leaves and such) would amplify such issues even more.
As importantly, dependence on external factors would further reduce the effectiveness of the team. For example, it’ll be quite hard to install windows until the actual windows arrive at the construction location; if the windows are late, progress cannot be made. And if ensuring that windows arrive on time is a core project task (versus a technicality that can be addressed by the so-called Scrum Master), external factors need to be considered as part of the planning.
Let’s put aside the construction industry, and move back to software-as-a-service (SaaS).
Why is scrum inadequate for SaaS?
In reality, the same two issues I outlined above apply to development of software-as-a-service applications, and—practically—to web applications in general.
Development of modern applications that face external customers is inherently made up of specialized team members. At a minimum, one would expect the development cycle to include some form of application design (some combination of user flow, schematic user interface, or actual graphical user interface and visual design), some form of writing (be it technical writing or friendly assistance write-up) and—I would want to hope—some form of user-oriented QA (at a minimum, testing for usability, friendliness and “smoothness” of the application; a task that cannot normally be carried out by the application developers).
What’s interesting in each of the above areas is that (i) it cannot always be carried out in parallel to core coding; and (ii) it cannot always be carried out by the same people. Minor variations in the application design and/or the visual design (e.g., a need for a new UI widget) can significantly affect scope and effort. So, the application design should really be nailed down ahead of the development iteration (as should the floor design ahead of an apartment construction). Customer-centric writing usually requires a different skill set than coders normally possess (though I’ve seen Scrum fans advocate using writers for QA tasks; I would again challenge such fans to apply this belief when they build their next house…). And, user-oriented QA can only commence once something is built.
While people have been proposing ways to adapt Scrum to address integration of specialized team members, these approaches often result in far-fetched variations. For example, some Scrum fans advocate conducting a separate pre-development Scrum for the application design team. If your company is successful doing this, I’d appreciate an invite. I have been curious to attend a daily standup (a scrum collaboration tool), which constitutes of exactly one person, as is often the case in application design. Other Scrum variations use the Scrum “brand”, but deviate so much from the original (simple and elegant) design of Scrum, that they truly formulate a different paradigm.
As importantly, a fundamental Scrum requirement is that development iterations are fixed in scope, and cannot be altered once started. In my mind, this misses the point when it comes to true iterative delivery of customer-facing applications. Suppose that you’ve just released Iteration N to your customer base and now started working on iteration N+1. Most likely, real input from customers would not be received immediately upon release. Instead, it would come in piecemeal throughout the subsequent few weeks. By the time the feedback is in, you’ve already started iteration N+1, and can only consider the requests, changes and feedback as part of the backlog for iteration N+2. So, in reality, you can only react to customer feedback (or, as I heard happens in other software companies (;-), resolve issues spotted by customers) in two iterations, which may take as much as two months. The diagram below tries to capture this limitation visually.
Shortening iteration durations helps alleviate part of this issue, but the fundamental issue is that Scrum rigidly offers no way to address time-sensitive market feedback.
Put differently, the SaaS reality is that external factors do weigh in during an iteration, and cannot simply be ignored or put aside for another iteration.
Is there a conclusion?
Well, for one thing, this note does not argue that Scrum is inadequate in general. Not only has Scrum played an important role in popularizing agile development, I believe it’s a viable tool for several classes of software applications (an obvious one being internal applications). However, Scrum is too far off the mark when it comes to modern customer-facing web applications, and other methodologies need to be called in.
In one of the next posts, I’ll try to outline some thoughts on how to better handle agile development and incremental releases in a SaaS (or: web application) environment. The key, though, is to acknowledge the real-life situation. When you consider the construction industry analogy I’ve used earlier on, it’s easy to spot that there’s a reason why not all construction team members work as part of a single construction project at the same time. Cross-dependencies and external factors do need to be factored in when devising one’s product release and product development methodology.