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.


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


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.



Scrum with a Physical Taskboard

Posted by admin under Scrum Basics

Agile management practices, which include Scrum, were originally conceived for use in small, collocated teams. Ideally, a team’s size falls between five and 10 members, all of whom are located in the same place. With no obstructions to communication, that arrangement facilitates ongoing collaboration and optimizes the team’s productivity.

According to research, teams in such an environment prefer highly visible communication and coordination tools that reinforce collaboration. For example, physical task boards, dry erase boards, Post-It notes, index cards, and other “manual” devices are among the most effective ways to track projects for Scrum teams working in ideal conditions.

However, most complex development environments contain too many variables for small team, manual agile techniques to work effectively. As team members increase, the attributes that make manual agile so effective in small teams don’t hold up. In fact, they actually become impediments in large-scale installations. So how do team members uphold Scrum’s tenets of communication and collaboration when they’re spread across offices, buildings, or even continents? And how they replicate manual agile in this context? Facing the challenges of scaling teams usually requires an agile tooling solution. While there are several solutions available, including my own company’s product, ScrumWorks Pro, I will focus on the most common challenges to scaling manual agile.

Large Groups and Collocation
Collocation is essential for teams using manual agile. When everyone works in the same vicinity, posting requirements and updates to a physically visible location is a great solution. But once a project team grows in size beyond 10 or 20 members, it begins to lose its impact. In short, as the visibility of the posting decreases as a team member’s geographic distance increases. As the group grows larger and larger individual group members will become farther and farther from the single physically posted requirements backlog. In this case, some group members will be hindered by the lack of convenient access with requirements and prioritization decisions.

In scaled agile, individual teams could employ a taskboard, which would be a convenient information radiator for all team members. But others — such as related teams — would struggle to stay informed of the team’s progress and impediments, since the board is outside its members’ immediate proximity.

This is a problem that happens even when all group members are collocated on a single floor, within relatively close proximity to the backlog. Furthermore, this situation is amplified when team members are spread over several floors in a building or in different buildings altogether. Clearly, this problem does not go away when teams are distributed across countries, continents, and time zones.

Management of Data in Large Groups
One of the most common ways small agile teams store data, including stories and tasks, is with note cards. This marks another challenge of manual agile for large organizations. Regardless of the benefits of using note cards and sticky notes, it quickly becomes impractical when dealing with large projects.

Consider a project comprised of thousands of stories and ten times as many tasks. The task of sorting and organizing that many cards would be impossible. Suddenly, these cards would only be of value to those in possession of them, since creating and maintaining copies of thousands of cards only compounds the implausibility of the situation. Considering that cards are often revised, archiving would need to occur daily. In general, standard data organization functions are made difficult in large agile projects that use manual tools.

Visibility and Reporting Issues
Manual, paper-based tools work so well in small agile projects because they increase visibility and communication for everyone involved in the project. As mentioned before, however, using manual tools on large agile projects actually obscures data rather than make it more visible.

In such a scenario, reporting will struggle to keep up with real-time updates and may convey inaccuracies, thanks to the time-consuming process required to manually compile statistics. The backlog is a living, breathing artifact, with new cards being added, existing cards being altered, and obsolete cards being thrown away. For instance, a swing of 20 to 30 percent in total backlog effort from sprint to sprint is not unusual. For minimal summary statistics (net change), manually re-summing backlog effort is necessary each and every sprint. If more detailed change statistics are required, a manual change log of activities must be kept in tandem with the note cards.



Scrum Epics

Posted by admin under Scrum Basics

In Scrum, the teams that complete the work spend time refining the top items in the Product Backlog. To minimize work in progress, user stories shouldn’t consume more than one quarter of a Sprint. In most cases they can be made much smaller than that while still providing visible value to the customer.

What happens when a story includes too many unknowns to tell just how big it is? Or what if the story’s requirements are known, but its effort is too huge to complete in a single sprint? We call these stories “epics.” If an item require more than a quarter of a Sprint to complete, it’s probably an epic.

Estimating epics can be harmful because it creates a false sense of certainty. Instead, they should be split, as illustrated in this video.


Watch a team split epics during a Backlog Grooming Meeting.




Scrum Product Owner

Posted by admin under Scrum Basics

There are three roles in the Scrum method of agile software development: the Product Owner, the ScrumMaster, and the team.

In Scrum, the Product Owner is the one person ultimately responsible for the return on investment (ROI) of the product development effort. The Product Owner influences the development effort by conveying his vision to the team(s) and prioritizing the Product Backlog. The Product Owner must have the authority to make real business decisions, vision about what the product could be, and availability to the team(s). In bad implementations of Scrum, one of these elements is usually missing. For example, if I don’t have the authority to cancel product development entirely (an important ROI decision), it’s misleading to call me “Product Owner.”

This combination of authority and availability to the development team makes it hard for the Scrum Product Owner not to micro-manage. Since Scrum is team self-organization, the Product Owner must respect the team’s ability to create its own plan of action. A Product Owner doesn’t demand additional work in the middle of the sprint. The Scrum Product Owner is discouraged from adding work to the sprint until the next Sprint Planning Meeting. However, the Product Owner may cancel a Sprint when necessary. One Product Owner I know cancels Sprints once or twice per year tops.

