InAweofGod’sCreationProduct development needs consistency
The basic idea of Scrum is to create a safe and change-free environment to enable a team to concentrate on the planned development tasks. The team plans out a sprint of typically two weeks and the idea is that they work uninterrupted during this period. This process really helps to get things done. It avoids the “new == important” trap where everyone thinks that this new idea is much more important than the one they came up with a month ago. Feature development needs consistent priorities to be successful.
A web application is a living beast
Fast forward to running and maintaining a successful web application. Thousands of users hammering it, finding bugs, making it creak under load, and even abusing it. There is constantly something to deal with by your technical team. They need to stop spammers, fix critical bugs, and optimize slow database queries as fast as possible. None of these issues can wait for the next sprint of a Scrum process.
Scrum is too slow for running a web application
Scrum enables you to deal with changes in priorities and to release new features every two or four weeks. For developing desktop applications (like embedded software or mobile apps), releasing every two weeks is already a great achievement. But, I’ve yet to see a web application, which doesn’t need one or two releases per week.
Web operations demands continuous releases
If your development team is currently split into silos and customers don’t see new features for months, consider introducing Scrum. It will help you to break down silos and build real teams where people take responsibility and start working together. And, it will make your users happy since they start seeing valuable stuff every two weeks.
But, don’t stop there. Be aware that even two week learning cycles are pretty long for today’s web business. Users are only one click away from your competitor. Keep them happy by constantly optimizing your product. And, of course, Scrum will not help you in dealing with everyday issues. Make sure you have an additional process like Kanban to deal with those. Otherwise, Scrum might fail and your trip to becoming more agile and productive is suddenly over.
What is your experience with introducing Scrum for developing a web application? How do you deal with the constant flow of things which need to be done? Let us know in the comments!
Agile Web Operations 
Where, exactly, is it written that Scrum Teams may not release more than once per Sprint?
Continuous Deployment is not a barrier to Scrum, they can work very well together.
LikeLike
You can actually have one week sprint or even one day sprint if two-week sprints are really that long for you.
LikeLike
I’d argue that in the extreme you could follow Scrum and do daily releases. Why not? There is nothing in Scrum that defines a minimum time period. You meet in the morning to decide what is getting done that day. By the end of the day the new code is deployed.
Scrum is not the problem.
LikeLike
I agree that scrum is not the problem. But the “A web application is a living beast” is very accurate and is one of the problems why sprint might fail if the site is already on production and you are making incremental updates. Fixing critical bugs, dealing with server issues, etc.. Ideally, none of those should happen post launch, but I have yet to see a project going live and being 100% solid and perfect. The sprint deliverables do tend to slip due to external interferences. My solution to this has been to allocate X hours per sprint to Production issues. If those are not used, great, we can do more product backlog items, but if they are used, it will not jeopardize what was agreed during the sprint planning.
LikeLike
While Scrum does allow multiple releases to Production per sprint, Scrum actively discourages introducing new work mid-sprint. Kanban can be useful in this situation, instead of twisting Scrum into something it isn’t.
LikeLike
While the team works on the Sprint there can be a second team working on the *release branch* pushing out the fixes as needed.
LikeLike
I don’t agree with your title ‘Why Scrum falls short for Web applications’. Any web based production system is going to have to deal with ‘more immediate’ situations than can wait for two week sprints, but that doesn’t mean Scrum doesn’t work for web applications. I would suggest Scrum works great for the new features/enhancements development. Use Kanban for maintenance/emergency activities. This way the development team still gets the advantages of a stable two week period to complete new features, while also being able to react quickly to production support situations.
LikeLike
wow – and again a myth about Scrum and KANBAN gets discussed. As Scrum would create the problem of being too slow, and KANBAN would resolve it. We are specialized in helping WEB 2.0 companies, like web portals to deal with their problems using Scrum. And what we find is not that you need 2 or one week iterations in Scrum. We do find:
A lack of responsibility for prioritization
A lack of understanding what is necessary
Developers who do not create a good code quality
Time to market is too slow because development teams are too late involved and and and and …..
Scrum is not the problem, nor KANBAN the solution. And even Scrum is also not a Solution or KANBAN. Both ideas help teams to visualize the real issues in the companies.
If you need continuous deployment in a web 2.0 world, Scrum will perfectly show this. And if Kanban helps to implement an additional row for non planned items on the board … do it. Create. Use what helps.
LikeLike
I think Boris hit the nail on the head, a lack of responsibility for prioritization.
I have changed sprint durations or created special teams to manage “rapid-fire sprints” after gathering data to show that the business needs quick and continuous turnaround on application features, functionality and customer service.
This should all be framed around ‘business requirements’ and not the type of application we are delivering, imo. Regardless of your platform, service or application, we must ultimately respond to the business in a high-quality, fast manner.
Good article, Matthias.
LikeLike
A little late, 1 yr after the post, but nontheless an interesting subject…
All of the commenters above are on track I think, and lack of responsibility may be a problem.
However at least in my mind, reading between the lines, the problem stated in this post is not that no one takes care of bugs, or that mid-sprint releases are impossible, but that if the team has X points of work in a sprint, and the sprint is overwelmed with bug-fixes and priority issues, then the user stories in that sprint will not get done.
Thus that sprint failed to deliver, and you re-plan some issues for the next one- however in that one more bugs comes in etc etc
Also this creates a problem where you have to break in the middle of doing work because the sprint has ended, although you know that in a few days you’ll just have to finish up anyway…
/K
LikeLike