As I promised at the close of our BoF: Scrum War Stories, I would write up a couple of the notes I made during our discussions. They aren’t in any specific order, and I only have some of the names of people who spoke written down Unfortunately those name tags at OSCON seemed to really want to flip around! If I ever host a conference, I am putting the names of people on both sides of the badge.
Before I begin I want to thank everybody who showed up! 14 people was a very healthy number of folks. Enough so that we can generate some real ideas, with people who were just learning about it up to people who are certified ScrumMasters and have been using it in the real world.
Mauro Talevi led off with a quick introduction on Scrum. One of the key points he made is that while processes like XP or RUP are “prescriptive”, Scrum is “adaptive”. XP says: “If you take my medicine faithfully and fully, then things will be better”, whereas Scrum says: “Lets honestly try some principles that are very common sense and see if we can change peoples behavior”. I really appreciated that distinction. Medicine versus Therapy.
He also pointed out that Scrum is a process for developers, but first and foremost is a method of communicating with the rest of the business. And that because it extends outside of the development team, what seems simple is actually incredibly hard to implement. And that lip service to Scrum processes doesn’t work.
We then chatted a lot about Jason’s situation where he has internal clients at a university. He wondered if you could use Scrum with internal clients. He wants to use it, has been championing it, and it hasn’t gone anywhere. After the group asked some more questions about his situation, in many ways Scrum was not a fit. In his situation, the business folks were not onboard with Scrum, and his attempts to gather requirements was failing. The advice was that:
- another job was better! A couple folks with university backgrounds had experience frustrations of the type that Jason was feeling.
- on a more constructive side, the group said he should just get enough requirements to start a prototype, and once the clients had something to look at, the rest of the requirements would become solid. Even if the original prototype was tossed out.
- Use interview process to elicit requirements. Someone mentioned a tool called DENIM (Denim?) for drawing simple GUIS for use in interviews. Another mention was made of using storyboard and tool that helps with that. Search Google for “XUL + Berlin”.
- Scrum doesn’t work without a team. If you are a developer of one then you can’t do Scrum. I showed how I organize my day to day life with a nice notebook that I scribble in. A notebook with “what I have to do” is not a stand up meeting!
The conversation drifted away from Scrum to requirements gathering for a while. The question came up, how do you take a 30 month project and figure out what you can do in 4 months of work. The answer seemed to be “ask the client, they know at some gut level what the minimum is”, or cancel the project completely, and solve the problem in a different, not IT way.
Aaron Farr then brought the topic back to Scrum as he said he thinks Scrum works even better with internal customers then external clients. A consulting firm with external clients has to justify every billable hours, so there is more of a framework and focus on managing scope and deliverables. Internal customers rarely are directly paying the developers, so they feel more leeway to change things around. This feeds directly back to the usefulness of Scrum. He also pointed out that you should let “Management be management”. They set the budget and tasking. You as a developer don’t. All you set is time.
The improvement in your team, as measured by your Velocity was brought up. Was it a factor of using Scrum? Was it just the team becoming better developers? Or is it that over time you become more familiar with your domain? Some suggestions was that the additional stability provided to your team by Scrum leads to better developers (less stress) and the interactive approach helps build knowledge of the domain.
A scary question was asked: “Can you lose your job?” Mauro replied yes, and explained that someone he knew in Scrum circles had “lost” their job because their job was to introduce Scrum, and while management had asked for Scrum, they were not willing to change their processes. Lip service was what they were looking for, and the ScrumMaster they brought in wanted to make actual behavior changes in how software development was handled. It was a sobering anecdote that ScrumMaster’s are often “Change Agents” which may ruffle a lot of feathers. And without management support, that can be a disaster.
“Slack” by Tom DeMarco was mentioned as a good book for people interested in Scrum. I hadn’t heard of it, but added it to my Amazon wish-list!
Lastly, we talked about tools. Tools, always a favorite for software developers! Someone brought up a web based wiki/spreadsheet, and after a bit of confusion we realized it was Dan Bricklin’s project. Dan and I gave presentations at a symposium once, and I learned a huge amount from him! I also mentioned “Rugby”, which is almost ready for public consumption. I’ll be posting more fully on it later, but it will be available from http://code.google.com/p/rugby/ . There is a Google Group where I will be posting more information.
I was very gratified at the turnout for my BoF, and am looking forward to hosting more at future conferences! If you have any questions, want to talk more about Scrum, please feel free to contact me at firstname.lastname@example.org . Thanks to everyone who showed up!