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.


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


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.

To see an example of a team computing velocity, pay attention about halfway through this example Sprint Review Meeting.

Tags: ,


Great Free Guide to Scrum

Posted by admin under Scrum Basics

If you’re just beginning to learn about Scrum, you’re probably hungry for introductory materials that break it down to the basics. DZone frequently publishes “Refcardz,” pocket reference guides for developers on pertinent topics, from IDEs to programming languages. A few weeks ago, DZone published one of its best. Authored by Danube CST Michael James, it’s on Scrum and, best of all, it’s free.

Certainly, there is nuance involved in successfully managing projects with Scrum and, as James suggests at the end of the Refcard, the best way to learn Scrum is through a two-day ScrumMaster Certification course. Still, having a reference like this—authored by someone who has lived and breathed Scrum for years—is a very handy resource, indeed. It includes an overview of Scrum’s roles, meetings, and artifacts, as well as brief discussions of more advanced topics, such as scaling for large installations and related practices. Even if you’re a veteran practitioner of Scrum, I think you’ll see the value of a document like this, especially as an aid for helping new teams learn the ropes.

You can download the pdf below.




Some Thoughts on the New CSM Exam

Posted by admin under Scrum Basics

There are frequent grumblings in the Scrum community about the generally lax nature of certification. Given that the number of CSTs has practically doubled in the last year, it might appear that the Scrum Alliance is certifying more trainers than the market for Scrum training can support. Then again, it also coincides with Scrum’s spike in popularity over the past two years. But even more concern has been raised over a new exam that the Scrum Alliance is beta-testing for ScrumMaster certification. Certainly, exams are used in countless industries to assess an individual’s candidacy for a particular certification. So why does this pose a problem for certifying ScrumMasters?

As CST Mishkin Berteig points out, a two-day Certified ScrumMaster course can provide attendees with a basic foundation of Scrum knowledge, but it can’t adequately prepare them for limitless scenarios they face as actual ScrumMasters. In Berteig’s estimation, this new beta test “simply cannot measure any level of competency. They simply measure people’s ability to pass exams.” His suggestion to address this issue is to have individuals take the test prior to attending a CSM course. Not only would this ensure that participants possessed a bedrock of Scrum fundamentals prior to the course, but it would also allow CSTs to go deeper during the two-day course. It’s not a bad idea; it would definitely make the CSM course—and attendant certification—more meaningful.

Still, I think what the Scrum Alliance is doing is very necessary. Without any kind of regulatory or certifying organization, Scrum could be damaged further by self-proclaimed experts dispensing uninformed advice. I see this all the time as I read Scrum and agile blogs. (It’s pretty terrifying to read a blogger authoritatively dishing out advice that would make any CST pull his or her hair out.) The current certification process may be in need of some tweaking—hence the development of the CSM exam—but I firmly believe the community would be much worse off without it.

The debate continues over at InfoQ.

Tags: ,


Guest Column: Scrum Transitions, Part 3 of 3

Posted by admin under Scrum Basics, Scrum Discussion, Scrum Transitions

Scrum Methodology’s Guest Column feature asks individuals throughout the Scrum community to address an issue that is a common obstacle for Scrum teams. In the final part of the inaugural column, entitled “Scrum Transitions: Do It Once, Do It Right,” Katie Playfair, director of client services at Danube Technologies, Inc., discusses how teams can work toward making a Scrum transformation a success—long before the transformation actually occurs.

Scrum Transitions: Do It Once, Do It Right, Part Three
Don’t fail before you start – avoiding common pitfalls prior to the pilot stage

By Katie Playfair, director of client services, Danube Technologies, Inc.

So you’ve got your team – now what?

It’s almost time to start sprinting but not yet!  The manager trying to spark this Scrum transformation needs to make sure their (hopefully) all-volunteer pilot team is armed with the tools they need to be successful at Scrum. The first thing they need to do is understand what Scrum is. There are two basic categories of knowledge about Scrum that will help the team begin practicing:

Knowledge of Scrum mechanics:

  • Roles, meetings and artifacts
  • Story-writing (requirements) basics
  • Vocabulary
  • Common patterns and anti-patterns

