main_banner.png
How To Improvise Scrum For Corporate IT Projects

by This e-mail address is being protected from spambots. You need JavaScript enabled to view it

SCRUM or agile development was originally designed for “typical” software development. The goal of any software company is to release high-quality software to market as soon as possible. In my extensive experience in software product management, I can tell you that in this type of “typical” software development environment:

  • Scope is often not clearly defined and changes frequently. This is because there are more “unknowns” than in most corporate IT projects.
  • Rather than tracking the budget closely (as is often the case in corporate IT projects), software companies will spend as many resources as they need to, to release the software to market as soon as possible.

 

 
Scrum works well in 'Typical' software development
 

 

SCRUM works well in this scenario because it enables the software company to be flexible with the project scope by defining a prioritised list of features (called the product backlog). The developers commit to a set of features they will complete within a time period of less than 30 days, which is called a sprint.

At the end of each sprint they must produce “demonstrate-able”, “release-able” software. After just a few sprints, the software is used in sales demonstrations and if sales succeed, the product can be released to market early with only the highest priority features.

What if the project is not “typical” software development? What if it is a change to an existing system and it has a strict deadline, scope and tight budget — can your project leverage the SCRUM methodology? Previously, for this type of corporate IT project, I would fall back on the traditional “waterfall approach” to development; meaning the project manager would create a detailed plan up-front outlining estimates for design, development and testing. This approach is called “waterfall” because each phase is reliant upon the completion of the previous phase before it can commence (i.e. design before development before testing). A lot of time is spent up-front analysis of the solution before any development starts.

Waterfall Shortcomings

Waterfall’s primary shortcoming is that issues do arise, like it or not. As a result, the analysis phase includes wasted effort, the development phase takes longer than planned, and the testing phase must be shortened. Because a “release-able” solution is only produced at the end of the project, too frequently, the project runs beyond the deadline! Due to the nature of this methodology, the waterfall approach can frequently produce late or poor-quality solutions.

Wouldn’t it be better to have 90 percent of the features and provide a solution that works?

In contrast to the waterfall approach, SCRUM enables the project manager to quickly deal with unforeseen issues by adjusting the plan, resulting in a high-quality, on-schedule solution. Rather than creating a detailed plan for design, development and testing for the entire project up-front; using SCRUM, the team creates a high-level plan which outlines which features/changes will likely fit into each sprint in order to meet the deadline. Development begins as soon as possible, enabling the team to identify issues early and adjust the plan accordingly.



SCRUM significantly increases the likelihood of an on-schedule solution — possibly at the cost of reduced scope. If unforeseen issues arise, the last few sprints may not be completed. It is very important that you discuss this with the project sponsor in advance and ensure that they feel that quality and deadline are more important than some of the low priority features/changes.

SCRUM provides a higher-quality solution than the waterfall approach by ensuring testing is completed throughout each sprint. Defects are always given top priority ahead of new changes/features. This is quite different from the typical waterfall approach where the majority of testing is completed at the end, getting squeezed when development exceeds the timelines. In my experience, performing testing throughout the sprint not only increases quality, but can also decrease the overall timeline of the project. With the waterfall approach, during the testing phase, developers may be sitting idly waiting for defects; whereas SCRUM ensures that all of your resources are equally busy throughout the length of the project, thereby shortening the overall timeline.

Stakeholder Buy In

Another way that SCRUM produces a higher-quality solution is through incorporating stakeholder feedback. You can be assured that the solution will meet the stakeholders’ requirements because there are demonstrations at the end of each sprint, and increased communication between stakeholders and developers throughout the project.

To implement SCRUM for projects that are not typical software development projects, there are a few key steps you must follow:
  • Stakeholders must give input into a product backlog (prioritised list of changes/features) to define the scope for the project. The features may be re-evaluated and re-prioritised throughout the project.
  • Ensure you have project sponsor “buy-in”. They must accept that the scope could be reduced if unforeseen issues arise. They must agree that quality and deadline are more important than some of the low-priority features/changes.
  • Spend a small amount of time up-front to create a high-level plan which outlines which features/changes will likely fit into each sprint in order to meet the deadline.
  • Start development as soon as possible. At the beginning of each sprint ensure the team determines which features/changes they will commit to completing and how they will provide a demonstration at the end of the sprint.
  • Perform testing throughout each sprint — do not save it for the end. This will reduce the overall timeline and improve quality.
  • Demonstrate your solution to the stakeholders within 30 days. Ensure that their feedback is taken into account after each sprint. At the end of each sprint there must be a “release-able” solution.

 

Not For All Projects

By following the above steps, you will be using an improvised version of SCRUM. You will not be following all the SCRUM rules, but you are well on your way to using agile development.

Certain types of IT projects are better-suited to SCRUM than others. I have tried managing small projects, where an iterative, agile approach did not work. To implement SCRUM, the project must be broken down into meaningful “chunks” of work, or sprints. At the end of each sprint, the project team must be able to demonstrate the solution. For certain projects it can be difficult to break down the work in this way. If, after a few days of high-level analysis you realise that it is not possible to demonstrate anything to the client in a few weeks then ask yourself whether it is worth trying to use agile development.

To recover from a project that doesn’t suit agile development, identify this early in the project and move back to the waterfall approach. This is an easy transition if you are still in the high-level design phase. In my experience, the types of projects that don’t work include:
  • projects smaller than about two months of development work
  • projects where changes are very widespread or horizontal across an application (and therefore not easy to provide a demonstration within a short period of time)
Although SCRUM was originally designed for “typical” software development, it is clear that even for a corporate IT project with a strict deadline, defined scope and tight budget that an improvised version of SCRUM can provide substantial benefits over the waterfall approach including:

A higher-quality solution due to:
  • improved communication between stakeholders and developers through regular demonstrations and the prioritised product backlog
  • testing being completed throughout, rather than squeezed at the end
An on-schedule solution due to:
  • a more flexible high-level plan which can be adjusted based on unforeseen issues
  • a “release-able” solution at the end of each sprint
  • load-balancing of resources by performing testing throughout each sprint
In closing, I firmly believe it is worthwhile to try agile development for corporate IT projects using the steps outlined above and see if it works for your project. The benefits you will gain are well worth the effort and limited risk involved.

Contributed by  Lorraine Pauls Longhurst of LPL Consulting.
 
RocketTheme Joomla Templates

Email

Telephone

  • +61 2 9929 6890 - telephone
  • +61 2 9929 7879 - fax
  • +61 438 157 565 - mobile

Address

Level 11, 122 Arthur Street
North Sydney, NSW
Australia 2060