A hot topic in the Scrum community of late has been whether the agile framework is compatible with traditional project management. Lately, an intellectual curiosity about the other has materialized in both camps. That is, after years of assuming they were on opposite sides of the fence, both groups are trying to determine what they can learn from each other.

If you’re a traditional project manager who wants to learn more about Scrum and how it could improve processes at your organization, then you should take a look at an article on Agile Journal called “An Agile PM Isn’t What You Think: Where Does Traditional Project Management Fit into an Agile Project with Scrum?” The article’s author, Jimi Fosdick, who is both a Certified Scrum Trainer and a Project Management Professional, lays out what’s at stake in Scrum and proceeds to illuminate how its minimal framework actually addresses the job functions of traditional management roles. If you’re thinking through these issues, then Fosdick’s article will be a valuable read!

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.

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.

One of the most common refrains in the agile and Scrum industry is that implementing those new processes is both hard and disruptive. By now, no one should be surprised to find out that there’s pain in changing—especially in situations in which groups of people are asked to dramatically revise the way they’ve always worked. But in an InfoQ story by Vikas Hazrati, Dave Nicolette reveals his experiences with Scrum and agile adoption, which suggest that a successful transformation is even harder than we all thought.

Many consider the creation of a single, functioning Scrum pilot team to be the big hump to get over during initial implementation. But according to Nicolette, that doesn’t necessarily mean an organization is out of the woods. As he explains, it’s not uncommon for a pilot team to be broken up to begin additional teams, which can often undermine the chemistry of the original team and fail to translate throughout the organization. In other scenarios, a pilot team may simply revert to old habits as soon as an on-site consultant leaves.

In Nicolette’s view, the two main reasons that pilots fail to stick at an organization are:

• “Local process optimization – The pilot teams were separate from rest of the organization. They were working in isolation from rest of the organization and as soon as the pilot was over that ripple in the ocean faded away. The changes were carried on too much at a local level to cause any amount of friction in rest of the organization.
• “Insensitivity to emotional factors – The consultants ignored the support of individuals and departments who would have been instrumental in the sustained success of the effort. As a result of this as soon as the consultants left, these support groups rallied together to get into the earlier way of working.”

That’s some good food for thought—and possibly a way to help your pilot team lead the entire organization toward a successful Scrum or agile adoption.

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.

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.

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.

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