Understanding of Scrum principles:

  • Reflexive knowledge of Scrum values
  • Embrace of guiding principles
  • Ability to apply values, principles and practices to scenarios not discussed in class

Although the first category of knowledge can be taught at a very basic level through books, blogs, and other didactic tools, the second must be taught through experiential means. Managers have a variety of providers to turn to and should consider the following factors:

  • Does this instructor have experience implementing Scrum at an organization of similar size and type to yours?
  • Is this person highly accessible and responsive to our questions and needs? Do they, or their educated staff, get back to you quickly with answers?
  • How involved in and respected by the Scrum community is this instructor?
  • Do they have case studies or references to back up their claims?

Once the pilot team has received some high-quality training (remember, we’re keeping costs low by limiting our audience to only those who will be immediately practicing Scrum), a manager should also be looking into infrastructure that will help them be successful. When piloting Scrum, it is extremely preferable that the entire team be co-located, if possible in the same room (team room). If facilities make that impossible, managers should seek to approximate in-room co-location as much as possible by providing some shared space for the team to have their daily stand-up and sprint planning, review and retrospective meetings. Although it is best to allow the team to develop its own tools for tracking sprint commitments and work, managers should be prepared for the need for a physical task-board area, a virtual way of tracking tasks through a Scrum-centric project management tool, or both. Often at this phase of the project, managers do not yet have senior management support or much financing to work with. Fortunately, there are free tools that can provide this necessary infrastructure without having to go through the budgeting process.

Motivated, educated, and armed with tools…

With an educated volunteer team armed with motivation, eagerness to try Scrum, knowledge about the framework and infrastructure to support their work, managers can finally feel free to let the team actually start sprinting. Now that the team is ready to sprint, the team needs to be successful in two major ways:

1. The team needs to be successful on a project that demonstrates the value of Scrum to the organization.  Essentially, they need to “show me the money!”

2. The pilot team needs to experience success and enjoyment from the process, so that their motivation level stays high to continue on with the pilot.

Tags: ,


Guest Column: Scrum Transitions, Part 2 of 3

Posted by admin under Scrum Basics, Scrum Discussion, Scrum Transitions

Scrum Methodology’s Guest Column feature asks individuals throughout the Scrum community to address an issue that is a common obstacle for Scrum teams. In part two of the inaugural column, entitled “Scrum Transitions: Do It Once, Do It Right,” Katie Playfair, director of client services at Danube Technologies, Inc., discusses how teams can work toward making a Scrum transformation a success—long before the transformation actually occurs.

Scrum Transitions: Do It Once, Do It Right, Part Two
Don’t fail before you start – avoiding common pitfalls prior to the pilot stage

By Katie Playfair, director of client services, Danube Technologies, Inc.

It’s all about buy-in

Teams that are successful at Scrum are usually teams that want to be successful at Scrum. If you’re a team member and your team wants to try Scrum, you have the right ingredients to start thinking about a pilot. How can a manager convince a team that Scrum is worth trying? More importantly, how can a manager motivate a team to want to be successful at Scrum? Building buy-in for Scrum at the development level is really about getting teams to embrace that Scrum will be better for them personally and professionally. Note the world “embrace” is not the same as “understand.” The goal of the buy-in phase is to get team members and, specifically, volunteers for your pilot team to become genuinely excited about Scrum. To accomplish that, consider the following:

Teams need to understand why what they’re doing now isn’t working.

First, ask the team what isn’t working for them. Examples include:

  • BA’s are overloaded at the beginning of the project, while developers and QA are bored. QA is overloaded at the end of the project, while other functional groups may be “done” with their contribution and unwilling to help.
  • Team members may be frustrated that requirements seem to change regularly and have a heavyweight change process, resulting in changes “jerking them around.”
  • As in the case of our Intel client case study, there may be unnecessary turnover at the end of a project because of burdensome deadlines falling on particular groups.
  • Work just isn’t fun anymore.
  • The team can’t release a product due to technical debt (when we change something, something else breaks).

