Chapter 4. Sprint! Visible, Collaborative, and Meaningful Work

I once trained a large company that has an office near Nice, France. On a nice sunny day, in between training courses, I decided to take my rental Peugeot into the mountains over to the Cote d'Azur. While I was driving, I noticed this old medieval city across the canyon and I immediately thought, "I must go there!". So I navigated my way to Tourrettes-sur-Loup via a Hertz Neverlost GPS that spoke French (and because I don't parlez vous Français, I couldn't change the settings to English!). Nevertheless, I finally arrived at the medieval city, and walking along the old, crooked, narrow streets, I fell in love—feeling like I had stepped back in time. I found it interesting that for such a beautiful, quaint, quiet, and peaceful place full of artists, it had quite a turbulent history. The city, strongly fortified by plunging cliffs and stone buildings nested high atop a hill, provided a stellar vantage point highly desirable to various...

How the Scrum team should work

In The New New Product Development Game, Takeuchi and Nonaka described teams as autonomous, focused groups of people, who, when given goals that caused built-in instability had to self-organize around a new directive. In these cases, the manager did not do their jobs for them but rather stayed out of the way and provided everything the teams needed in order to be successful. This wasn't just a hypothetical model; rather, their article was a set of case studies about companies that were actually creating new products this way.

Jeff Sutherland describes the Scrum team as dedicated, cross-functional, self-organizing with a very high degree of autonomy and accountability. Sutherland's description of a Scrum team is similar to the generic definition of any team: a group of people with a complementary skillset and a common purpose. What makes Scrum teams different, then? There are three factors: Scrum team members are empowered to manage themselves, they are dedicated...

Working in a sprint

Right after sprint planning, team members begin to work on the tasks they identified in the planning meeting. Usually, programmers begin to write code and unit tests. Testers begin to write test cases. Ideally, they're writing both on the same set of assumptions based on the conversation with the product owner, some parts of which are captured in the acceptance criteria of the story (see Chapter 7, Scrum Values Expose Fear, Dysfunction, and Waste). Keep in mind, however, that sprints were designed with a different way of working in mind. In the original Scrum literature, Ken refers to team members as development team members, regardless of what's on their business cards. In other words, everyone is supposed to jump in, no matter what their expertise, and work hard to fulfill the goals of the sprint committed in sprint planning. That means developers could pick up testing tasks, testers could write user documentation or perhaps make a schema change, if that's the way the...

Estimating work

In Chapter 3, Sprint Planning – Fine-tune the Sprint Commitment, we discussed the traditional Scrum method of breaking PBIs into four to sixteen-hour tasks for the sprint. The reason behind this is that if a work task is small, the team member working on it will have something new to report every day, or at worst, every other day. This visibility into daily status allows for an entire team, then, to jump in and help each other when they can. If you visualize the Scrummage formation in rugby, you can see the similarities, except our Scrum team is huddled around product backlog items, not rugby footballs. Small estimates combined with a daily scrum meeting help the team move the sprint's PBIs together to completion.

When Scrum teams first start out, they focus on planning sprint tasks with lots of detail in order to ensure that they haven't overcommitted, as well as to generate their sprint burndown chart (Chapter 6). Due to the repetitive, sometimes boring nature of planning...

The misunderstood daily scrum meeting

Just as release plans are revisited throughout a release, sprint plans are revisited and adjusted throughout the sprint during the daily scrum meeting. This meeting, which should be 15 minutes (or less) every day, in the same place, at the same time, is commonly thought of as just a set of three questions that team members answer, going in turn around the circle: what did I do since yesterday's meeting, what will I do by tomorrow's meeting, and what obstacles are in my way?

Daily scrum meetings are meant to be so much more than this. The intent was to help a team synchronize its work tasks so that product backlog items would flow through the sprint as quickly as possible, and to provide visibility into the team's work for anyone who was interested. I'll admit, I've grown tired of these three questions. Maybe it's because I've been doing Scrum for so long, and it's repetitive. Or maybe it's because I've seen too many robotic Scrum team members answering...

Individual influences to the work of the sprint

It is important for ScrumMasters to understand personality and learning frameworks so that he/she may more readily recognize what's really going on when a team's members move from the "Forming" stage into the "Storming" stage. One such framework is called the Five Factor Model (FFM); basically, five dimensions that describe the human personality (refer to http://en.wikipedia.org/wiki/Big_Five_personality_traits for more information). These certainly come into play when a team's members get to know each other.

Factor 1 – Openness

How open-minded and curious are the people on your team? Do some want to explore different ways of designing or coding a feature, while others have already made up their minds about how to proceed? For the latter, are they set in their approach, not wanting to listen to the ideas of others? One example that readily comes to mind is the architect and the developer. The architect wants to figure it out all up front, think...

What's 'Norm'al for one team is not for another

Teams that move into a Norming phase establish game rules for behavior. They feel mutually accountable for the goals of the sprint because they have set the goals themselves. Game rules help the team keep its focus; norms are rules that the team follows and emerge from the team's history and experiences. You can imagine that a team's members are much more committed to the norms they've set for themselves rather than rules set for them by managers or others. It is imperative that a ScrumMaster is secure enough to create an environment in which team norms may emerge. And it's important to know that one team's norms will be very different than that of another's. One team I worked with had a rule that if a developer chose to pair with another developer on a user story, then the code did not have to go through a code review; the team found over time that pairing resulted in much better code quality as a result, allowing a formal code review bypass...

A corporate culture and its impact on teamwork

Think about your corporate culture: does it support collaboration and creativity, or is it focused on creating internal competition and/or obsessed with controlling everything. Collaborative workplaces are "open" and "sharing" and place high value on teamwork, participation, and consensus. Creative cultures encourage risk-taking and experimentation and initiative and freedom of the individual. In a control corporate culture, rules and processes govern behavior and management wants security and predictability. Competing organizations emphasize winning and competitive action (Bruce M. Tharp, http://www.haworth.com/en-us/knowledge/workplace-library/Documents/Four-Organizational-Culture-%20Types_6.pdf).

Think about your company's mind-set and the way that Scrum will fit—will it be like putting a square peg in a round hole? Your company's culture will have a direct impact on your team members and the way they work together, especially at first. A...

Summary

The ScrumMaster's responsibility is to do anything necessary to help the team find success. This means removing obstacles and protecting the team from outside interruptions. However, other obstacles present themselves while a team is working—surfacing as personality, cultural, or values conflicts or mismatches. "Sticking to your guns"—that is, upholding your responsibilities as a ScrumMaster—provides an opportunity for both your team and the surrounding organization to change. If you relent on your responsibilities, it's likely that the team and the organization will remain in status quo.

Recommended reading

• Adkins, Lyssa. Coaching Agile Teams: A Companion for ScrumMasters, Agile Coaches, and Project Managers in Transition (2010), Addison-Wesley

• Kanban, general at http://en.wikipedia.org/wiki/Kanban

• Scrum-ban write-up available at http://leansoftwareengineering.com/ksse/scrum-ban/

• Ladas, Corey. Essays on Kanban Systems for Lean Software Development (2009), Modus Cooperandi Press

• Scrum and XP from the trenches, Henrik Kniberg's free whitepaper available at http://wwwis.win.tue.nl/2R690/doc/ScrumAndXpFromTheTrenchesonline07-31.pdf

• Bruce Tuckman's model available at http://www.sandy-campbell.com/sc/KTC_Module_2_files/KTC%20Module%202%20%E2%80%93%20Tuckman%201965.pd