The Scrum methodology of agile software development marks a dramatic departure from waterfall management. In fact, Scrum and other agile processes were inspired by its shortcomings. The Scrum methodology emphasizes communication and collaboration, functioning software, and the flexibility to adapt to emerging business realities — all attributes that suffer in the rigidly ordered waterfall paradigm.

4th
JUN

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.

Tags: , , , ,

2nd
FEB

Can CSMs and PMPs Get Along?

Posted by admin under Scrum Discussion, Scrum Transitions

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!

Tags: ,

11th
DEC

Advice for Agile Adoption

Posted by admin under Agile and Scrum, Scrum Transitions

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.

Tags:

18th
NOV

Share Your Story

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

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.

Tags: ,

8th
OCT

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

Tags: ,

1st
JUL

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.

Tags: ,

25th
MAR

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

23rd
MAR

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

18th
MAR

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.

Introduction

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

Scrum Training Courses