Secondly, tell the team what isn’t working for the organization with regard to their product:

  • Development is too slow.
  • The team isn’t open to change due to current processes.
  • The project is constantly slipping deadlines.
  • Software quality has gone down – bug reports are way up.
  • Due to technical debt, the team can’t develop new features anymore.
  • Team member attrition has gone up and the cost of replacing good people is too high.

Team members need to have adequate information about this Scrum framework a manager would like them to try.

What the team needs to know:

  • Working in a Scrum environment is more fun than traditional project management.
  • In Scrum, the input of every team member matters and the organization will ask for your opinion, often on your area of technical expertise. Scrum helps create more equality between team members and each person’s input is considered equally important.
  • The Scrum framework helps ensure that the technical team is responsible for the technical quality of their output and that the business team is responsible for the quality of business decisions.
  • Engineering practices that go hand-in-hand with Scrum will help make late change cheaper and less painful.

How can you get them this information?

  • Distribute case studies from similar companies who have experienced success.
  • Invite an experienced Scrum coach or trainer on-site to share success stories.
  • Encourage developers to attend local agile, Scrum and XP user groups to discuss how their counterparts at other companies feel about it.
  • Invite them to read blogs, participate in online discussions, and generally research Scrum online.

Seek volunteers who agree that current processes could be improved and that Scrum might be worth trying.

  • Express support for doing things differently and ask for motivated folks who want to try it.
  • Demonstrate concern for the welfare of the team and their success.
  • Assure volunteers that they are safe to try and fail at first, while they learn this new way of working.

Does volunteerism work in the real world of Scrum transformations? Yes. Let’s take the case of a 35+ person development organization, divided into two basic categories, “technical leadership” and “everyone else.” “Everyone else” members were treated as lackeys, not allowed to make technical decisions or have any input into how to estimate difficulty of their tasks. Many of the “everyone else” team members were bright and capable, longing for more responsibility and independence. When a Scrum pilot was offered as an option, members of the “everyone else” team rushed to volunteer to be on the team.

Tags: ,


Guest Column: Scrum Transitions, Part 1 of 3

Posted by admin under Scrum Basics, Scrum Discussion, Scrum Transitions

Scrum Methodology’s Guest Column feature asks individuals throughout the Scrum community to address an issue that is a common obstacle for Scrum teams. In the inaugural column, entitled “Scrum Transitions: Do It Once, Do It Right,” Katie Playfair, director of client services at Danube Technologies, Inc., discusses how teams can work toward making a Scrum transformation a success—long before the transformation actually occurs.

Scrum Transitions: Do It Once, Do It Right, Part One
Don’t fail before you start – avoiding common pitfalls prior to the pilot stage

By Katie Playfair, director of client services, Danube Technologies, Inc.


The pressure to create more software of higher quality with fewer people isn’t new, but the global circumstances of the last several months have created greater urgency around cutting costs and doing more with less. Scrum is a framework designed to leverage small teams to deliver maximum business value and has become the answer for many organizations for reducing development costs and time to market, while still delivering a great product. As Scrum becomes a more visible and popular framework for managing enterprise development, managers and executives are naturally eager to implement it as soon as possible. In an interesting paradox, however, most successful enterprise Scrum transformations have been driven, at least initially, through strong bottom-up efforts that started at the developer level, gradually gained the acceptance of management, and, ultimately, scaled organically to large teams. So if managers today are drawn to Scrum, how can they leverage known best practices of bottom-up transitions to spark a transformation in their organizations?

Don’t start how you think you should…

If you are a manager eager to roll out Scrum across your organization, please hear out this argument. What you believe has worked for you in the past (in terms of rolling out new processes) will probably not work with Scrum. Here’s an anonymous proof point:

Case One – Online e-commerce portal:
Senior managers at this company decided Scrum was the key to restructuring teams and, therefore, developed a process roll-out plan based on previous process roll-outs. The plan involved training about 150 software team members and asking all of the teams to “kick-off” on the same day. The plan sounded very organized, but, critically, failed to consult anyone with actual enterprise Scrum implementation experience. Trainers were brought in for several sessions. What management discovered is that employees had not “bought into” changing the way they worked. Moreover, since more than 50 percent of the staff was comprised of contractors who felt the transition jeopardized their employment, more than half of the staff present for training refused to participate. Ultimately, after spending tens of thousands of dollars on training, only a few enthusiastic individuals embraced Scrum. It took approximately three years for these enthusiastic volunteers, working on a pilot project, to re-sell Scrum to the organization by demonstrating their success and the best practices they had developed as a small pilot team. This same outcome could have been achieved by spending only a few thousand dollars on sending those enthusiastic volunteers to training or conducting a small- to medium-sized training session for 10 to 30 people.

