Welcome to Scrum Island! Now go home.

I’ve noticed a curious insularity in discussions among Scrum experts. These discussions focus mainly on how to get a Scrum team to run as smoothly as possible. Less commonly, there are discussions about how to introduce Scrum into a company, which focus on the benefits of Scrum for efficiency of development.

In short, the talk is about the view from “Scrum Island,” where the Scrum team lives. Either the islanders are discussing how to make the island work better, or they are talking about how to get foreigners to fund the island. One could be excused for thinking that the islanders have no concern for those who live elsewhere. In fact, I’ve heard of (but not personally experienced) cases where Scrum teams are actively hostile to the notion that outsiders have any right to know what is happening on the island.

The insular view that the team should be protected by an “ocean” (a procedural firewall) that makes it a black box from the outside is understandable, but unfortunate. It is true that the team’s internal workings should be protected from meddling by outsiders, but outsiders have a real need to know what the team has done, is doing, and plans to do.

The Foreigners

The software development process, and the teams that make it happen, do not exist in a vacuum. They exist in the context of a business that has customers, and which contains important roles outside the engineering department. Many of these outsiders are stakeholders for the process. Either they provide inputs to the process, or they are impacted by the process. These stakeholders (“foreigners”) have legitimate reasons to know what is happening on Scrum Island.

Who are these Stakeholders, and what do they want?

  1. Customer Support personnel need to enter problem reports into the bug-tracking system, complete with some assessment of impact or priority. They also need to know when bugs are scheduled to be fixed, or have been fixed, in order to respond to questions from customers.
  2. Professional Services personnel are in a similar position to Customer Support. They interact with customer who have purchased a service offering, and who expect that their bug reports and feature requests will receive attention.
  3. Not only do Salespeople get requests for features from current or potential customers, but they also must communicate expectations about the schedule for feature development. As a result, they place a high priority on getting this information, because it has a direct impact on quarterly sales.
  4. Directors, Vice Presidents, and C-Level executives need to plan out business strategy that is aligned with development schedules, which means they need to know (and influence) development plans.

Bridging the Ocean

Bridging the space between the “Islanders” and the “Foreigners” requires three things: tools, procedures, and attitude. Of these, the last is the most important, because it enables the first two to work smoothly.

“We’re all in this together” goes a lot further towards success than “us versus them.” If the Scrum team and external stakeholders can work together easily, the result can be very good. However, if the Scrum team refuses to share information, or external stakeholders try to interfere with the current Sprint’s work, the results will be dismal.

As for tools, the classic “sticky notes on whiteboard” solution for displaying Sprint content and progress does not meet the needs of stakeholders well except in very small companies. When teams and stakeholders are no longer on the same floor, the visibility suffers; when they are in different buildings, it vanishes. A more effective approach is to use an agile project-management tool, which provides a “single source of truth” for requirements, schedule, and progress for everyone, including the teams and external stakeholders. Many such tools exist (e.g., Rally, VersionOne, ScrumWorks), and they can be very effective at providing the information stakeholders need. (As an added benefit to both side, the Scrum Master is freed from the need to write reports for stakeholders.)

“Procedures” refers to the practice of entering requirements and plans into the project-management tool, and keeping the status information current. As Scrum teams have to do these things anyway, in order to function, there is no additional cost to supplying the information to external stakeholders.

Moving to the Continent

We don’t really want Scrum Islands. They arise as accidents, or in response to perverse incentives. What we really want is to have everyone, on Scrum teams and not, working together smoothly. A Scrum process provides the opportunity for tremendous visibility into work done and planned, and this information is valuable throughout the company. Making the information available is not difficult, and brings real rewards to everyone involved with supporting, selling, planning, and building products.

So let’s say good-bye to Scrum Island, and move to the Land of Agile Business. We’ll all be happier.

Explore posts in the same categories: Uncategorized

