An iterative incremental software development process

Scrum Software Development

Subscribe to Scrum Software Development: eMailAlertsEmail Alerts newslettersWeekly Newsletters
Get Scrum Software Development: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn

Scrum Authors: Pat Romanski, Stackify Blog, Ken Schwaber, Eric Robertson, XebiaLabs Blog

Related Topics: Cloud Computing, Scrum Software Development, SOA & WOA Magazine, Cloud Data Analytics


Sprinting into Cloud Computing

How Scrum Methodology helps cloud transformation

Cloud Migration Projects Execution: Now that the Cloud concept is settling down in the minds of the CXOs, apart from ready-made things like mail service, CRM Service and other IaaS services, it is also time to think about the Cloud migration project execution.

Cloud migration projects will be on the rise in the near future with the following characteristics:

  • An on-premise project that is identified to be moved to a public or private cloud and identified to provide value due to transformation
  • The application is built on a Cloud-friendly platform (Java EE or .NET) and migration to Cloud may result in a few changes , but not a complete rewrite
  • The application has several modules and certain features will be moved to the cloud and will work on a hybrid model for a while before completely migrating the application to Cloud
  • The business and IT community will be involved during the course of migration and their interaction is a full part of the project execution

Scrum and Cloud Migration Projects: Scrum is an iterative, incremental framework for Project Management that is driven using the Agile principles. Scrum methodology differs from document deliverable-centric, traditional waterfall methodology. Scrum also banks on real-world progress of the project. In Scrum, projects are delivered into smaller work packages known as sprints, which are typically one week, two weeks or three weeks in duration. At the end of each sprint, stakeholders and team members meet to assess the progress of a project and plan its next steps. This allows a project's direction to be adjusted or reoriented based on completed work, not speculation or predictions.

After a deeper analysis of Scrum methodology, it will be clearly visible that Scrum methodology is best suited for enterprises that are considering Cloud Transformation or Cloud Migration projects. This fact can be ascertained from the following table.

Scrum  Philosophy or Guiding Principle

Cloud  Transformation Project  Fitment

A key principle of Scrum is its recognition that during a project the customers can change their minds about what they want and need (often called requirements churn), and that unpredicted challenges cannot be easily addressed in a traditional predictive or planned manner. As such, Scrum adopts an empirical approach-accepting that the problem cannot be fully understood or defined, focusing instead on maximizing the team's ability to deliver quickly and respond to emerging requirements.

While   Cloud is fully adopted  now, not all the enterprises  have a clear vision of  how to migrate existing application to  Cloud. They would like try to multiple options across vendors  or even within the   Vendor choosing a best option. For example suppose a particular  client would like to move to Windows Azure,  he can try between  Relational Database  Service like SQL Azure or  a  big table based storage like BLOBs for storing certain artifacts.

Scrum provides a perfect methodology for handling the volatility  in the Cloud Transformation Projects.

In traditional   water fall method, end users are involved only in requirements management and user acceptance testing phases of the SDLC.

Scrum assumes deeper end-user involvement into the process. First of all, there is always something ready for production deployment at the end of each Sprint, whose acceptance process happens every few weeks. Second, Scrum team is glad to get a feedback as soon as a new feature (may be not fully functioning) is added to the daily build. It helps to stay on the same page with the user of the feature, make fine-tuning on the fly and avoid unnecessary development efforts. End users are getting exactly what they need and developers can implement even more features for more users.

Unlike  the traditional Software development inventions,  Cloud  is some thing which is adopted by business  in a much faster rate than  actual developer community itself.

This means that  a methodology  like Scrum  which actively involves Business Community  among many other stake holders as part of the process is most suited for  Cloud Migration.

A Cloud Transformation Project in Scrum Methodology: The following draft approach explains how the Scrum methodology can be applied for a typical Cloud Transformation Project. For the sake of case study a typical Cloud Migration project is assumed with eight Sprints and, depending on the size of the project, a Sprint can be one or two weeks or more.

Sprint 0 ( Planning Sprint): Most cases there is an initial Planning Sprint, also known as Sprint 0, that's used to provide a high-level plan for the subsequent Sprints. Typical deliverables of Sprint 0 from a cloud transformation perspective are:

  • Identify the potential list of use cases within the application or suite of applications that can be migrated to the cloud
  • Release plan for migration into the cloud for each feature
  • Most cloud platforms has many architectural components, so fitment of architectural components into the roadmap of the application will be another goal of Sprint 0

Sprint (1-5) Feature Sprints: These constitute multiple sprints, where the goal is to ensure that certain identified functionalities are being released for testing by the user community. These features need to be carefully identified so that the feature released is self-contained so that users can start utilizing or at least testing them.

For example if an application has both transactions and reports, and if the reports are dependent on transactions, then there is no reason to include the Features on reporting being included in earlier sprints.

The goal of the Sprint is to create a potentially shippable product increment - working, tested software. The set of features that go into a sprint come from the "Product Backlog," which is a prioritized set of high-level user stories and tasks. Which backlog items go into the "Sprint Backlog" is determined during the Sprint Planning meeting, held just prior to the start of each sprint. The team agrees on the items in the product backlog that must be completed. The team then determines how much of this they can commit to complete during the next Sprint. Ideally, during a Sprint no one is allowed to change the Sprint Backlog, which means that the requirements are fixed for that Sprint. Development is time-boxed so that the Sprint must end on time; if requirements are not completed for any reason they are left out and returned to the product backlog. After a Sprint is completed, the team demonstrates completed features to project management.

Sprint (6-7) Release Sprints: In Scrum we tell teams that at the end of each sprint they need to produce a "potentially shippable product increment." However, "potentially shippable" and "shippable" are not the same thing. Cloud Migration Projects will require the use of "release sprint" or "hardening sprint" at the end of a release cycle (say six two-week sprints then a two-week release sprint). The release sprint is meant to ensure that the Testable cloud application is actually fit into the target cloud deployment model with respect to non-functional requirements and other infrastructure needs; for example, assume that when we transform an application to a public cloud some of the specific activities of the Release Sprint are :

  • Setting up of Available Compute Instances and set algorithms for dynamic sclability
  • Use the features like Availability Zones, Geographic data centers, so that the application is highly available
  • Utilize the Security features like linking with the Enterprise Federated Directories for authentication
  • Ensure that the storage instances are set to utilize the appropriate backup features
  • If there is a need for On premise integration set appropriate integration points for the same

Cloud is here to stay. Green Field Cloud Projects are easier to think and implement, like creating an email system in cloud for the enterprises, the challenge is on the Cloud Transformation projects for migrating existing on premise application. Considering the political, cultural, technical and other logistic-related challenges, traditional methods of Project Management tend to have a higher failure rate for Cloud Transformation.

We find the Scrum Agile Model will fit the Cloud Transformation by mitigating the volatility associated with it, the following diagram gives a high level over view of the process.

Happy Sprinting into Cloud.

More Stories By Srinivasan Sundara Rajan

Highly passionate about utilizing Digital Technologies to enable next generation enterprise. Believes in enterprise transformation through the Natives (Cloud Native & Mobile Native).