Scrum Methodology
Learn the Scrum Methodology
The Scrum methodology of agile software development marks a dramatic departure from waterfall management. In fact, Scrum and other agile processes were inspired by its shortcomings. The Scrum methodology emphasizes communication and collaboration, functioning software, and the flexibility to adapt to emerging business realities — all attributes that suffer in the rigidly ordered waterfall paradigm.
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.
- 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.
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.
Comments Feed Reader's Comments
Leave a Reply
Newsletter Sign Up:
Loading ...Recent Posts
- Can CSMs and PMPs Get Along?
- Orlando Scrum Gathering in March 2010
- Free Scrum Webinars
- ScrumMaster as Impediment
- Advice for Agile Adoption
- Share Your Story
- Free Agile Resources
- Advice for Extending the Sprint
- Danube’s New Scrum Video Blogs
- What Happens at Scrum Training?
- The CSM Exam Saga Continues…
- The CSM Exam
- Back to Scrum Basics: Product Backlog Items vs. Tasks
- Value Versus Velocity
- Scrum and the Enterprise
Categories
- Agile and Scrum (16)
- Scrum Basics (31)
- Scrum Discussion (20)
- Scrum Transitions (8)
- Uncategorized (5)
Archives
- February 2010
- January 2010
- December 2009
- November 2009
- October 2009
- September 2009
- August 2009
- July 2009
- June 2009
- May 2009
- April 2009
- March 2009
- February 2009
- January 2009
- December 2008
- November 2008
- October 2008
- September 2008
- August 2008
Blogroll
- Agile Methodology
- Agile Programming
- Agile Project Management
- Eric Brown
- Free Project Management Software
- IT Today
- PM Student
Danube on Twitter
- Overheard from a Twitter post by @hyperionab
- Overheard from a Twitter post by @scrumworks
- Overheard from a Twitter post by @najarianbagy
- Overheard from a Twitter post by @BuffaloRaceway
- Overheard from a Twitter post by @derosewdvi
- Overheard from a Twitter post by @prideauxqjgf
- Overheard from a Twitter post by @Eastmad
- Overheard from a Twitter post by @eduarte
- Overheard from a Twitter post by @projectfile
- Overheard from a Twitter post by @ero3group
Hi,
Very nice and beautiful presentation about the scrum methodology..
Great post! Thanks for taking the time to discuess these very important concepts in project management.
This is the short & clean explanation about the scrum methodology
Any recommendations for good tools to use for managing the SCRUM methodology - or creating and managing the overall Sprint Backlog?
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.
Very Very nice article. Thanks for posting the info.
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
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
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.
This is short, to the point and easy explanation. Even a naive user will find it easy to understand and grasp the methodology.
Thanks a lot for a short and informative note on SCRUM methodology.
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!!
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.
i have a question, who normally acts as the scrum master ? is it the project manager, or one of the team members ?
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.
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.
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.
very nice article about scrum!
I noticed that Rally had some limitations in the ability to interface with other tools that control other aspects of a project, as in automated test results inserted into a database with a front end tool to display/manage defects, software tools used to track the review of key specifications and test plans. The SCRUM process still had great results. I believe one of the key factors that because much more refined and was predominant throughout the internal cycle of the product development was the focus on quality. The developers seemed to be much more agreeable to insert quality needs into the product, and the team developed a more cohesive relationship that almost bordered on intuitive knowledge of what other members would deem a success story. The only drawback I have seen in a sprint is the three hour sessions at the beginning of the sprint to determine the focus, as well as the three hour session at the end to present the result of the sprint efforts to the team. Those hours are rather precious in an environment where most resources suffer serious time constraints due to company downsizing. Has anyone else experienced this and if so, what successes can you share? This is a terrific site! I hope it continues. I am hooked on the article as well as the discussions.
Hi, I have a basic question about Scrum. Can a large scale project have multiple simultaneous sprints going in parallel? Are there any best practices on this?
Thanks
Hi, thank you verey mutch on this presintation…
I’m studying software engineering in Jordan, and we study the design and analysis for software projects, we use the waterfall, spiral, prototyping, incremental model, and some each other models and technique..
But we don’t have a clear idea about the SCRUM METHODOLOGY.
Can you help me to know more about it….I will be fathefull to you.
If you have any thing to give it to me…please send it to my e-mail
(loai_b@yahoo.com)
(loai_b@hotmail.com)
(loaisband@yahoo.com)
Nice artical for the new members.
is their only one scrum manager in agile or more than one.
Hi! Nice article explaining basics.
I have a question regarding the roles. What will be Release Manager’s(RM) role? How will RM add value using Scrum OR How will Scrum be used to release the product?
Hi Phyllis. Thanks for your kind words! Yes, planning and review meetings can be brutally long at times, but I suppose the way I think of it is that it’s better to know where you’re going than to start a sprint with fuzzy objectives and waste that time following the wrong direction. If these meetings did not include the team, they would certainly be shorter, but that would also undermine the essential input that the team provides during these negotiations. I have a hard time dedicating that much time to talking about the work that we have to do, but I’m sure the alternative would be much more disastrous…
Hi SG. Yes, absolutely. Although Scrum was created for use in small, collocated teams, it is also being used in extremely complex development environments, where there are several dozen Scrum teams working against different backlogs. In terms of best practices, it might be a good idea to take a look at Ken Schwaber’s book on Scrum and the enterprise. Something else to look into, though, would be the latest release of ScrumWorks Pro, which introduces some functionality that will make cross-product modeling an actionable reality (previously, most agile tool users had to dream up creative workarounds to accurately model their development). You can learn more about this release of ScrumWorks here.
Hi Loai. The best place information on Scrum I’ve found is the Danube Technologies site (www.danube.com). There are tons of free materials written by Certified Scrum Trainers, including white papers, blogs, and news articles. Dig in!
That’s a good question, Ekta. I’d encourage you to take a look at Danube’s blog where a number of trainers have been chewing on this question for a few months now. Head here: http://www.danube.com/blog
Hi Nitin. Scrum plays an important role in release forecasting because it 1. employs empirical data to drive prioritization decisions and 2. provides opportunities throughout the development cycle for the Product Owner to present the product-in-progress to the customer. The former point ensures that the Product Owner is looking at reality when making predictions about when it will be ready, while the latter ensures that the customer has a chance to shape the outcome throughout the process.
Hi, Please forgive my ignorance, I am a certified six sigma black belt currently working in manufacturing and have recently been introduced to the scrum methodology. I am very keen to understand scrum further and see it as a possible route into breaking out of the manufacturing sector and broadening my proces improvement skills even further. Can anyone tell me if obtaining this certification will aid me in my escape? and what potential roles would be available.
Regards
Craig
Hi, I would like to know how Scrum can be applied in an Onsite/offshore model. Will it work? Has this been practised before? Pls share your thoughts.
Nice posting bout Scrum. it would be great if their is some examples.
I’m thinking of implementing an EMAIL notification that basically would require ALL team members to EMAIL me their daily status and simply answer these 3 questions:
1. What did you accomplish yesterday?
2. What will you accomplish today?
3. Are there any road-blocks standing in your way?
Has anyone implemented an email Scrum notification and if so, does it work better or worse than the daily FACE-TO-FACE standup scrum?
Thanks
M
We use scrum in our workgroup and it sucks. It may be good for an isolated software team with well defined roles and who never get interrupted in the day from customers and other unplanned disturbances, or for a manager in a plant directing techies with the same context (i.e. isolated and simple clear goals).
Otherwise it’s just another way to make your life miserable and be micro-managed.
Mike Me,
I think that is a very bad idea. Sorry. The daily meeting is very much NOT a status meeting. It is a time for team members to align with each other. having them email one person (what role are you? manager, SM?) will break the concept od self-organization and collaboration faster than you can say “waterfall”. Don’t do it. Have the tema members talk to each other. Every day, in as a direct way as possible.
agreed with Tobias.
A good article to learn the SCRUM methodology.
hi,
i have always been exposed to waterfall methodology….i have just joined a comapny tht uses scrum but a product owner has experienced challenges in reporting to customer wrt to delivery dates??…please help with the following:
1. How does one link scrum to the project plan i.e. my understanding is that even if u follow scrum, project plans and road maps must still be done?
2. how can product owner communicate progress to clients i.e. prodcut owner that i am trying to assist is being given task that are to be done on dailiy bases but doesnt know how those tasks link to the final product??
Hope i make sense.
Xhanti
Hi,
I am seeking employment with a company that uses the scrum methodology. I am familiar with the Primer methodology (PMBOK) and would like to learn more about scrum. Can anyone help point me in the direction. Thanks!!
In response to Jose, who indicated that using Scrum “sucks”, I’d say that it’s not Scrum that is not working, but the implementation that’s not working. For e.g., the responsibility of the ScrumMaster is to remove impediments that may prevent the development team from doing their job, not to micromanage the activities of the development team. Some of the overriding agile principles are to ensure the customer is getting what they actually asked for, and to keep the lines of communication open. You’re trying to prevent surprises by ensuring that EVERYONE knows what is happening on the project at all times. Scrum and other agile methodologies were designed to prevent what occurs on many waterfall projects, which is that you don’t find out the project is way off course until too late in the lifecycle, wasting time and money.
My suggestion is to look at how Scrum has been implemented in your organization, compare it to what Scrum teaches, see where the differences are, and modify your implementation to align with what the methodology teaches. You may find that you’re not really doing “Scrum” even though you say you are.
Gain - I would recommend reading this website and also check out popular blogs like blogs.danube.com
Here’s a blog post for Gain as a starting point!
http://blogs.danube.com/your-career-in-scrum-pathways-to-starting-a-scrum-career
Is Scrum methodology useful for a testing project?
Scrum 101 explained at its best. Thanks. I feel Agile methodologies like scrum needs to be implemented at every level in the company not just development.
Hello all,
I am brand spanking new to the Scrum world. I am traditionally a WATERFALL guy and I am very confused on where testing fits into the scrum methodology. I understand the sprint cycles and all that and I understand that the code is developed to pass the tests. I guess where I am confused is in shorter sprints, say for instance, a one week sprint, where SQA run the intergration tests or the regression test.
Is this how it works or am I missing something here? Say we have a 1 week sprint.
** Mon - Wed (Developement of the test and the code.)
** Thurs - Friday (Integration/Regression testing as well as a product demo)
I am assuming that if this is the general idea that the SCRUM methodology relies heavily on automated regression testing, is this a correct assumption?
Thanks in advance for ANY help.
Thanks Ryan for the comments here is my recommendation:
QA & Scrum Blog posts here:
http://blogs.danube.com/scrum-and-quality-assurance
http://blogs.danube.com/junit-is-not-just-for-unit-testing-anymore
http://blogs.danube.com/generalists-vs-specialists-revisited
If you need more - just ask!
It’s a very good article. Just please let me know that using scrum, whether there is need of Tech Lead/Project Lead/Project Manager.
very well written summary …succint and clear..Thanks.
Great article, great questions, and great group commentary and advice.
I am running an Agile project as the scrum Master and we have had a great amount of success. This is a project that was stopped or put on hold twice over 2 years in Waterfall. We started Scrum in July of 2009 and have a final first release of our solution rollibng out to 10% of our locations (about 800) now through March. We have a complex solution, a team of sub small teams because of skill sets of their focus and anagressive timeline. We also had external vendors participating or owning some of the development. We are very happy with our results in 6 months. Here is my 2 cents:
- Read Mike Cohns Toward a Catalog of Scrum Smells. We hit all of these.
http://www.mountaingoatsoftware.com/articles/11-toward-a-catalog-of-scrum-smells
- The Product Owner Role is Key. Ours was involved and Co-located with the team 95% of the time. It made all the difference in the world.
- The preson that alked about Scrum not working in a environment where team mebers get pulled away to do support a lot We have that bad. We made it work. The scrum Master must get involved every time and be creative, negotiate.
- Those thinking of entering the scrum world, it helps to have some PM background but I would recommend you try. The best projects I have ever been on were those of colocated groups where collaboration and team work was the approach. Scrum Agile is a lot of fun and very rewarding. Not to mention efficient and sucessful.
QUESTION- Scrum is new to us and we did not follow it to the “T” but were adapted it “Cafeteria style” took what we felt we needed and it worked. My shortcoming is - How do you measure your progress from the beginning and forecast an end date when you never really know the complete picture or workload? Requirements evolve, scope expands (does not always creep)or becomes more robust, that makes it difficult to see what you have in front of you. The siza of the elephant if you will. We measure team hours burn against the project and timeline burn. I expect you will tell me that when we run out of time/money, we need to request new approval to move forward from what we have accomplished so far. I believe that is where we are at and I have no issue with that, I just would like a better metric on Progress through sprints as it relates to the Product Backlog
Thank s alot for this site.
Hi,
To answer Ryan’s question, in my team, the test team is 100% automation. We dont have any manual tests happening unless there is any automation-tool limitation. What this means is:
Each team has a tester (couple of them) and s/he’s a part of the pre-sprint planning and the daily scrum from which s/he knows the tasks and starts identifying/ designing the automation scripts for the functionality developed the previous day or the one which is going to be developed the same day (which also means the wire-frames or cut guides must be ready to automate). So the cumulative automation scripts are run twice or thrice within the 1-week sprint (we have 2-4 weeks sprints here). Another point is that unless there is automation, the test team will not be able to give a decision for that sprint’s deliverable within the sprint time. Hope this helps. If not, do add in your question here
@ScrumDog - I would read through Michael James’s macro-measurement white paper here: http://danube.com/scrum/whitepapers
Hi,
This article is really helpfull. Thnaks for posting. If somebody can explain this thru some diagram it whould be wonderfull
Really nice and helpful article. It clear all the queries in my mind.
Hi!
Thank you for a nice article. Can scrum be applied as a project management in general, not only software development?
What are the requirements for scrum to be sucesfull? (if you don’t consider the implemetation part..)