Thursday, September 16, 2010

Scrum Master: Tools of the Trade

(or "How Rally Could Improve Their Software")



When a team is employing Scrum to project manage their software development efforts one facet for consideration is how to keep tabs on things: the backlog, the stories and associated acceptance criteria, the current state of affairs and so on.

The things one uses to do this are the “tools of the trade” for a Scrum Master, indeed for the whole team.

Much advice is given about keeping this simple. Much advice is given about the idea of visual management techniques including “information radiators” that constantly, clearly and loudly proclaim the state of affairs. These should be intuitive to read, easy to work with and not intrusive.

The quintessential approach to this is the use of a team area with a task board of some kind along with perhaps a burn down chart. We've done this at my company in our early days of agile adoption and it worked extremely well. The main benefits I saw were:
  • You can take in the state of an iteration in a glance. For instance, got most of your Post-its on the left and it's near the end of the sprint? Looks like trouble...
  • You don't really have to train anybody how to use it, it's dead simple
  • People not intimately involved in the project day-to-day (read: management and executive sponsor types) can quickly "read" it and get value from it
  • It's quick and easy to work with...adding a story, task, note, changing status...
  • It's always present, you don't have to "go" to a website, tool or what have you
Of course, it works best when you have a fully co-located team. When there are team members that can't visit the task board in person then this approach weakens considerably. This is one reason why a team may turn to a tool to aid them in creating a virtual task board. Part of me feels that this is treating the symptoms rather than the root cause...that is, you should look again at whether you really need to have a team spread out over different offices. However, I also recognize that that optimal arrangement isn't always practical, whether for financial or political or other reasons within an organization. Sometimes your talent is spread across the world and you can't bring it together. Anyway, I digress...

The other seemingly valid reason for a tool to replace the simple white board and Post-its I consider to be related to managing a group of teams or a portfolio of products. There will be very legitimate needs to roll up the status associated with individual software development teams to obtain a higher level view of the work of an engineering department. If teams are in different offices or countries, it's clearly impossible to run from one team room to another to update oneself on how all the teams and products are doing.

So clearly there are at least a couple of reasons why you may reach a point where you need a tool to help your agile teams coordinate and track their efforts.

My company reached this point. We chose Rally.

Here's a quote I happened across on the Rally Products Overview web page (it doesn't always show up, seems they cycle through various quotes) -- “The usability of Rally is one of its main selling points.”

Now I'm sorry, I don't mean to offend either the man being quoted or the people who've worked hard at Rally building this software. But it's far from a shining example of highly usable software.

It's my assertion that information radiators like a task board that a co-located team would use are basically the Gold Standard.

So, if you’re going to try and create some software that can be used in place of this then you should try damn hard to get as close as possible to that Gold Standard. I know there are other issues like concurrency, responsiveness, reporting, user management and so forth. But at the heart of a bit of software like this, it is my belief at least, should be a tool that empowers a team, not a tool that is awkward to use and gets in the way.

So what's my beef with Rally usability? Well, having thought on it a bit I believe my criticism falls into three main areas.

1. The Software is not Task-Centric

And when I say this, I'm not talking about the tasks one can break stories down into. I'm talking about the fact that different roles on a Scrum team regularly and repeatedly engage in certain tasks but that there are no options in Rally that particularly support or enable these. Instead it feels an awful lot like a small set of database tables with some views layered on top and then exposed as HTML. Various ways to slice, dice, subset and drill down my releases, iterations, stories and so forth is fine, but I'm looking for something more.
  • I want a tool that supports the Product Owner in release planning.
  • I want a tool that supports the Scrum Master in sprint planning.
  • I want a tool that supports the team on daily stand ups.
  • I want a tool that supports the team during sprint reviews.
  • I want a tool that supports the team during retrospectives.
Rally does of course contain various list views and so forth that help with this, but it seems to me that none of them are really conceived to aid any of these roles in any of these tasks. It's more a small set of Lego bricks you can arrange as you see fit to achieve your ends. And yet it would be so much more useful it the "bricks" were assembled into larger constructs that supported the various Scrum ceremonies and tasks that people on the team perform.

2. The Software Looks, um, Less Attractive than I Would Like.

