SQE Agile Dev 2009 ScrumBut Tutorial

What is a ScrumBut? As originally coined by Eric Gunnerson in 2006, he wrote:

• ScrumBut: the words of Scrum, the actions of waterfall.
• “We’re doing Scrum but…”
  • our sprints are 12 weeks long…
  • we do two normal sprints and one bugfix sprint…
  • we do all our planning up front…
  • we skip the daily meeting…
  • our managers decide what’s in each sprint…
  • we haven’t read the books yet…
  • our team has 30 people…

The original idea behind the workshop was to break into three groups, having each group come up with their most common ScrumButs. When we did our group introductions, we discovered that everyone had multiple ScrumButs. In true inspect-and-adapt fashion, we quickly realized that the original approach would not yield as much value as the one that was emerging, so we quickly documented the list the attendees generated.

We had quite a list to work through! We prioritized the work and divided each item into twenty-minute sprints and we were off. Here is a summary of each item.

Documentation in Agile

There is a common misnomer that “agile means no documentation” which could not be farther from the truth. In our findings, we discussed what the right documentation is and how to get there. Most importantly, people need to focus on not just documentation, but the right documentation at the right time. For more information on this, please see my Learning Scrum article on how to create a Definition of Done.

Big Design Up Front

The next item we discussed was big design up front. Several people were dealing with situations where architects were pushing down designs not early but late. As a result, the time and money invested in these designs was not fleshed out but they were often implemented due to the investment made. We discussed how much architecture is the right architecture and how to build and deliver working software at the end of every sprint with architecture emerging over time. We found the correct amount of architecture for our group to be planning two to four sprints out, with more attention focused on the near sprints and less on the far sprints.

Scrum Teams Working with Traditional Teams

This was a common problem in our group. We did not spend a lot of time on this but what we did discuss was how to build mock objects between our application or service and the other services that need to be integrated. We do this so we can have stability in our system while the other teams build their architecture and services. Scrum teams cannot wait until “everything is done” – the behavior of traditional teams – and we found this approach to work best.

Selling Scrum to Management

The biggest part of selling to management (and customers) is to help them realize that change is common in software projects and that it is nearly impossible to predict the future of time, scope and money. We walked through the building of the Stacey Uncertainty Matrix (below) on a way to help people understand the amount of change that is common in most projects. Scrum is ideal for projects that are complex and less so when they are simple (because we just know what to do!).

Sabotage

Participants had problems of sabotage on their projects, where people were knowingly or unknowingly derailing the project and the team. We discussed ways to deal with this and with rogue team members.

Relinquishing Control

This was a big one. There was a common thread with people where others had a hard time letting go, thinking they needed to control what people did, how they did it and (sometimes) when. This conversation on leadership lead to a discussion on what we can do to help make leaders in our companies, specifically on how we can deal with “the guy” who is always called on to save the day.

Offshoring and Distributed Teams

This topic was a bit short due to the time. The main topics we touched on were planning on a lot of travel, ways to build teams locally for three months and then transplant them to their new location, using technology like webcams and phones to help open communication channels, have a single-team mentality and ways to stay focused (e.g. the removal of IM and email).

In Closing

Thank you to the people that came to this workshop and made it a great success. Both Cory and I had a blast!