Scrum Methodology

Scrum Methodology

For many developers in the software industry, the agile methodology is nothing new. Most folks know that agile was a direct response to the dominant project management paradigm, waterfall, and borrows many principles from lean manufacturing. In 2001, as this new management paradigm began to pick up momentum, agile was formalized when 17 pioneers of the agile methodology met at the Snowbird Ski Resort in Utah and issued the Agile Manifesto. Their manifesto is now considered the foundational text for agile practices and principles. Most importantly, the manifesto spelled out the philosophy behind agile, which places a new emphasis on communication and collaboration; functioning software; and the flexibility to adapt to emerging business realities.

But for all of the strides the Agile Manifesto made in revising a philosophical approach to software development, it didn’t provide the concrete processes that development teams depend on when deadlines — and stakeholders — start applying pressure. As a result, when it comes to the nuts and bolts of running a team with agile every day, organizations turn to particular subsets of the agile methodology. These include Crystal Clear, Extreme Programming, Feature Driven Development, Dynamic Systems Development Method (DSDM), Scrum, and others. At my organization, we use Scrum and I’ve found it to be an incredibly effective management methodology for everyone involved, including developers and stakeholders. If you’re interested in learning about the other agile methodologies, there are plenty of resources out there. This blog is designed to provide some essential background for those who are new to Scrum.

What’s Unique about Scrum?

Of all the agile methodologies, Scrum is unique because it introduced the idea of “empirical process control.” That is, Scrum uses the real-world progress of a project — not a best guess or uninformed forecast — to plan and schedule releases. In Scrum, projects are divided into succinct work cadences, 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.

Philosophically, this emphasis on an ongoing assessment of completed work is largely responsible for its popularity with managers and developers alike. But what allows the Scrum methodology to really work is a set of roles, responsibilities, and meetings that never change. If Scrum’s capacity for adaption and flexibility makes it an appealing option, the stability of its practices give teams something to lean on when development gets chaotic.

The Roles of Scrum

Scrum has three fundamental roles: Product Owner, ScrumMaster, and team member.

• Product Owner: In Scrum, the Product Owner is responsible for communicating the vision of the product to the development team. He or she must also represent the customer’s interests through requirements and prioritization. Because the Product Owner has the most authority of the three roles, it’s also the role with the most responsibility. In other words, the Product Owner is the single individual who must face the music when a project goes awry.

The tension between authority and responsibility means that it’s hard for Product Owners to strike the right balance of involvement. Because Scrum values self-organization among teams, a Product Owner must fight the urge to micro-manage. At the same time, Product Owners must be available to answer questions from the team.

• ScrumMaster: The ScrumMaster acts as a liaison between the Product Owner and the team. The ScrumMaster does not manage the team. Instead, he or she works to remove any impediments that are obstructing the team from achieving its sprint goals. In short, this role helps the team remain creative and productive, while making sure its successes are visible to the Product Owner. The ScrumMaster also works to advise the Product Owner about how to maximize ROI for the team.
• Team Member: In the Scrum methodology, the team is responsible for completing work. Ideally, teams consist of seven cross-functional members, plus or minus two individuals. For software projects, a typical team includes a mix of software engineers, architects, programmers, analysts, QA experts, testers, and UI designers. Each sprint, the team is responsible for determining how it will accomplish the work to be completed. This grants teams a great deal of autonomy, but, similar to the Product Owner’s situation, that freedom is accompanied by a responsibility to meet the goals of the sprint.

Comments Feed

Reader's Comments

1. Ramanjaneya sharma | January 6th, 2009 at 6:31 am

   Hi,
   Very nice and beautiful presentation about the scrum methodology..

2. Sandra Sears | January 17th, 2009 at 11:57 am

   Great post! Thanks for taking the time to discuess these very important concepts in project management.

3. Marsow | January 19th, 2009 at 5:47 am

   This is the short & clean explanation about the scrum methodology

4. Steve Strecker | February 9th, 2009 at 9:01 am

   Any recommendations for good tools to use for managing the SCRUM methodology - or creating and managing the overall Sprint Backlog?

5. Daniel Steiniger | February 11th, 2009 at 1:53 pm

   Hi, I’m working on a large software development effort and we use Rally. As with any tool, it’s only as good as the information that it contains but it does allow us to take the information and use it effectively.

6. Sai | February 12th, 2009 at 6:47 pm

   Very Very nice article. Thanks for posting the info.

7. admin | February 26th, 2009 at 11:28 am

   Hi Steve. As I’ve written on this site before, my team practices Scrum, so we use Danube’s ScrumWorks Pro. It’s tailored for use with Scrum, which is helpful for employees who are new to the framework. But even if your team is using another agile process, it’ll be similarly intuitive and easy-to-use. I love it! If you want to learn more about it, visit the Danube site: http://www.danube.com/scrumworks/pro

8. M N Mamun | March 8th, 2009 at 2:11 pm

   Its a nice summary of Scrum. Thanks for posting

   I am trying to write my Scrum experiences to explain the deep meaning of various terminologies, methodologies and techniques. You may want to check:
   http://evilword.wordpress.com/

   BR
   ~Mamun

9. shrivithal | March 11th, 2009 at 3:42 am

   This is good one. I have worked in the SCRUM methodlogy my experience say the plan of SCRUM should be done carefully and by skillful person.

10. Vandana | April 9th, 2009 at 11:00 am

    This is short, to the point and easy explanation. Even a naive user will find it easy to understand and grasp the methodology.

11. suwarna | April 22nd, 2009 at 12:32 am

    Thanks a lot for a short and informative note on SCRUM methodology.

12. Maurine | May 3rd, 2009 at 4:01 pm

    Thanks for the article, very informative and well written in describing the overall concept of SCRUM methodology. I’m new to the understanding of this method in particular as it relates to managing projects. I can really appreciated the efforts put forward in the sharing of this concept. Well Done!!

13. Brian | May 14th, 2009 at 12:21 pm

    As a seasoned professional software developer and architect, I can tell you quite simply that most career projects should have a minimum two week sprint. A one week sprint is absolutely unheard of in my experience due to unforseen complexities and analysis that must be performed in order to successfully implement solid coding to meet user requirements.

14. jimmy | May 18th, 2009 at 2:00 pm

    i have a question, who normally acts as the scrum master ? is it the project manager, or one of the team members ?

15. http://BusinessAnalystSite.com | May 27th, 2009 at 7:52 am

    It can be anyone but is normally someone not in the team who is actually involved with delivering the solution.

    Some businesses I have worked with as a consultant have had dedicated resources (from within the IT organization) that hold this position.

16. admin | June 4th, 2009 at 12:09 pm

    Hi Brian,

    I agree with your assessment. Every team I’ve ever been a part of has used a two-week sprint. However, most Scrum literature suggests that sprints should be between one and four weeks in length. Still, the only instances in which I’ve seen a one-week sprint really pay off is when teams are working on an especially volatile project and can’t afford to wait any longer than five days to adapt its approach to reality.

17. admin | June 4th, 2009 at 12:09 pm

    Hi Jimmy,

    Good question. Technically, the ScrumMaster is on the Scrum team, but is not a part of the development team. Having said that, the ScrumMaster should definitely not be the Project Manager (or Product Owner). The ScrumMaster is a separate role, who works to increase productivity for the team and the Product Owner. So this individual should be someone who is fully committed to the task. It really is an integral part of the framework and its value is significantly diminished when an individual attempts to be a “part-time” ScrumMaster.

18. Keval Solanki | June 8th, 2009 at 6:40 am

    very nice article about scrum!

Leave a Reply

Name (required)

Mail (will not be published) (required)

Website