Almost every successful Scrum transition has started with an enthusiastic pilot team that wanted to try Scrum, demonstrated its capacity for success, documented their best practices, and, finally, asked their management to invite other teams to join. So if your plan for starting Scrum among your teams doesn’t look anything like that, it is almost certain that you will fail either entirely or by spending more time, money, blood, sweat, and tears than necessary.

Rather than spending time developing an enterprise roll-out plan, sending out RFPs to vendors for training and coaching services, and risking spending too much money, let’s talk about how managers can leverage best practices developed by successful Scrum teams around the world to facilitate lasting change that positively impacts the bottom line. On a side note, what you’re about to hear is going to be cheaper than these “big bang” strategies, too.

Tags: ,


A Scrum Users Group with a Twist

Posted by admin under Scrum Basics, Scrum Discussion

InfoQ just published a brief article on Scrum Club, a group of Los Angeles-based software professionals that operates like a mix of a user group and a philanthropic outreach organization. In short, the group—which was founded by devs who connected at Agile Open California 2008—strengthens the Scrum community by meeting regularly and discussing Scrum best practices. It extends its impact by offering its services to a hand-picked group of local non-profit organizations. You can read the full text and check out the group’s Fight Club-inspired video here:

While Scrum Club’s model of a users group expands the mission of most of the ones I’ve encountered, it’s a great reminder of the value of getting together with folks who speak the same language, face the same challenges, and can share strategies for overcoming similar obstacles. There are Scrum and agile user groups all over the country—in fact, they seem to be popping up more often than ever these days. A quick Google search should help you find one in your area.



Games Are for Teams

Posted by admin under Scrum Basics, Scrum Discussion

I’ve been hearing more and more about Certified Scrum Trainers (CSTs) who are using lessons from outside of software development to inspire their students. Most recently, I’d heard about a presentation given by Danube CST Michael James at last fall’s Stockholm Scrum Gathering, in which he shared some fascinating findings from high-performing teams in aviation, psychology, and jazz. Not long after, I ran across this article on the SD Times web site in which Jeff Feinman reports on how some trainers are using principles from other fields to help their students better understand Scrum. For example, one trainer mentioned in the story has attendees engage in exercises drawn from improvisational theater, another leads participants through a series of stretches.

So what’s the value of teaching teams about Scrum using these methods? For one thing, it draws participants out of their shells and gets them to start talking to one another. That might not sound like a big deal, but, given that software developers are often introverted personality types, it’s a big step toward getting a team to behave like one. In a bigger sense, it gives participants experience working outside of their comfort zones. This is good practice for team members at organizations that are about to transform through Scrum. Leaving familiar working behaviors behind for new, sometimes challenging processes is scary for a lot of team members. So a no-pressure or goofy team-building exercise can break that ice and show a team member that a break from the norm can be exhilarating—or even lead a team to accomplish what they never dreamed was possible.

How has your Scrum team helped members acclimate to new processes? Have those efforts worked? How did team members respond? Please share your experiences in the comments section.



Universal Impediments

Posted by admin under Scrum Basics

Over at Computerworld’s web site, I just read an interesting interview with Christophe Louvion, who has been serving as a ScrumMaster at online ad network Gorilla Nation for about a year. Louvion doesn’t get too deep into what it takes to transform an organization to Scrum, but his answers will likely remind you ScrumMasters who read this blog that the challenges you face are not limited to your organization. For example, he had to convince management to re-organize teams to be cross-functional, regrouping teams by “product and value streams”; he still has to persuade middle-managers to be “impediment-removers,” not taskmasters; and he still prefers developers with team-friendly soft skills over genius coding knowhow. If these sound like familiar scenarios (and I’m sure they do), at least you’re not alone… 🙂


Scrum Training Courses