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.
I recently attended a webinar hosted by Scrum company Danube Technologies. The session, called “Definition of Done: An Organizational Perspective,” was led by Dr. Dan Rawsthorne, PhD, one of Danube’s Certified Scrum Trainers. Over the course of an hour, Rawsthorne discussed creating and revising acceptance criteria for various kinds of user stories and how those stories can be used as standardized templates as well as an educational tool within a Scrum organization. In all, it was a great webinar; Rawsthorne clearly speaks from years of experience.
Sound like something you, your team, or your company could benefit from? Check out the entire list of special event webinars offered by Danube. They’re free and always hosted by a Certified Scrum Trainer. There’s a chunk of time at the end reserved for questions and, importantly, there’s no sales pitch. Highly recommended.Tags:
One of the best ways to illustrate how agile and Scrum can transform the way an organization manages its development is through case studies. Rather than simply saying that agile methods will streamline processes, reduce cycle time, and improve product quality, a case study illustrates how agile and Scrum can achieve those things. Moreover, they’re inspirational. When you can see that someone at another organization has experienced the same challenges and worked through them to successfully implement agile, it gives you the confidence to embark on that journey yourself.
Do you have an agile or Scrum transformation story you’d like to tell? If so, please post them here in the comments. To make things interesting, the person who submits the best one will receive a free iPod Nano.
Please make sure that the story you submit contains the following three sections:
- The Problem. What was going wrong at your organization that made you decide to implement agile or Scrum?
- The Application. Once your organization decided to use Scrum to surface dysfunction and transform its processes, how did you go about doing it? What were the first steps you took? Was it an organization-wide adoption or just on the team level? Did you use training or tools?
- The Solution. What was the result? Can you quantify the improvements that Scrum and agile helped realize? Have other teams at your organization begun adopting agile management techniques?
I look forward to reading your stories. Deadline for submission is Dec. 31, 2009 and please try to keep your case studies to between 500 and 750 words.Tags: Scrum case studies, success with Scrum
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
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
Posted by admin under Scrum Discussion
As some of you might know, one of the biggest influences on the development of Scrum project management is complex systems theory, especially in relation to adaptive life forms. That is, just as life forms have adapted to survive in evolving conditions throughout history, Scrum teams also adapt to real-world business conditions to remain competitive and “survive.” Interestingly, several Scrum experts have commented that the Scrum framework will not evolve—that its current construction is stable to endure as-is. In my mind, such an assessment seems not only short-sighted, but deeply contradictory. If the process is based on continual improvement and adaptation, why wouldn’t the framework itself be subject to the same kind of survival-motivated revisions?
I was pleased, then, to find this blog post by Certified Scrum Trainer Dr. Dan Rawsthorne, PhD, which charts the evolution of Scrum from its early days to the present and wonders where it might head next. Certainly, he’s been on the scene since the early days and has a great perspective, but, for the most part, he doesn’t really commit to any predictions about how Scrum will evolve. It’s something I think about every day as I run up against certain shortcomings at the organization and wonder if it’s the framework itself or simply impediments derived from the people working within it. And it’s definitely something I’ve been thinking about more as organizations (my own included) wrestle with scaling small-team Scrum for the enterprise.
What do you think? Will Scrum continue to evolve or is the basic framework set in stone, with no reason to adapt beyond its current state? If you do think it will continue to evolve, how so? Please post your Nostradamus-like predictions in the comments section.Tags: Scrum Basics, the scrum future, where is scrum headed
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
Posted by admin under Scrum Discussion
I just ran across this post (http://www.infoq.com/news/2009/05/chickens-in-daily-scrum) called “How Many Chickens Are Too Many?” on InfoQ, in which Vikas Hazrati reports on a rather lively discussion that occurred recently on the Scrum Development group. The discussion in question was triggered when one user posted that as many as four to five “chickens” attend his team’s daily standup. Given that his team only consists of five or six individuals, the ratio of mangers to developers is nearly 1:1.
Now, most Scrum literature clearly advocates that if a manager—or “chicken” as Scrum practitioners are fond of referring to them as—wants to attend the daily standup, he or she may do so as a silent observer. The daily standup is a meeting designed for inter-team communication. That is, it’s an opportunity for the team to speak with one another frankly about how the sprint is going. When managers are present, teams may skew the reality of their progress to present a rosier picture of development for them. Or worse yet, the manager may simply usurp the daily standup, using it as a time to micromanage the team. When this happens, Scrum’s emphasis on self-organization—that is, the team’s ability to choose how it will accomplish its sprint goals—is effectively undermined and management reverts back to a traditional, command-and-control approach. In my mind, the issue is clear. A manager should probably not attend the team’s daily standup meetings, but, if it’s essential, he or she should do so as an observer only.
Interestingly, many of the Scrum users who weighed in on the conversation claimed that this is not exactly a black-and-white scenario. Several explained that it depends on the particular culture of the organization. That is, if management is supportive of its developers and empowers them to make decisions (even if they’re occasionally the wrong ones), then there’s no harm in them attending this meeting. Of course, few of us have had the good luck to write software in such an environment. It’s far more likely that your manager or Product Owner is not exactly hands-off.
What do you think? Obviously, Scrum is designed to be flexible so that it can adapt to the needs of specific organizations. But should something as fundamental as this really be up for interpretation? I’m curious to hear your thoughts on this one.Tags: daily standup, Scrum Basics, scrum daily standup, scrum meetings, scrum teams
Posted by admin under Scrum Discussion
In a post on agile luminary Martin Fowler’s blog, he identifies a new strain of Scrum dysfunction that’s wreaking havoc on software development projects: “flaccid Scrum.” Here’s Fowler’s description of how this anti-pattern gets started:
- “They want to use an agile process, and pick Scrum
- They adopt the Scrum practices, and maybe even the principles
- After a while progress is slow because the code base is a mess”
What Fowler is describing here is an organization that has begun to use Scrum—and Scrum only—to manage its projects. For organizations developing software (or other chaotic technology deliverables), Scrum is not a substitute for agile engineering practices—not even close. In fact, Scrum intentionally omits engineering practices to give organizations as much flexibility as possible. That is, Scrum is about people and teams and believes that decisions about engineering practices should be left up to them, rather than prescribed.
Of course, Fowler understands this and is quick to say that a recent outcropping of so-called “flaccid Scrum” projects has more to do with Scrum’s surge in popularity than any inherent flaw with the framework.Tags: Flaccid Scrum, Scrum Basics
Scrum Training Series
- Do you REALLY want to learn Scrum? Try a 3.1-day CSM class with case studies. July 25, 2013
- Scrum based funding model – 20 percent May 9, 2013
- MJは６月と７月の２ヶ月間、日本に滞在する予定です。スクラムのコーチングまたはトレーニングに興味のある方は是非ご連絡ください。 March 14, 2013
- The Next Big Idea March 5, 2013
- On Being Available February 17, 2013