(This is Part II of a two-part piece. Click here for Part I) The scrum methodology offers flexible, results-oriented project structures with an emphasis on incorporating and embracing change throughout a project’s lifecycle. It’s an ideal framework for projects that evolve and change as much as software development projects do.  Seriously, if I told you, “We can give you what you want and need, we can have something for you to test within a few weeks, and we can incorporate loads of changes as the progress progresses,” wouldn’t you say that sounds like a great plan? 

Scrum is minimalistic, but not simple.  It’s basic, but has the framework to handle the most complicated and evolving software projects.  The fundamentals of Scrum keep everyone involved on the same page throughout the project’s entirety and ultimately results in a higher-quality product at the end of the project.

Basics of Scrum

To start, you have a Product Backlog – a list of features and functionality outlined in user stories that effectively communicates the goals of the site or software.  User stories are carefully outlined to incorporate the different functionality that the users need to be able to do (i.e. Create a Username/Password to gain access to the site or the ability to save out a document and name it however they want).  Each user story is then prioritized by the product owner, the person who is assuming the responsibility of determining the budget, direction, and overall final product.  As the user stories are prioritized, the scrum master can then take each of the user stories that will fit into an iteration, or sprint, of no more than 3-4 weeks.  The development team then tackles the user stories that have been assigned to that sprint, testing their work as they go.  Throughout the sprint, the team (product owner, scrum master, and development team) meets daily to review the progress and in a meeting that should never last longer than 15 minutes, the team gives their status – what they did yesterday, what they’re going to do today, and any impediments that are standing in their way.  At the end of the meeting, the development team breaks to take care of the day’s work while the scrum master focuses on getting the impediments out of the way so that the developers’ progress is not slowed.

This goes on for the duration of the sprint and, at the end the team has something that has been set up to be accepted by the product owner as software that’s performing as expected.  While the product owner reviews and accepts the sprint’s work, the development team jumps into the next sprint’s activities, which were planned and prioritized by the scrum master and product owner while the previous sprint was being developed.  This process goes on as long as there is work in the product backlog and funding from the product owner.

Benefits of Scrum

While the logistics of scrum seem fairly simple, the potential benefits to running a project this way can be monumental.  From the high level of flexibility that allows for the inevitable changes to be incorporated to the highly increased speed to market, scrum offers benefits that make it difficult to ignore when starting a software development project.

Change, Change, and More Change

Every project is going to experience some level of change – whether it’s about building a car that can be driven on Mars  or a piece of software that creates the CAD files that will aide in the design of the Martian rover, change is all but inevitable.  By breaking the project down into small, digestible pieces and keeping everyone involved throughout the process, change is much easier to incorporate and encouraged to benefit the overall success of the project.

You Don’t Know What You Want Until You Interact with It

Oftentimes, you don’t know what you want until you interact with it.  When you’re in the planning phases, you may think that one piece of functionality seems like the best idea anyone’s ever had, but once it’s built, you realize that you don’t need it at all. Approximately 64% of the features that are built into software projects are used "rarely" or "never"1. So why are companies dumping their limited funds into a project where such a high percentage of the features and functionality will never be used?  Because they’re trying to plan for everything they may need…and they don’t know what they will or will not need until they interact with it.  Imagine prioritizing everything on your list from the most important to the least important and, as the project progresses, there are other features and functionality that come up that you may have overlooked in the initial planning phases.

Reducing the 64%

Because you have already determined which features are the most important, you can prioritize these changes in the queue with the other features and, as changes come up and new technologies, ideas, requirements come up, you can prioritize them in comparison with everything else in the queue and bump the lower priorities off the list, if necessary.  Since you’re not locked in to any specific functionality outside of the current sprint, you have the flexibility to reassess requirements and reprioritize as necessary.  You can even knock functionality out if you find that it’s not as important as it initially seemed, therefore eliminating features that may end up a part of the 64% that are rarely or never used.

Quicker to Market

Theoretically, at the end of each sprint, you have something that can be pushed up to a live environment and, since you’re prioritizing features and functionality as you go along, you’re always going to have the very most important things coming out of the early iterations.  After a few sprints, you have a reasonably-sized site or piece of software that can be pushed out into the world, where it can begin collecting user data to incorporate changes and enhancements into future sprints.

Higher Satisfaction of the Final Product

Since the product owner has been involved throughout the process, the probability of acceptance at the end of each sprint is very high.  This allows the development team to continue forward movement on a project rather than having to stop, go back, and do something over or make significant changes.  However, even if changes are requested at the end of the sprint, it’s easy for the team to incorporate them into future sprint so that they don’t lose momentum.  Ultimately, everyone from the product owner to the development team will experience a higher level of satisfaction on the overall project because everyone is working together to create the best product possible. 

I think where scrum makes people uncomfortable is in its inherent flexibility and how encouraging it is of change.  Many people, at some level, are uncomfortable with change and that’s totally normal – people like to know what the plan is so they have some reassurance that they’re headed in the right direction.  They want to know what the outcome or final product will be.  However, software development projects are always going to change, regardless of whether they’re run through a waterfall approach or with an agile methodology.  Scrum simply provides a more accommodating environment for these all but inevitable changes, resulting in a more focused and successful solution.

PART II REFERENCES

1 - http://esj.com/articles/2009/02/10/agile-and-the-fine-art-of-gathering-application-requirements.aspx