8 Comments on “Welcome to Scrum Island! Now go home.”

  1. Juan Banda Says:

    Nice write up. I word of caution about planning and tracking tools, they are valuable when you have a distributed team but when all your team members are collocated, I don’t really see the need to over complicate things including extra tools.

    If you ask Ron Jeffries you’d get a more radical answer about these tools. Me, I’ve seen that an Scrum team can perfectly work without them if the team truly understands and practices Scrum and the Scrum Master does a real good job buffering the team from external noise.



    • I’ve been at a Bay Area virtual worlds company that used Scrumworks to track internal team progress, even though everyone was in the same area. As a manager, I found it enormously helpful to have all those records of previous sprints, retrospectives, etc., as did the team. With little scraps of paper and post-its, you’re either spending a lot of time transcribing stuff into electronic files, or in future months you’ll be pawing through zooms of dozens of hard-to-read photos of sprint planning boards.

      In addition, I very much agree with Kevin’s point that electronic tools increase visibility of activities to interested parties outside of the scrum team. In larger organizations, this can often be scrum teams who discover that their work is gated or related to other teams.

  2. Kevin Thompson Says:

    Juan, thanks for the comment. I think, though, that you may have missed a point I was trying to make, which is:

    The team is not the only groups whose needs matter.

    If the team doesn’t need an online tool for managing requirements, but other stakeholders in the company will benefit from the use of such a tool, then acquiring the tool may be the right thing to do even if the team would prefer otherwise.

  3. Mark Brennan Says:

    Great post.
    Some central peninsula companies still hire primadonnas, which is fine. But failing to spank them when they form elite enclaves, is not fine.

    • Kevin Thompson Says:

      Thanks! And I agree that we want to prevent isolated enclaves.

    • Mike Smith Says:

      “Spank”? That is one reason why some developers are so strongly inclined to isolation.

      I think building bridges does not involve spanking. Forming a cohesive organization includes mutual trust, respect, and some healthy friction to challenge priorities.

      Moreover, there’s something to be said about team gel and a sense of “this team is cool”. A well-gelled team is more productive, and that does not happen when they are whipped into submission by manager mommies and daddies.

      I think with the right mix of business-minded leaders on both sides, it is possible to encourage an enclave of achieving developers that yields to business requirements.

  4. Ryan Martens Says:

    Nice post and thread. I recently published an article at Dr.Dobbs on a social contract. (http://www.ddj.com/architect/220900441) I think that is the way to build this bridge. It is easy to “spank,” but you do not have to take responsibility for helping to create the issue. If you write a social contract that says what you will do for people who join the parade, you are taking responsibility. Now you just need to walk your talk:)

    Kevin – I assume you and Tobias get along well?


    • Kevin Thompson Says:

      Ryan – Thank you! I’ve never met Tobias, but we have some common beliefs. I’m with him on the awfulness of the “pigs and chickens” story, which I’ve always found revolting.

      We’re also on the same page regarding artifical boundaries. Tobias dislikes a hard separation between Product Owner and team. I agree. While I use the word “team” in the official Scrum sense, meaning the people who do the hands-on development and testing, Scrum projects that I organize have PO and team members working smoothly together.

      Tobias thinks the Scrum Master role isn’t always necessary. I half agree. I would say that the SM’s responsibilities need to be carried out, but there may be ways to do so that don’t involve a single dedicated SM per team. I do think teams need a “go to” person to be responsible for various nuts-and-bolts items, and problem solving for issues that would be a waste of time for the team to tackle. (I happen to think that good project managers are appropriate for this kind of thing…)

      I disagree with Tobias on some things (I like estimating tasks in hours, he doesn’t), but he always makes good points.

      Your Dr. Dobbs article is interesting. If I can paraphrase, you are essentially using a Scrum process to define and work through the tasks needed to put a Scrum development process in place. That’s an intriguing approach, and I’ll have to think about it the next time I’m in that situation.

      One thing that Scrum does is force painful issues to the surface quickly. In the beginning, this really hurts, and it can seem that the process is failing. In fact, it’s succeeding, and people learn that pain fixed now is better than more pain fixed later!

      In the same vein, I like how the social contract you describe goes right to the pain (fear) of each team member: Will I lose my job if I do this? This contract is forcing painful issues about the transition to agile develoment to the surface, much as a Scrum process forces painful issues about development to the surface. Kudos to both!

      In the project-management world, we are taught that the best way to change behavior is through leading, mentoring, encouraging, and rewarding people (positive incentives), not through punishment or “spanking” (negative incentives). This doesn’t mean that all PMs do these things well, but the ones who don’t, should know better.

      Good stuff. Thanks for writing!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: