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.

3rd
NOV

Free Agile Resources

Posted by admin under Agile and Scrum, Scrum Basics

I always like to point out valuable resources for those who are beginning to use agile and Scrum at their organization. While I’d always recommend that those who are serious about Scrum consider taking a Certified ScrumMaster course with a knowledgeable and experienced Trainer, it’s always good to have supplemental resources like the Refcardz produced by DZone to give developers a helpful cheat sheet on a wide array of topics. Previously, DZone published an introductory guide to Scrum authored by Michael James, one of Danube Technologies’ Certified Scrum Trainers. If you enjoyed that one, they just published a related Refcard on agile adoption and how it improves software quality. You can download it here.

Tags: , ,

28th
OCT

Advice for Extending the Sprint

Posted by admin under Agile and Scrum, Scrum Basics, Scrum Discussion

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: , ,

16th
OCT

Danube’s New Scrum Video Blogs

Posted by admin under Agile and Scrum, Scrum Basics

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: , ,

1st
OCT

The CSM Exam Saga Continues…

Posted by admin under Agile and Scrum, Scrum Discussion

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: , ,

14th
SEP

Back to Scrum Basics: Product Backlog Items vs. Tasks

Posted by admin under Uncategorized

The Product Backlog is a force-ranked list of Product Backlog Items (PBIs), which should represent customer-centric product features. The Product Backlog should not contain tasks.

Since it is the Product Owner’s responsibility to determine what work will yield the most business value, the Product Owner prioritizes the PBIs. The Product Owner focuses more on the “what,” while the “how” is left for the team to decide.

The Product Owner and team should collaborate about an hour per week on backlog refinement (aka “backlog grooming”) to convert large fuzzy requirements (“epics”) into more distinct user stories. If a PBI would take more than a quarter of a two-week Sprint, it’s probably too big.

Only a subset of these PBIs, the Sprint Backlog, are tackled by the team in a given Sprint. During Sprint Planning, and during the Sprint itself, the team discovers and tracks the Sprint Tasks necessary to accomplish each PBI in the Sprint Backlog. I often meet teams that cannot distinguish their Sprint Backlog from their Product Backlog, making me wonder whether they have clear goals.

My favorite way to keep track of Sprint Tasks is with a physical taskboard, owned by the team. The team is less likely to self manage if people outside the team, including the Product Owner, try to scrutinize their progress during the Sprint, particularly at the Task level. The demo at the Sprint Review Meeting is a more appropriate time to inspect and adapt the product.

If the effort to accomplish PBIs is estimated, we prefer relative units such as T-shirt sizes or Story Points—i.e. abstracted estimates of difficulty. Sprint Tasks should usually take one day or less. Some teams find it useful to estimate Sprint Tasks in hours, though we eventually stopped estimating them at all. Also, there’s no point in trying to reconcile the effort estimates of PBIs and Sprint Tasks.

 

Watch a team break Product Backlog Items (PBIs, or User Stories) into Sprint Tasks during the Sprint Planning Meeting.

 

Tags: , ,

10th
SEP

Value Versus Velocity

Posted by admin under Agile and Scrum, Scrum Basics, Scrum Discussion

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: , ,

4th
SEP

Scrum and the Enterprise

Posted by admin under Uncategorized

As Scrum continues to grow in popularity, one of the hottest topics on the minds of the community is how to translate the benefits of a paradigm created for small, collocated teams for enterprise-level installations of hundreds, if not thousands of users. Given that communication channels increase (and therefore communication decreases) as the size of a team grows, this issue is only compounded when teams begin to scale to Scrum-of-Scrum configurations. Clearly, the solution is a tool designed specifically for Scrum projects that can allow teams to remain small, but nonetheless connected to the bigger picture.

Of course, the tool also needs to be flexible enough to meet the unique demands of large and complex development environments. For example, large organizations often develop products with shared components, which require the ability to plan releases against multiple backlogs. And while Scrum and other agile management methods have steadily crept into the software development landscape, the project management tools available have not kept pace.

But all that may be changing now. I just watched a screencast of ScrumWorks Pro 4 and this release’s new functionality makes it the first truly enterprise-ready Scrum tool. Namely, it addresses the issue outlined above by allowing customers to manage high-level features and releases that span multiple product backlogs. This is a really important breakthrough. Before that functionality existed, organizations had to creatively develop workarounds for their agile tools to achieve the same effect, but, still, with less-than-ideal results. Now, products can be associated with multiple programs, which, in turn, allows shared components to be modeled accurately while providing organizations with a more realistic view of overall progress. This is going to eliminate some very big headaches for some very big companies… You can read more about it here.

Tags: , , , ,

12th
AUG

Where Is Scrum Headed?

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: , ,

17th
JUN

Standing Room Only

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: , , , ,

4th
JUN

Flaccid Scrum?

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: ,

Scrum Training Courses