Why You Should Use Scrum in Your Web and Mobile Teams?

Hello Everyone,

This is a discussion in reference to the following screen-cast: “Why You Should Use Scrum in Your Web and Mobile Teams”

URL: https://www.sitepoint.com/premium/screencasts/why-you-should-use-scrum-in-your-web-and-mobile-teams

The Screen cast was a brief presentation, which clearly identifies how Scrum works, in fact I did enjoy it … But here comes the question … How practical is implementing Scrum on a ongoing (i.e. almost legacy) application? Let me set the scenario so everyone can try to give their contribution and experience (i.e. I’m still trying ot figure out how it can benefit, but til then much more practical is the ‘Water-fall Methodology’ for me, unless I can see the real benefit of Scrum)


We have a 2-3 year old application; the application was built by a team of developers. The Product requirements were not properly documented, and the business owner has had a several meetings with the developers and requesting certain features, etc., to be available on the product. There was no proper ‘Solution Architects’ or ‘Documentation’ involved on the project, and among the developers the ‘Senior Developers’ started developing the product as they understood it.

During the last 3 years the product has been constantly updated with some or other feature; as these were not visualized at the time, and eventually when customers started using the product they start contacting the sales team asking for a feature and the marketing team evaluating the requirement give instructions to the development team to add the feature to the product. The product has grown with all these features over the last 3 years.

  1. Point No 1: The Technology they used has become obsolete; and they need to update the whole application back-end. Example the lets assume that the product was built on Zend 1 and now Zend 1 has reached

  2. its ‘end-of-life’, the product/application needs to be upgraded to the latest version of Zend 3.

  3. Point No 2: The product does not have proper documentation of requirements, etc, including no PRD’s, and whatever is available are scatted on various Emails and JIRA tickets that were created during the initial inception of the project.

  4. Point No 3: Although the application has 4 modules (i.e. Product Module, Admin Module, User Module, Customer Module); the application was built in as a single unit. i.e. interconnecting features and functionalities across the whole application. Example the application has a ‘CRM Functionality’ for the ‘Customer Module’, and part of that CRM are also available at the ‘Admin Module’ as well part of it used on the ‘User Module’. i.e. the application is built in a inter-connected manner, if the ‘CRM Function’ will have an issue, it will be reflected across all the other 3 modules. The application has not been developed in a SOA method.

  5. Point No 4: The development team consists of lets say 20 team-members, with groups of 5 each developers each, with a team leader at each group. Each of the Team’s (i.e. 4 teams) have been given a Module to work on, and each module has a range of functionalities which are still inter-connected.

  6. Point No 5: In order for the customer to be able to use the product properly each of the 4 modules should be workings fine at the same time. i.e. the product cannot work on a single or selected few features at a time due to the interconnection and dependency of the whole application.

  7. Point No 6: At end of the upgrade of Zend3 the whole application needs to be tested by the QA team. If bugs are found they will be fixed by the developers. Point No 7: In order to deploy the product to the customer, the 4 modules need to be completely tested and all bugs free. Once confirmed by the QA team, the product will be deployed to the customers online.

[Note: Below are some of the points why the scrum process is unable to be used on this project; unless someone more experience on Scrum might be able to point out how they might do it based on their experience.]

Issues & Notes of Scrum:

  1. Unable to work on a single module or feature that can be rolled out to the customers, as an legacy application the whole 4 parts of the application are required to work to-gather, and 1,2 or 3 weeks of Sprint might not be useful as the whole application has to work in order for the customer to be able to use the product.

  2. As no proper prior requirements have been collected or documented and the original requirements have changed over the time due to implementing small and new features constantly; having a clear ‘Story’ will be not be easy as some of the team members who developed the original product are no more available.

  3. Unable to identify or crate a ‘Product Backlog’ as the whole application is based on 4 modules and they all need to be available at the same time to have the product working. (n.b. not sure if the ‘Work-Packages’ can be considered as Back-Logs ? see below for work-package definition)

  4. ‘Product Increment’ cannot be achieved again as the 4 modules are required to get he product working.

  5. Product cannot go through ‘Short-Release Cycles’ as the product needs to work as a single unit, and can only be released when the QA has done the testing and all bugs fixed. Note this is an already available legacy application that is being upgraded on the back-end and not the product features.

Based on the above scenario implementing a ‘Waterfall Methodology’ seems to be quite logical. The product upgrade was achieved using Water-fall methodology as below:

Waterfall Approach:

  1. The team was divided to 4 teams, each team receiving a module out of the 4 modules.

  2. Each module’s related features were grouped in to ‘Work-Packages’, with each Work-package having a few tasks that needs to be accomplished in order for the ‘Work-Package’ (i.e. not sure if we can consider this as a Sprint ?)

  3. Eventually for each of the 4 modules, the work-packages and task were identified, and timelines defined, and developer resource added.

  4. Once each work-package was completed, it was sent to the QA team who would test and if bugs are identified, assign them to the development team, who will start working on them once they complete each module assigned to them.

  5. Once the bugs are fixed by the development team, a final QA test is carried out to make sure they are all bug free and working without any errors and working as per the currently available old application which was used as a baseline for comparison.

  6. Finally when all is a GO from the QA team, the System teams will schedule for deployment, after which a post-test is further carried out by the QA team to identify any unexpected issues on the live environment.

So based on the above, how good is Scrum on such a project and how could it have been done better than the waterfall methodology in this instance ?

All your ideas and inputs will be greatly appreciated in trying to understand how ‘Scrum Methodology’ could have been or could be used for Web Application projects.

This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.