Scrum Methodology

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!

What’s the Point of Velocity?

Posted by admin under Agile and Scrum, Scrum Basics

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.

Another Scrum Success Story

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

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.

Scrum is a Framework, Agility is a Concept

Posted by admin under Agile and Scrum, Scrum Discussion

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
gaps.

These two subtle corrections really changed the way I think about Scrum. Thanks, Michael!

Has Scrum Become the Face of Agile?

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?

Agile Two Years From Now

Posted by admin under Agile and Scrum

Victor Szalvay, CTO of Danuber Technology, makers of ScrumWorks, tells a story about his hope for the future of Agile in the next 2 years. “I think the coolest thing for Agile is if the core principles are still intact and hadn’t been corrupted by this push, this press for codification at the enterprise scale.”

Agile Conference 2008

Posted by admin under Agile and Scrum

Here’s an interesting video I reposted from the Agile Journal website: an interview at the Agile 2008 conference in Toronto between Agile Journal reporter Patrick Egan and Victor Szalvay, co-founder of Danube Technologies, Inc. and Product Owner for the ScrumWorks Pro agile management tool. It only clocks in at about five minutes, but, in that time, Patrick and Victor cover a lot of ground. Topics discussed include agile adoption trends; the evolution of agile tooling solutions; common challenges organizations face when adopting agile; and how Danube uses Scrum to manage all their projects, from budget forecasting to marketing.