Comfortably Scrum: Certified Scrum Master Training Part 1

This week I attended a Certified Scrum Master course in Atlanta led by Jeff Sutherland and Joe Little. It was a great opportunity to hear best practices from the man himself. It was also great to be around a good group of people in different stages of adopting Scrum and we had some really great conversations.

Me with Jeff Sutherland in Atlanta.

For my first post on the training I wanted to describe how the course itself was run. One of the interesting approaches was that the training was run like a Scrum project. Each day Jeff populated our Sprint Task Board with subjects we would cover that day. Each hour he would move the cards on the board and update a burn down chart. All of the exercises were time boxed and he kept things going with Tibetan meditation bells to end a session.

Our course's sprint task board.

The course manual had quite a bit of content and we did not make it all the way through the book. Jeff skipped around quite a bit and his slide deck had updated content that was not in the book but was provided to us afterwards. A good bit of content came from Henrik Kniberg's Scrum and XP from the Trenches book which I reviewed in my last blog post.

Jeff had many anecdotes of adopting Scrum from his many years of experience that made the ideas behind it a bit more real. There was a lot less rhetoric than I had anticipated and he backed up all the ideas with hard numbers from a multitude of studies. These numbers are great fodder for conversations with management when trying to convince them to adopt Scrum.

There were also some very cool activities that really illustrated the contrasts between traditional practices and those prescribed with Scrum. There are many paradoxes in Scrum (and Agile/lean processes) that produce results that are contradictory of what most people would think. I plan to post more info on some of these activities soon.

All in all it was a great class where I not only had a good bit of what I have been doing for that past couple of years validated but learned many new things as well. I would strongly suggest that if your company plans to implement Scrum that everyone involved in software development attend a training course of this type. Jeff recounted studies that have shown Scrum teams starting without a Scrum Coach or the right training normally only see about a 35% benefit initially where teams that are trained and coached well see a 400% increase in productivity.

Thanks to Jeff and Joe for a great course!

Comfortably Scrum: Book Review for "Scrum and XP from the Trenches"

The book "Scrum and XP from the Tranches" by Henrik Kniberg was suggested reading for my Certified Scrum Master training course. You can download it for from from InfoQ and I highly suggest you do. It has been out for almost a year now so I am a little late coming across it and I really wish I had found it sooner. The book's format is great in that it is told totally from Henrik's point of view describing how his team adopted Scum (and some XP practices) at his company over one year. It does not have the same rhetoric as a few of the other popular Scrum books, but rather a basic outline of how they implemented the Scrum framework and the basic philosophy around each decision. He never claims that his process is the right way to do Scrum, but the one that worked best for his team. I found it realistic and pragmatic. It is a short read and goes very fast so with it being free you really can't go wrong with this one.

Conchango Scrum Template 2.2 & Sprint Task Board Updates

Conchango has released the 2.2 version of their Scrum Process Template for Team Foundation Server. This template is free and includes some great additions including a load of new reports, bug fixes from 2.1, and a web based report slide show. They have also provided a command line utility to upgrade your 2.1 template to 2.2. See the full details here.

They released the beta 3 version of their WPF Sprint Task Board application a few weeks ago which now supports the Scrum template 1.2 for TFS 2005 as well as 2.x on TFS 2008. It is going to be release by the end of this month and the pricing will be $90 per license for 10 copies or under. You can get discounts for larger volumes.

Huntsville User Group

Yesterday I drove down to Huntsville, AL to present to the local .NET user group. The meeting was hosted in a very nice auditorium on the Intergraph company campus. The majority of the attendees worked for Intergraph who has been recently adopting Scrum and evaluating using TFS for their management tool. I ended up delivering both the "Intro to Scrum" talk in an abbreviated form and then going right into my "Implementing Scrum using Team Foundation Server" presentation. The crowd was very engaged and there were some great conversations afterwards.

I want to thank the user group leaders (Sujata, Jim, Charlie, & Steve) for having me down.

Agile: Where is the Line in the Sand?

The more I read on agile practices the more I hear some fairly edgy ideas about requirements gathering, design, and architecture in the agile world. While I understand the concept of embracing change, there has to be a line in the sand somewhere of how your company performs its business and how you build software to enable that business. As I work with clients adopting Scrum I find different levels of the YAGNI (Your Ain't Gonna Need It) principle and the idea of building extensible software that gracefully accepts change. My struggle is that I need to find a happy medium with the majority of my clients. Martin Fowler's article "Is Design Dead?" makes an argument for something in between also, but he focuses more with contrasting against the more edgy concepts in XP. Unfortunately a large number of agile pundits have taken up the idea that design up front is a wasteful practice as is gathering any type of detailed requirements. These are not just the inexperienced newbies blogging from their soap boxes, but well respected and experienced thought leaders in our industry.

So is up front requirements gathering and design really dead?

I have never been a agile purist and I think that for my clients some hybrid is more prudent. In the past I have been on Scrum teams that designed on the fly and kept the YAGNI mantra. Sometimes this resulted in some patchwork architectures and some disjointed business themes in the application. While I do think it is a great idea to embrace change, a basic vision for both your business case and architecture/design of any software solution are needed to keep the smaller iterations on at least some common path. This vision should be able to change as well, but there are some fundamental things that most probably will ring true for the solution. Determining that line is a black art. Too little and you risk being all over the place in your deliverables. Too much and you start becoming too rigid and have lost the benefits of an agile approach.

So how do you know how much up front work to do?

If I had a textbook answer I would give it to you. And it would most likely be wrong. Every case is different. Each client's situation and environment is different. As a company's business evolves the line might have to move also. But I do think that forming a basic business case as the initial vision and some high level architecture and design is almost always warranted. Even Ken Schwaber, one of the originators of Scrum, advises to start as soon as you have enough backlog items to start a sprint. You do not need grand functional specifications and loads of UML diagrams. As is often quoted "The plan is useless, but the planning is essential." When determining if you need to detail a specific business case ask yourself how essential is it to our core business? Higher value requirements always get the most attention. As far as architecture/design, defining the basic components and their interactions at a high level should be enough to ensure your deliverables follow a cohesive path. When determining how extensible a given component should be, concentrate of the most probable changes rather than inventing all sorts of possible future scenarios.

So how can you gather requirements and perform up front design while still being agile?

If you are going to start a sprint with just enough product backlogs items then some of those product backlog items should be forming high level business cases and prototypes so that subsequent sprints will have the benefit of an uniform vision on both fronts. I also believe that you do need some level of documentation for these outside of just the backlogs. A wiki is a great place for them since by its very nature embraces change (and the good ones can provide history for those people who just cannot get over the idea of this type of change). To take that idea to the next step, Team Foundation server allows you to add links to web pages on backlog items so that you can tie the documentation to the user functionality and development tasks. If you want to go low-tech use flip charts and save all the paper. Post it on the walls of the room where the team is literally surrounded by the business and architectural vision.

Even if you are well into an agile project, you can always have the stakeholders redefine the vision if you feel you are straying too far because of only thinking about the next sprint. Change is inevitable, but your company's core business fundamentally changing in not very probable. And good design should elegantly accept change also. I do not think up front gathering of requirements or design is dead. I just think that in agile environments it has evolved and shed its more useless features.