The Scrum approach to agile software development marks a dramatic departure from waterfall management. Scrum and other agile methods were inspired by its shortcomings. Scrum emphasizes collaboration, functioning software, team self management, and the flexibility to adapt to emerging business realities.
Your Scrum team is days away from the end of its sprint when it discovers a significant impediment—one that’s large enough to keep the team from delivering the product increment it’s negotiated for the sprint. So how should the team handle this late-breaking discovery? And what should the Product Owner do about it?
This is the question posed by InfoQ reporter Mark Levison in a recent post titled “When to Extend an Iteration/Sprint.” He aggregates advice from numerous Certified Scrum Trainers and, though there was some discrepancy among their responses, everyone seemed to be on the same page on this issue. Namely, all the CSTs surveyed explained that the team should inform the Product Owner as soon as the problem is discovered and that, under no circumstances, should the sprint be extended.
Perhaps the first point is an obvious one. When a problem arises, if the team informs the Product Owner immediately, it gives him or her more time to access the extent of the problem and formulate a plan of action with as much time remaining before the end of the sprint.
But why should a sprint never be extended?
In Scrum, development activity is organized in repeatable work cycles called sprints or iterations. It’s essential that sprints always be the same length because 1) it allows the development team to establish a rhythm and 2) lets the Product Owner observe the team’s velocity, which is extremely helpful with release forecasting. When a sprint’s length deviates, it undermines the repeatability of the process and erodes the urgency associated with sprint deadlines.
So what does the Product Owner do in such a situation?
First, the Product Owner should take stock of the situation. If work can be reorganized to salvage important sprint goals, it should be. But if the problem is too far-reaching for that to occur, then it should be treated like any other PBI in Scrum. That is, it should be returned to the backlog (where its acceptance criteria might need to be revised) and added to the next sprint. More thoughts on why awarding partial credit within a sprint is potentially harmful, take a look at this blog post by CST Michael James.Tags: Product Owner, Scrum Basics, sprint
I’ve mentioned here before that my team uses Danube Technologies’ ScrumWorks Pro to manage development efforts. Since Danube is a Scrum company, I check their site frequently for new content written by its team of Certified Scrum Trainers, which includes blogs, white papers, and more. When I visited the site yesterday, I was happy to discover that the company has launched a new video blog series, which gives folks a chance to watch a short clip of a CST discussing an issue related to Scrum. The first installment features Jimi Fosdick, who starts the conversation by asking, “What Is Scrum?” So far, the company has only posted one video, but I’m excited to see where this goes. It already looks like a great resource for Scrum users learning the ropes. Check it out here.Tags: Danube, Scrum Basics, video blogs
When organizations first transition to a new way of doing business—an agile method such as Scrum, for instance—the best way to ease the disruption and fear that often accompany such change is to educate your employees. Certainly, presenting the shift transparently will minimize undue anxiety, but, moreover, providing training can be an empowering process that equips employees with the knowledge to excel in their new work environment.
In the case of Scrum, many organizations engage Certified Scrum Trainers to train employees in a public course setting or to deal with specific organizational challenges as an on-site coach. And while there are many training options readily available, they aren’t cheap, nor is their instruction all of the same quality. When my company adopted Scrum, a portion of my team was sent to public ScrumMaster Certification (CSM) training with Danube Technologies. It was a great experience; all of us who attended felt that we’d learned a lot about Scrum and were armed with the kind of actionable knowledge we could take back to workplace and implement.
So what did training look like? I recently encountered a blog post written by William Roberts, the Chief Integration Engineer at Symbian Software Ltd., in which he discusses the CSM course he attended with Danube trainer Michael James. Much of his discussion compares and contrasts Scrum as it was presented in class and as it was actually lived out at his organization. You can take a look here: http://wtr1.wordpress.com/2009/09/04/wondering-what-on-earth-im-doing-here/
Coincidentally, Michael James recently recorded an interview for DZone, in which he discusses the value of Scrum and how Scrum practitioners can refine their skills as team members by observing the traits of highly performing teams in other disciplines. It’s a brief and very engaging video, which you can watch here: http://agile.dzone.com/videos/scrum-adoption-michael-jamesTags: Scrum training, ScrumMaster Certification
Since I last posted on the CSM exam, it seems the plot has thickened enough that another post is warranted. As I’ve explained previously, the Scrum Alliance recently decided to introduce an exam which all Certified ScrumMasters will be required to pass before receiving that distinction. It should be noted that only those individuals who have taken a two-day, Scrum Alliance-sanctioned CSM course from a Certified Scrum Trainer will be eligible to take the exam.
Well, after several delays and a recent rumor that the exam would be pushed back from its project Oct. 1 launch date, the exam is back and will, in fact, go into effect today. According to an email sent by the Scrum Alliance’s new president Tom Mellor on September 16th, “the initial release of the exam will not be sanctioned by any certification agency.” He continues on behalf of the Board: “The exam will continue to evolve and we earnestly desire that it be approved by a certifying authority in the near future. Our goal has been and continues to be to bring even stronger credibility to the CSM throughout the world. A certified examination will benefit us in this endeavor.”
For those familiar with this organization, you may know that this exam has been a source of much controversy internally and, it appears, resulted in the resignation of both Ken Schwaber, one of the founders of Scrum who previously served as the Alliance’s president, and Jim Cundiff, who previously served as the organization’s managing director. The fact of their departures illustrates just how polarizing this exam has been.Tags: CSM Exam, Scrum Basics, ScrumMaster
Very soon, the Scrum Alliance will introduce a new process to certify ScrumMasters. Previously, certification has been awarded to anyone who attends a two-day, Scrum Alliance-certified ScrumMaster Certification course. But beginning October 1, course participants will also be required to pass an exam within 90 days of attending training. Certification will be good for two years. At the end of two years, individuals will need to re-certify for CSM status. This costs $150, including Scrum Alliance membership fees, and lasts two years.
In some ways, this marks an improvement because it endeavors to ensure that a CSM fully understands the tenets of Scrum. Certainly, this is better than simply awarding an individual ScrumMaster certification based on sitting through a two-day class. That is, while CSM courses are incredibly beneficial for most participants, they do not guarantee that an attendee will necessarily absorb or apply everything he or she has learned. Of course, the flipside is that an exam will only test attendees on certain aspects of the Scrum framework in a format that does not necessarily promote a deep understanding of Scrum’s values.
What do you think? Is this an improvement over the existing certification process or an unhelpful amendment to a process that was working fine? I’d love to hear your thoughts in the comments section.
You will do better on the CSM or PSM exam by keeping your Scrum Reference Card handy.
Over at InfoQ, Vikas Hazrati points out the common misconception that a team’s velocity is directly linked to the value it yields for the organization. It’s a fairly understandable mistake: If a team accomplishes more in a given sprint, then surely it’s making a larger contribution to the organization’s success, right? Well, not necessarily… A team might set records for the number of story points it completes, but that doesn’t actually mean it’ll add up to “value” for the organization. For instance, what if the product it completes sits on the shelf and is never shipped because evolving market conditions render it irrelevant? What if it is shipped, but no one buys it? It’s easy to see that, once these aspects are considered, there’s really no connection between velocity and value.
Determining what agile-specific metric is best for quantifying the actual value generated through the team’s work has been a point of ongoing frustration for many managers. The best way I’ve seen this issue dealt with is in the ScrumWorks Pro tool, which employs several metrics—Business Value and Earned Business Value—to give organizations a way to track the actual business value being created in a product.
How does your organization track this? I’d be curious to hear your strategies for this in the comments section. Thanks!Tags: Scrum Basics, Scrum metrics, velocity
Scrum teams know that velocity is a rough estimate for the amount of work that a team can accomplish in a given sprint. It is calculated by simply adding up all the completed story points. Since the point values are merely estimates of the perceived difficulty and time necessary to complete the backlog item, a team’s velocity is not especially useful in and of itself. Instead, it becomes a valuable metric over time as teams complete multiple sprints and have the opportunity to establish a consistent velocity. Once this occurs, the Product Owner can look to the team’s established velocity to determine how much work it can tackle in the next sprint.
Amr Elssamadisy has just posted on the topic of velocity and concludes his post with the following questions: “Should velocity be used a metric for productivity? Should it be used for iteration planning? What about longer term release planning? Should it be used at all, or is it a wasteful practice?”
As always, I’m curious to hear how you’d answer those questions, so please share your thoughts in the comments section.
As you might guess, I’m of the mind that tracking velocity is a valuable process. However, the limits of its value must be understood, since it is derived from estimates (i.e. abstracted valuations) and not an absolute indication of progress or productivity. Thus, it can be helpful for sprint and release planning, but should be regarded as an estimate all the same.Perhaps the most valuable aspect of tracking velocity is the ability to observe how a team develops over time. That is, if a team consistently increases its velocity, it can be inferred that the team is learning to work together better and incrementally improving its performance.
To see an example of a team computing velocity, pay attention about halfway through this example Sprint Review Meeting.Tags: Scrum Methodology, Scrum Sprint Planning
For folks who are contemplating a Scrum transformation, the most compelling testimony usually isn’t found in a blog or a whitepaper, but in a case study. When an organization can read a detailed, step-by-step account of how another company did it and ended up better for it, it can give organizations the confidence they need to move forward. And the more granularly such case studies document the process of adoption, the more valuable they are for organizations following in their footsteps.
Samir Bellouti has just published a very detailed success story on the Scrum Alliance that covers the first year of Scrum adoption for an unnamed airline and travel agency. Tasked with rebuilding its travel booking application—from scratch—Bellouti suggested they use Scrum to manage the project. He then goes on to describe the team’s lack of understanding of Scrum (they understood the concept of daily meetings, but nothing else) and how they got off the ground for those initial sprints. The fact that the project is then examined a year later adds another dimension to the piece, showing that these things take time, but are worth the patience they require.
Here’s another great and very detailed success story I found on Danube Technologies’ website, which describes how a division of Intel used Scrum to manage an especially chaotic project.Tags: scrum success, scrum success story
If you’re new to Scrum and agile, or like me a long time Scrummer, there are always insights to gain from talking with experienced practitioners. I had a recent opportunity to talk with Michael James (link to his blog) of Danube Technologies. He clarified something extremely basic for me, but it cemented the relationship between Scrum and agile for me so I thought I’d share it with you all.
Our conversation started with me stating that Scrum was a process that fell under the general umbrella of processes called “agile”. He quickly stopped me right there and pointed out two subtle, but important corrections. First, Michael noted that agile is not a process (or collection of processes) at all; rather, it’s a set of principles summarized by the Agile Manifesto. Scrum, XP, and other methods embody these principles and so are described as “agile”. There is no real parent-child relationship though.
Second, Michael made clear that Scrum was not a process in the technical sense of the word. A process is a prescriptive and linear series of steps taken to repeatably generate the same output. Hmm, that doesn’t sound like Scrum at all! Since we’re constantly inspecting our work and adapting the backlog, there is no repeatability we’re striving for. Instead, Michael suggested we use the term “framework” or “method” to describe Scrum. These terms suggest that we have a skeletal framework within which things happen, but that the innovation and intelligence of the team fills in the
These two subtle corrections really changed the way I think about Scrum. Thanks, Michael!Tags: agility, Scrum Basics, scrum concepts, scrum framework
Posted by admin under Agile and Scrum
I just came across a recently published Forrester report called “Ensure Success for Agile Using Four Simple Steps,” that provides recommendations for how organizations can smooth out the agile adoption process and make sure it sticks. Written by David West, with assistance from Mike Gilpin and David D’Silva, the report draws on the experiences of companies using agile to manage complex projects (from HP to Wells Fargo) as well as companies who offer agile training and software solutions, such as Danube Technologies which publishes ScrumWorks Pro. It’s a great document for organizations considering an agile transformation or those who have taken the plunge, but are still encountering obstacles to adoption. To purchase it, head here: http://www.forrester.com/Research/Document/Excerpt/0,7211,54037,00.html
One of the most interesting aspects of this article was how Scrum is used almost interchangeably with agile. That is, while Scrum is in fact just one project management method beneath the umbrella of agile, there was virtually no mention of any other method. (Rational Unified Process (i.e. RUP) was mentioned, but Crystal, Spiral, and DSDM were not.) It’s clear that Scrum has become the most popular exponent of agile over the past few years, but West’s report suggests its popularity has grown to the point that it has become the face of agile. Nearly every concrete example provided refers to Scrum and, early on, Scrum creator Ken Schwaber is quoted about Scrum teams as a proof point of an “agile” trend.
In part, this squares with one of the report’s main points: “Make organizational change, not agile development, the main focus.” That is, agile development is only doing its job if it’s helping an organization improve its processes and become more effective and efficient. After all, if a team religiously follows agile practices and processes, but fails to enact actual change, then there’s no point. In that sense, any agile method can work for an organization, but I suspect West returns to Scrum time and again because it is the most widely practiced—and most successful—method.
What do you think? Is your team using another agile subset to manage projects? Or is Scrum just the standard? What reasons do you see as responsible for Scrum’s popularity?Tags: agile, Scrum Basics
Scrum Training Series
- Scrum based funding model – 20 percent May 9, 2013
- The Next Big Idea March 5, 2013
- On Being Available February 17, 2013
- Should Scrum Always Require the Product Owner to Attend the Sprint Retrospective Meeting? February 5, 2013
- Happiness Metrics January 23, 2013