It is the Product Owner’s responsibility to consider which activities will produce the most business value. This means making tough decisions about what not to do.

In Large Scale Scrum, one Product Owner prioritizes a single Product Backlog for multiple teams. Multiple backlogs for one product — and multiple Product Owners — cause localized optimizations (detracting from a whole product focus), longer work-in-progress queues, thus are harmful to agility. Large Scale Scrum encourages teams to become truly cross functional and take greater responsibility for their own requirements clarifications. Cross functional doesn’t mean only dev + test, it also includes learning the requirements domain.

The responsibilities of the Product Owner are also described about halfway through this video module:
Introduction To Scrum video

Tags: , , ,


Scrum Backlog Grooming

Posted by admin under Scrum Basics

While backlog refinement (also called grooming) was not originally a formal meeting in the Scrum framework, Ken Schwaber, who founded Scrum, advises teams to dedicate five percent of every sprint to this activity. As with Scrum’s other meetings, the grooming should take place at the same time and place and for the same duration each sprint.

Everyone attends the backlog refinement meeting: the team, the Product Owner, and the ScrumMaster. During the meeting, everyone helps prepare the Product Backlog for the sprint planning meeting. This usually includes adding new stories and epics, extracting stories from existing epics, and estimating effort for existing stories. Why is this helpful? Because a groomed backlog will help streamline sprint planning meetings; otherwise, they can stretch on for hours. When product backlog items contain clearly defined acceptance criteria and are estimated by the team members, the planning process does not have to be tense or overly long. By dedicating a time to backlog maintenance, the team ensures that this preliminary planning occurs prior to the sprint planning meeting.

Watch an example backlog grooming meeting.

Tags: , , ,


Scrum Meetings

Posted by admin under Scrum Basics

Sprint Planning Meeting

In Scrum, every iteration begins with a sprint planning meeting. At this meeting, the Product Owner and the team negotiate which stories a team will tackle that sprint. This meeting is a time-boxed conversation between the Product Owner and the team. It’s up to the Product Owner to decide which stories are of the highest priority to the release and which will generate the highest business value, but the team has the power to push back and voice concerns or impediments.

When the team agrees to tackle the work, the Product Owner adds the corresponding stories into the sprint backlog. We usually recommend this be physically represented by moving a Post-It note or index card with a story written on it from the backlog into the sprint backlog.

At this point, the Product Owner may choose to leave while the team decomposes the forecasted backlog items into tasks. This meeting is sometimes called Sprint Planning Part 2.

In Large Scale Scrum, multiple teams pull items from one Product Backlog. Multiple backlogs for one product, and multiple Product Owners lead to localize suboptimizations, longer work-in-progress queues, thus are harmful to agility.

Watch an example Sprint Planning Meeting.

The Daily Standup

Every day, the Scrum team gathers in front of their taskboard to discuss the progress made yesterday, goals for today, and any impediments blocking their path.

  • What have I done since the last Scrum meeting (yesterday)?
  • What will I do before the next Scrum meeting (tomorrow)?
  • What prevents me from performing my work as well as possible?

This meeting should not exceed 15 minutes. If members of the team need to discuss an issue that cannot be covered in that amount of time, we recommend they attend a sidebar meeting following the standup. This allows team members to attend meetings that directly involve their work, instead of sitting through irrelevant meetings. Unfortunately, daily Scrums often last longer than 15 minutes. To compensate, many teams use stop watches or timers to uphold the time limitations. Also, to limit distracting small talk, many teams employ a talking stick or mascot, which a team member must hold to speak in the meeting. Upon finishing an update, the talking stick is then passed to the next team member, who reports, and so on.” target=”_blank”>Watch an example Daily Scrum Meeting.


Sprint Review Meeting

When the sprint ends, it’s time for the team(s) to demonstrate a potentially shippable product increment to the Product Owner and other stakeholders. The Product Owner declares which items are truly done or not. Teams commonly discover that a story’s final touches often excise the most effort and time. Partially done work should not be called “done.”

This public demonstration replaces status meetings and reports, as those things do not aid transparency. Scrum emphasizes empirical observations such as working products.

In Large Scale Scrum, multiple teams demonstrate a single integrated product increment.

Watch an example Sprint Review Meeting

Sprint Retrospective Meeting

After the sprint review meeting, the team and the Scrum Master get together in private for the retrospective meeting. During this meeting, the team inspects and adapts their process. When the Scrum Master and outer organization create an environment of psychological safety, team members can speak frankly about what occurred during the Sprint and how they felt about it. After all team members thoroughly understand each other, they work to identify what they’d like to do differently the next Sprint, typically focusing only on one or two specific areas of improvement each Sprint. The Scrum Master may also observe common impediments that impact the team and then work to resolve them.

Overall Retrospective Meeting (Large Scale Scrum only)

In Large Scale Scrum, the Sprint Retrospective is followed by an overall retrospective that focuses on inter-team interactions and the outer organization.

Watch an example Sprint Retrospective Meeting.


Tags: , , , , , , , ,