« « Previous Post | Tell a Friend! | Share on Twitter | Next Post » »

Welcome back to a new week at www.implementingscrum.com.The topic for this week is regarding the use of software tools on a Scrum team.I am going to write about some of the commercial and open source tools that are available today. In addition, I will continue my public stance that these tools should not be used by a Scrum team — and give you evidence from real-world experiences about what I continue to take this hard-line stance.

Feel free to ignore me (as usual!). This is just my opinion. Like the rest of this site (smile).

[Full Disclosure ON]

I am not affiliated with any of the tool vendors mentioned in this blog entry. I have used some of the tools at various client sites and have worked with demos from some of the companies. I am not receiving any financial gain (or loss) from the companies mentioned. I know the main people at each of the companies and have spoken with them in the past about tool usage for agile and Scrum teams. They are nice people (smile).

[Full Disclosure OFF]

The “Software” Scrum tools out there include Version One (versionone.com), Rally Software (http://rallysoftwaredevelopment.com), Scrumworks Pro(http:/danube.com/scrumworks/pro) as commercial products.

There are more. And there are write-ups about the different tools (for example, “Fear and Loathing (http://weblogs.asp.net/bsimser/archive/2006/10/21/Scrum-Tools-Roundup.aspx or Dave Froslie – Microsoft Development on the Prairie http://blogs.msdn.com/dave_froslie/archive/2005/12/15/504251.aspx)

Open Source tools include XPlanner (http://xplanner.org/) and others that pop up on a regular basis (for instance, I heard about a new tool just last week called Project Dune (http://sourceforge.net/forum/forum.php?forum_id=671252).

There is always Microsoft Excel for the die-hard MS fans.

Microsoft Project is one tool I would not even consider using on a Scrum Team.

So, those are the “Software” tools that are available today.

Are there more?

Sure.

Will there be more in the future?

Of course. Geeks like to create tools. And marketing folks like to sell seats (licenses) for them.

“So Mike,” you may be asking me at this point, “Clearly the market has shown a need for these software tools, and people are buying them (or at least trying their demos!). You must be smoking something if you think software tools provide zero value to Scrum teams.”

First, I am not smoking anything. Or snorting. Or injecting. Or swallowing. Gulp.

The software tool mainly provides value to the software vendor. Remember, their goal is to sell “seats” or “follow-on” consulting services. Heh… remembering also that this statement comes from a consultant (who does not sell software tools).

And, wow, I work with teams that actually use these software tools; some clients even go as far as growing their own internal versions (so they can print cards nicely or bla bla bla).

Congratulations.

And what value does that bring to your team?

Think about this.

And then…

Here are some conversations I start hearing when software tools start getting involved / used on Scrum teams:

“Please make sure you update tool X so that we can report our burndown to [someone who is not even in the room].”

“Holy Shit. Our tool is down. What do we DO now?” [mad scramble ensues]

“I love this tool. It keeps me from having to be in the room all the time…..”

“I love this tool. I do not have to talk to anyone about what I am working on anymore. I can just enter my tasks and user stories in and just worry about the stuff I am working on.”

“Look at these cool graphs.”

“Wow. Our estimated time for a task was off my 37.5%, how do we ‘fix’ that delta so we don’t get dinged for giving bad estimates.”

“Oh, we do not have a bundown because our software tool admin is out of the country for a few weeks. And we do not show task cards or user stories anymore.”

And… I could continue for hours (really… and this makes me sad… barfy sad sigh).

I discourage the use of tools at any point in the project, but teams almost always want to use them . Geeks.

Are you seeing where this can have a reallllllllllly negative impact on the team and how the team works together?

The scary thing is, when teams get started using tools, it can be perceived as crack cocaine.

The first one is “free” (demo).

Then… The tool starts taking grip on the team. And starts growing to other teams within the organization.

Hmmm… now internal compliance people (at an enterprise level, these people say what applications “can” and “cannot” run on your machine) get wind of it.

Bad things start to happen.

So an internal software tool starts getting developed. This takes resources — or usually one poor schmoe who winds up doing it off the side-of-desk — away from the main goal of the team.

The compliance people may get involved again because hey, you are running some internal tool that is not supported by the enterprise and gulp, you are running it using a non-standard database (i.e. Microsoft Access etc.).

And then, and this is the really scary part, Chickens get this great idea that they can start comparing team velocities and setting up a control center or dashboard of some type to magically report what is happening in their kingdom. [Bad idea — here is why.

Throughout all of this, the comments I made above — REAL comments I have heard from teams using software tools — take place and start eroding the real purpose of why a team started using Scrum in the first place.

“So Mike,” you may be thinking. “What are the alternatives?”

My advice.

Keep it simple.

Really.

The alternatives include index cards, some markers, large post-it notes, and whiteboards.

I know, whiteboards can sometimes be harder to get than ordering new software for the team. Do not use that as an excuse to start using software tools.

And yes, whiteboards can get erased. It’s OK. Life goes on. And, since your team is actually using a whiteboard on a daily basis to discuss stuff, it may not be all that bad to refactor the board once in a while anyway (smile).

Remember the goal of setting up your team implementing Scrum?

Did you have one?

Was it to actually develop working software?

Think about it.

Delivering working software does not include “software tools” to get your there.

All the “stuff” I wrote about above regarding the use of “software tools” takes the team away from the primary goal.

I have actually seen teams burn more than 50% or their available velocity in trying to maintain a software tool.

Yikes.

50%???

Or more???

For WHAT????

Huh? Where the heck is the Product Owner in all of this?

Hopefully not the one saying, “I love this tool because I do not have to be in the room to answer questions anymore.” Unfortunately, I have heard this during a Sprint Review in the past.

Uggggggggggggggggg.

Just because you have a hammer does not mean it is the right tool for everyone. Or every team. Sometimes you can use a small screwdriver to finesse something together instead of whipping out THE big hammer and causing more collateral damage than good.

As software professionals, we should all carry a toolbox of things we can use. Sometimes, a “software tool” makes sense (hammer) while others it makes sense to use manual techniques.

And not lose site of your Sprint Goal.

Really.

Gotta run…

Please send comments, questions, criticisms, ideas, or whatever here.

You can also enter The Scrum Community to discuss this cartoon and other Scrum topics. Thank you!

« « Previous Post | Tell a Friend! | Next Post » »