Scrum Methodology

The Daily Scrum; It’s a Good Habit to Make

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

When you think of the word “habit” what do you think of? In the dictionary, there are several distinctly different meanings for “habit” such as:
1. A customary practice or use
2. An acquired behavior pattern regularly followed until it has become almost involuntary
3. An addiction, especially to narcotics
4. A dominant or regular disposition or tendency; prevailing character or quality

We tend to think of “good” habits or “bad” habits. When the behavior we are repeating results in positive circumstances, it is “good”. When it leads to negative results, addictions etc. it is “bad”.
The “daily scrum” is the heartbeat of scrum and is a “good habit”. Tamara Sulaiman, a Certified Scrum Trainer, in her blog post titled “Techniques for Improving Your Daily Scrum; when Your Daily Scrum isn’t Daily” says, “The daily scrum is one of the most valuable practices that any team can use.” The purpose of the daily scrum is to increase the team’s communication and focus by answering 3 questions, “What have I accomplished since the last meeting? What do I plan to do for the next meeting? What impediments are in my way? “ When teams don’t huddle daily, they risk losing the communication, focus and momentum of a team necessary to build the right product with the appropriate quality on time. Oftentimes, teams will have excuses for avoiding the daily scrum or stand up meetings. I’m sure you will be familiar with many of the excuses Tamara talks about. The daily scrum, however, makes teams more successful because it is the smallest, tightest feedback loop built into the Scrum framework. Think of it like brushing your teeth or exercising daily– it’s a good daily habit to make and will pay off in the long haul.

What is Scrum?

Posted by admin under Agile and Scrum, Scrum Basics

Chances are you’re reading this blog because you use Scrum or agile. But some of you may be here because you want to learn more about Scrum and agile—it’s something you’ve just heard about and now you need to find out what it’s all about. If that’s the case, Joshua Brown’s recent article on the basics of Scrum is a great place to start. It addresses the framework’s basic structure, roles, and rationale for departing from traditional management. It’s short, but it starts at ground zero and builds from there.

If you’re looking for additional materials to help you wrap your head around the basics of Scrum, I’d recommend taking a look at “What Is Scrum? The Five-minute Explanation for Folks Not Yet Practicing It” and “Scrum Mechanics: An Introduction to the Basic Scrum Engine” by Danube’s Katie Playfair. Last year, CST Michael James authored a Scrum Refcard for DZone, which is another great crash course for Scrum newbies. Download it here: http://refcardz.dzone.com/refcardz/scrum?oid=hom9677

Free Scrum Webinars

Posted by admin under Scrum Basics, Scrum Discussion, Uncategorized

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.

ScrumMaster as Impediment

Posted by admin under Agile and Scrum, Scrum Basics

One of the biggest reasons the Scrum framework works so well is through the role of the ScrumMaster, an individual whose time is dedicated to ensuring a team’s ability to deliver on its sprint promises remains unobstructed. The ScrumMaster achieves this in a number of ways, such as by reminding the team to adhere to the Scrum process and keeping the Product Owner informed about how development is going. But, above all, the ScrumMaster is charged with removing impediments that prevent a team from completing the work it has negotiated for a given sprint. This can literally be anything from replacing a broken PC to mediating a disagreement between two developers. If it’s keeping the team from moving forward, it’s the ScrumMaster’s job to eliminate the impediment.

But what about situations when the ScrumMaster is the impediment? As Vikas Hazrati of InfoQ observes, it’s a scenario faced by many Scrum and agile teams, especially offshore installations where cultural hierarchy and traditional communication strategies complicate the process even further. But, as many CSTs have countered, when the ScrumMaster is creating an additional impediment for the team, there’s likely a greater degree of dysfunction lurking elsewhere that is manifesting itself in the ScrumMaster role. Usually, it means that traditional, command-and-control management techniques are still dominating the organization, even if the outward effort is to become more agile or abide by the rules of Scrum. For instance, if the ScrumMaster is committing to work on behalf of the team, acting as a proxy for the Product Owner, or actively managing the team (instead of respecting the ScrumMaster role’s lack of authority), Scrum’s distribution of authority and responsibilities are being broken. And when that happens, Scrum’s potential to deliver value is undermined, as well.

Do you encounter ScrumMasters at your organization who seem to do the opposite of what their role demands? If so, what are the reasons you suspect these ScrumMasters are failing to remove impediments, etc.? Please share your thoughts in the comments section.

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.

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.

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.

What Happens at Scrum Training?

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

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-james

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.