I know people have worked hard on this, and I don't mean to completely disparage their efforts. I'm not even saying I could necessarily do much better (although I'd like to think I could...) but consider:
  • In general, there's a "designed by an intern programmer circa 1996" feel to things
  • The Dashboard looks like Jetspeed 1 That's not a good look for anybody.
  • In general, screen/form layouts are pretty unattractive and hard to scan: content is not well bounded, poor typography, colors, etc. Take the basic detail view of a user story, or the pop-up edit a story view…labels not emboldened, field boundaries unclear, it just looks like my 12 year old designed it after reading "HTML in 24 hours".
  • Look at the new Reports --> Epic Progress app that was just released. Was somebody really happy with how that looks? If I was Product Owner I surely would not be.
  • Why does editing a story have to spawn another browser window? Why not in-place? Rally allows a certain amount of in-place editing in list views so why not the full form? Nobody wants extra browser windows hanging around…
  • Speaking of in-place editing, there's a disconcerting "twitch" or "jump" when on the Plan --> User Stories view and you in-place edit something.
  • The tabs don’t stand out enough so it’s hard to “read” where you are, especially since so many “views” look so similar. There's not enough contrast with almost everything being in very drab black/white/blue. Use some more of the Rally Red maybe. Also I find the tabs are not very responsive, they “lag” as you move over them.
  • Why is the icon you can click and drag to reorder things different between Plan --> Backlog and Plan --> User Stories?
There's more, but that's a good representative selection of the things that strike me as looking unattractive.

3. It's Just Not Intuitive

I know agile and Scrum pretty well. The software then ought to be fairly intuitive to work my around. And yet it isn't...
  • It's Confusing how the backlog tab only shows things that *haven’t* been assigned to a sprint and/or release (can’t even remember which, but stuff disappears from here)
  • It's confusing how story hierarchies are shown in Plan --> User Stories but not Plan --> Backlog…in fact the whole parent/child thing is confusing. Why not have first class support for the common theme --> epic --> story structure?
  • Plan --> Releases gets its own tab just for defining a simple release "record"? Navigation from here to see “stuff” slated for a particular release is non-obvious. Could be much nicer.
  • “Page Tools” vs. “Actions…look different, kinda confusing…
  • Column headings etc. look lost...it's just not clear that they are column headings.
  • Plan --> Plan … really? What does that mean?
  • Track --> too many options. None seemingly optimized for daily stand-ups which is the #1 tracking activity in Scrum.
  • The "Task Board" doesn't work unless your stories have been broken down into tasks. OK, maybe that's why you call it a task board, but not everybody sees value in further decomposing stories. I don't, rendering the task board useless. Even if I did want to break stories down into tasks the view doesn't lend itself well to, say, sharing via WebEx for a stand-up with a distributed team.
  • The URLs are useless: I can't copy/paste a URL and IM it to a colleague. No matter what I'm doing the URL is always https://rally1.rallydev.com/slm/rally.sp
OK roasting more or less over. Given that the product is a tool for use by agile teams and that it's developed using agile principles and practices, I'm not convinced it's an especially good "advert" for agile. I'd like to think that if Rally were being truly effective here then there would be a much nicer product as a result.

This is of course all just my own personal opinion, and I freely admit I have not worked with the product for that long. Maybe I'll grow to love it and think it the best thing since sliced bread. Presently however I do not. I think there's a lot of things that could be done to improve above and beyond adding things like the Epic Progress app (do we really need yet another view of progress?). I suspect this scathing rant bars me from applying for the Product Owner job in Boulder ;-) but if I did have that job, these are the things *I'd* be prioritizing high on my backlog. I note they are also looking to hire a Usability Analyst which has to help, although they're only looking for someone with 2+ years experience and I wonder if they don't perhaps need someone a tad more seasoned...


Monday, September 13, 2010

Scrum, Crop Rotation and the Fallow Field

Since the dawn of agriculture (well, maybe…certainly some when in the last 10,000 years) farmers have realized that growing the same crop in the same field, year in, year out depletes the nutrients in the soil. Eventually this leads to the field failing to produce as well as it used to, or even becoming unusable.

One might see a parallel here with scrum teams: although the rhythm of short release cycles, time-boxed sprint planning meetings, daily scrums, sprint reviews and retrospectives provide a stability, might they not also eventually lead to burn out and reduced productivity? I venture to say that they might.

So can agricultural techniques offer any further parallels that might inspire us with ideas for how to help keep a scrum team producing? Well, with the employment of a little imaginative (some might say dubious) metaphor, I believe they can.

First, consider the idea of leaving a field fallow: the idea here in farming terms is that one might operate a three field system, with only two fields at a time being planted. The third will be left empty, or fallow so that it might recover. Things shuffle around so that each season a different field is left fallow.

So what would it mean to leave a scrum team fallow? Simple. After a successful release, have a sprint with no formally planned activities. Sound wasteful? Consider that this would allow for the team to celebrate the release, decompress from the work and general renew their energy levels. In addition there could be some planning activities or less rigidly time-boxed investigatory work in anticipation of the next release cycle.

But there’s more. According to Wikipedia, the Romans and several civilizations in Asia and Africa used more sophisticated crop rotation methods to keep their fields productive without having to leave them fallow so often. In these schemes, by carefully selecting the right crops they were able to restore the nutrients depleted in one season with soil enriching crops subsequently.

I think the parallel for a scrum team is the idea of working on something different to the main product they are responsible for during a release cycle. This might be helping out with a different product, pursuing the development of some tool or infrastructure they think would help the team in future, training or other creative ideas.

As a child I can remember my grandmother offering up many pieces of advice, including the notion that "a change is as good as a rest." Personally, I’ll take a rest over a change any day, but in truth both work. And there’s no reason not to employ both as productive investments in the overall health of a scrum team between release cycles.