Contents tagged with Scrum
-
How do you know she’s a witch?
She looks like one! So begins one of my favourite skits in movie history, the witch scene from Monty Python and Holy Grail. The gist of it is: If she weighs the same as a duck then she’s made of wood and therefore… A witch! And what do we do with witches? We teach them Agile!
What do witch hunts have to do with software development? Plenty.
How do you know you’re really “doing Agile” or following Scrum practices in your project? How do you know if you’re doing the right thing or not? How do you know when it’s done? How do you measure success? Why is the sky blue?
All of these questions come up when things start going sideways in the Agile sense, and you fall into the Scrummerfall way of doing things. Practicing traditional Waterfall management techniques but calling it Scrum. Tasks are assigned to people rather than claimed by owners. Customers are non-existent and uncommitted. And the team really doesn’t know what they’re delivering or why, they just keep doing stuff to stay busy because the PM tells them to.
Brad Wilson describes Scrummerfall as the way to ensure failure at a much faster rate than you had with Waterfall alone. There are some clear signs you’re on a slippery slope and if you see them, you should grab hold of something (preferably a pair of coconuts) and find yourself a swallow (African or European – your choice).
Three key things that you can bank on in Scrum:
- The practice regularly delivers business value
- The team is frequently aligned with the business requirements
- The business drives the project based on their needs and values
There are other elements of Scrum here but I like to highlight these ones as they’re not bogged down in techno-babble terms that nobody understands.
Delivering Business Value in a Predictable Way
A sure sign of Scrummerfall is having a schedule that follows some mythical Gantt chart or Waterfall-ish schedule that’s about delivering “phases” or “stages” of the product. Waterfall PMs will plaster these on the wall, attach them in monthly reports, and bring them to sprint reviews to show the customer “how well we’re doing”. How well you’re doing in an Agile project is measured by the business value you deliver and that can only be determined by your customer, not IT. Regular sprints of fixed lengths creates that predictability that is often missing in Waterfall projects where milestones keep slipping because of uncertainty with features that were estimated and planned months previously. If your team demonstrates value-added features at the end of your sprint and the business is on board to move to the next one, then you’re doing something right. And you’ll be hopefully able to more accurately predict the level of effort next time around.
The Business Requirement Alignment Shuffle
Requirements and business users change their minds. Especially after seeing results. It’s human nature. How many times have you brought that “perfect” tapestry home only to have your wife say “No, now that I see it on our castle wall it’s just not right. I want a shrubbery”. System solutions are the same thing and that’s fine. After a sprint ends, the business has every right; nay the privilege; to say what’s in or out next sprint. And heck they may even introduce brand new features as they see the system take hold and start dreaming up new stuff. This is *not* scope creep. It’s manageable expectations that are agreed upon by everyone once they understand the depth of the requirement.The Scrummerfall bing-bong alarm will go off if you’re in your 3rd day of the sprint and the PM starts picking and choosing from “other items” in the product backlog, substituting them in because of impediments. Avoid this at all costs. Features are not interchangeable like Lego. Even stories with the same number of points doesn’t mean it’s the same size. In situations where you’re not using story points or any kind of measurement system of feature/story size you’re in Scrummerfall land and cannot, under any circumstances, play the shell game with yet-to-be-determined-features.
Business Driven
In Scrum, the business drives the project by prioritization and commitment in order to help the entire team achieve some business value (which down the road should equate to some ROI). In Scrummerfall, the business just says “you pick what you need to do, propeller-heads, we really don’t care and will do our thing, you do yours”. A customer who’s not committed to the process but demands the project succeeds is an impediment. I think the biggest success factors in any Agile project is a fluid customer involvement. If you’re not engaging your customer, for whatever reason, then correcting that is Step #1 to success. IT cannot make business decisions. I’ve been on projects where we did, against my advice but forced by the PM, and when the client finally crawled out of whatever rock they were under, they took one look at the assumptions we made and blew 2 weeks worth of a teams work out of the water. Again, the powers that be, who only read Scrummerfall monthly reports, will chalk this up to Agile failure and blame Scrum.
Engage the customer. They may not always be right, but, like any engagement, it’s a courtship and a democracy, not a dictatorship. There may need to be some hand holding at first and you might have to wade into the pool with them step by step, but it’s for the greater of the entire team and success of the project to do so. Or you could take the Scrummerfall approach and just push them off the cliff hoping they know how to swim (and maybe tossing them a life preserver if you’re really feeling generous).
Peter Schuh has a great article here on 7 simple steps to go Agile without going extreme. It’s more geared for the nerds and developers, but there’s a great tip in a section called “Identify and collaborate with your customer”. That’s what this is all about.
Know the Signs
Knowing is half the battle and if you sense you’re on the slippage towards Scrummerfall (or are already knee deep in it) it’s time to sink or swim. Step back and get everyone involved to help identify what’s not working. If need be, stop the project and regroup. It might be to get some level of understanding in the requirements (or even the problem that you’re trying to solve) or get resources on track or whatever. PMs and other manager-types around the world are saying “Warning, warning, danger Will Robinson. We can’t afford to stop this project”. Frankly, you can’t afford *not* to stop it for a few days or a week at most. The entire team won’t be running flat out during this time but when things get back on track, the team should be better off. Don’t let this technological terror manage you and keep driving down the road with nobody at the wheel just to satisfy some planned delivery date. While you can screw around for the next few months/years on the project (and hey, some firms have all the fun because of unlimited funds) there’s little value in just doing stuff to keep busy.
Adoption is a two way street and sometimes you’re going to face killer bunnies and sorcerers named Tim. It’s not pretty sometimes but Agile is about adaptability. Humans adapt well to their environment so should projects adapt well to theirs. If you’re setting out to change the world in one fell swoop, stop kidding yourself and be a little more pragmatic. If however you’re looking for a few small wins to move inches closer to an Agile approach to project delivery, it’s an attainable result given some realistic goals. Know your audience and your environment and play nice with the other kids.
Waterfall is still valid today. Document, design, test, are all still there in every project. Practicing Scrummers (is that a word?) just do it in a different sequence.
A bit of a side tangent. When I’m mentoring people on development, specifically refactoring, we do the refactoring manually and by the book. It’s painful in this day and age but it’s done for a reason, to help understand the meaning behind the refactoring and what each step of say an extract method is doing (and more importantly, why). After that, we can pull out the copy of ReSharper and accomplish the same refactorings with 1 or 2 keystrokes. I see Scrum the same way. Implement it by the book at least the first few times. Get into it, understand it and prove that it works. *Then* tweak it and massage it to better fit into your organization and how things may have been done in the past, perhaps grafting PMO processes, reports, and budget tracking into it.
I don’t believe for a second that any organization out there can say “We’re doing Scrum everyone, pack up your PMI certifications and get rid of those silly monthly reports, we’re *Agile* now!” and drop everything. Even after learning and practicing it, they come to an understanding of what works and what doesn’t. If the team is geographically divided (with some members in different time zones for example) it’s impractical to have 8:30 AM stand-ups every day with everyone. Adjust to what makes sense to everyone.
Agile is about adaptation and it can adjust itself quite well because it doesn’t follow strict rigorous policies that need to be approved by a committee and signed off by 15 heads of state before it can be followed. The Scrum approach is much like a morning brunch in a Dim Sum restaurant. You pick and choose what you like and ignore the chicken feet, no matter how appealing they may look like.
It’s about what works for the team and the team has to discover that with practice and experience. If you only implement one or two practices (say daily stand-ups and a product/sprint backlog) and they work for you not against you, then good for you! You’ve taken your first step. However it needs a fighting chance to start. Wedging Scrum (or any Agile practice) in where it doesn’t belong is a bad practice in anyone’s books and not the fault of the process but the person trying to force it in. Don’t blame Scrum for bad choices you make.
At the end of the day, whatever methodology, practice, or process you follow it needs to be backed by the new-but-old methodology, Common Sense. Agile is a powerful tool but not a religion. Scrum can be tailored for your needs, but you need to be able to identify those needs first before trying to apply any practice against them. Again, Common Sense reigns supreme here. There is no end-all methodology that will save any project from the depths of Hell. It’s the ability to identify, use, and adapt pieces of Agile that will help you to the end goal.
-
Scrum for Team System Tips
As I'm staring at my blank Team System setup waiting for the system to work again, I thought I would share a few Scrum for Team System tips with you. SFTS has done a pretty good job for us (much better than the stock templates Team System comes with) but it does have it's issues and problems (like the fact that PBIs are expressed in days and SBIs are expressed in hours, totally messes up with the Scrum concept and makes PMs try to calculate "hours per point"). I'm really digging Mingle though and will be blogging more on that as we're piloting it for a project right now and I'm considering setting up a public one for all of my projects (it's just way simpler than Rally, VersionOne or any other Agile story management tool on the planet, hands down).
So here's a few tips that I’ve picked up using Scrum for Team System that might be helpful to know (should you or any of your Agile force be put in this position):- When a sprint ends, all outstanding PBIs should be moved to the next sprint and the sprint marked as done.
- The amount of work done in the sprint (SBIs completed) gives you the capacity (velocity) for the team for the next sprint.
- Only allocate one sprints-worth of PBIs to a sprint when planning and try to estimate better based on previous sprint data.
- When the customer decides the product is good enough for shipping have a release sprint where the goal is to "mop up" bugs and polish the product ready for shipping. This would include new PBIs like:
- Fix outstanding bugs
- Create documentation
- Package/create MSIs
- Fix outstanding bugs
- Never attach new SBIs to previously closed PBIs. If the customer changes his mind about the way something is implemented, it is recorded as a new PBI because the requirement has changed.
Definitions:
PBI: Product Backlog Item, can be functional requirements, non-functional requirements, and issues. Comparable to a User Story, but might be higher level than that (like a Theme, depends on how you do Scrum)
SBI: Sprint Backlog Item, tasks to turn Product Backlog Items into working product functionality and support a Product Backlog requirement for the current Sprint.
- When a sprint ends, all outstanding PBIs should be moved to the next sprint and the sprint marked as done.
-
Scrum for SharePoint
Agile teams are all about co-location and communication. We have a wall where tasks are posted. The wall is life. It is the source of truth. From the wall, the ScrumMaster (me generally) enters in the hours remaining for tasks and updates some backend system (in our case, VSTS with the Scrum For Team System templates).
There are many tools out there to do Scrum, XP, etc. and keep track of your items. I think I did a round up of the tools out there but I missed one. SharePoint. Yup, my two favorite topics, SharePoint and Agile, come together.
A friend pointed me to an article on Redmond Developer News (a new feed I didn't even know about and one that looks pretty cool) by David Christiansen called Building a Virtual Bullpen with Microsoft SharePoint. Basically he walks you through creating a digital bullpen, complete with product backlogs and sprint backlogs all powered by SharePoint. And easy to do, with a few custom views and all standard web parts and controls.
I remember Scott Hanselmen mentioning that they used SharePoint for Scrum awhile back on an episode of Hanselminutes. He said it worked well for them. I've setup clients using standard out-of-the-box lists to track Product Backlog items and such. The only thing 2003 won't give you are burndown charts. With Excel Services, a little bit of magic, and MOSS 2007 behind the scenes this now becomes a simple reality.
Check out the article to get your virtual bullpen setup and drop me a line if you need a hand (or just want to share with the rest of the class).
-
A Scrum by any other name...
I'm not getting it. I'm seeing a lot of posts about "Feature Driven Development" (or FDD for short) but I'm just not getting it. All I see is Scrum with different terminology. I was reading the Igloo Boy's blog where he's off at DevTeach 2007 (man I'm so jealous, Montreal in the summer time with geeks) and he posted his review of a FDD session with Joel Semeniuk and I just don't see the bru-ha-ha about FDD.
Definition
FDD is defined as a process defined and proven to deliver frequent, tangible, working results repeatedly. In other words, what we try to achieve when using Scrum in software development.Characteristics
FDD characteristics include minimum overhead and disruption, Delivers frequent, tangible, working results, Emphasizes quality at each step, Highly iterative. Again, Scrum on all fronts.Features
FDD centers around working on features (Product Backlog Items in Scrum) which have a naming convention like:<action> the <result> <by|for|of|to> a/an <object>
Like user stories where:
As a/an <role> I would like to <action> so that <business benefit>
Feature Sets
FDD Feature Sets is a grouping of features that are combined in a business sense. In Scrum we've called those Themes.So am I way off base here or are we just putting lipstick on a pig? Are we just packaging up Scrum with a different name in order to sell it better? Wikipedia lists FDD as an iterative and incremental software development process and a member of the Agile methods for software delivery (which includes Scrum, XP, etc.).
There are differences here between Scrum and FDD, like reports being more detailed than a burndown chart (however for me, a burndown chart was more than enough information to know where we were and where we're headed). Practices include Domain Object Modelling (DDD?) and teams centered around Fetures, but again this is just (to me) just Scrum organized a certain way. I would hazard to say I already do FDD because to me it's all about the domain and business value.
Or maybe this is a more refined take on Scrum. Scrum with some more rigor around focusing on the goal? A rose by any other name... I must be missing something here.
-
Scrum Room = Fun Room!
I like to have fun at work. Whether it's just messing around (by changing developers desktops to pictures of the Simpsons) or just focusing on a task, I think software development should be a fun thing and thus, be conducted in a fun atmosphere. After all, if you're not having fun then what's the point?
A few months ago, we shifted things around and finally got a large enough room to setup our projects in what we call the Scrum Room (I like to call it the center of the universe, but that's a little egocentric as it doubles as my office). Unfortunately our environment isn't what I would prefer it to be (a large team room for all members to be co-located) but this isn't bad. A single "War Room" where we hold the daily scrums each morning for each project. I personally grind code, print out burndowns, and keep the ship steered in some direction (the direction changes all the time) here every day but besides holding daily scrums, the area is generally regarded as the "drop by and let's talk about [insert design pattern here]" room.
First off, we have the daily scrum rules posted on the wall for everyone to see and for us to refer to from time to time as people forget. As I mentioned last week, if anyone strays from the rules during the daily scrum, the Scrum Witch lets out a Wilhelm scream (and we don't want that to happen). This wall also holds the burn down charts (created from Team System) of each iteration. I forgot to snap a picture of the entire burndown wall but you can catch one of them here. I'll post later a more detailed breakdown of the burndowns from one project as we're in the 6th month and there's been a lot of great activity and challenges with that project.
Next is the start of daily scrum. This is a Japanese character a friend of mine got and I had to barter with to obtain (I traded a broken iMate Jas Jar for it). He's an alarm clock of sorts and when you press the button on his chest, music starts up and he tells you to wake up (in Japanese of course). Press the "snooze" button again and he tells you "thank you for waking up" (or something like that, my Japanese is non-existent) and the music stops. We would get into the habit of starting this guy up just to get everyone pumped for the day, although I haven't activated him for awhile now.
Now we come to "The Wall". This is a large (about 20ft wide) wall in my office that houses 3 projects and their tasks. Each project has a 8-10ft section of the wall and we print out the splash screen for each project to identify it (of course the splash screen is the first thing done for the project, screw the requirements, we need a cool logo!).
Under each project contains 3 sections with tasks. One for "Not Started", one for "In Progress", and one for "Done". The "In Progress" section is broken down with a small post-it showing 0% - 100% which is the completeness of the task. Under the "Not Started" section we break down tasks in an organized fashion so it's easier to find them when you're grabbing a task during your 5 minutes of fame at the morning scrum. Each team groups the tasks differently. One team has it defined by role (BA, QA, Dev, etc.), another has it defined by a feature, still another uses a line of business to collect tasks. Whatever works for each team is fine.
It's the usual routine for task boards (in our case the entire wall is the board). Tasks move from the "Not Started" area to 0% in the "In Progress" area. As team members work on tasks, they move across the wall to 100% then drop into the "Done" area. It really does give a quick overview of where things are at. It's the easiest way to describe and display progress and the entire state of the iteration for anyone looking at it. This is how much we have to do, this is how much we've done. Highly effective and easy to understand.
The banner at the top of the wall is labeled "The New Goodness" and was a phrase someone has mentioned awhile back (more than likely it was over a few shooters at the bar, but that's okay too). We liked it as it represented the new approach to software delivery (agile vs. waterfall) and seemed to reflect the atmosphere we wanted to take. Something new and something good. Sure the grammar is off but again, we're focused on fun here not English. The development manager also printed out a picture of a traditional rugby scrum so we felt it was appropriate for the wall (and some mornings it feels like this).
There's a section over my desk where we've got some fun and motivational type stuff. A printout of a cartoon that Hugh MacLeod created (I'm not cool enough like Scoble to have a hand signed lithograph) that is a bit of a motto when you're in my office. We have the Scrum cartoon about the chicken and pig wanting to open a restaurant, courtesy of Implementing Scrum. Finally, there's the fish. This will take a little explaining.
This fish is the award the team member gets for breaking the build. Originally we were thinking about bringing in a real (ala taxidermy) fish. The dev manager has 3 of these so we would pass out the fish and the team member who broke the build gets to display the fish on his desk all day. This wasn't quite practical (and we felt we would run out of fish and then what! Goats? Sheep? Cats?) so he hunted down a goofy picture of a kid holding a fish. If you break the build, he emails the fish to you and prints out a copy for you to pin up in your cube.
Today we discovered some people were actually collecting their fish so maybe we'll have a contest at the end of the project as to who gathered the most fish. The idea is to spice up your team with ideas and promote fun within the team even when they do something bad like breaking the build.
Well, that's the whirlwind tour of our Scrum Room. It doesn't have to be a stuffy board room or a boring task board, and if you're going to live in it every day (like I do) make it enjoyable!
The message here is to have fun with your projects. Don't get so stressed out. So what, you lost a resource or two. So what, the requirements changed a day before you were supposed to deliver that feature.
Breathe, relax, pick up, and carry on. It's just software.
-
Beware the Scrum Witch!
I'm always happy when I see the Internet spread goodness, or at least what I perceive to be goodness. Last week or so I talked about the Scrum Witch, a horrific little screamer that we introduced to our daily scrums as things were getting out of hand. If a team member strays from our standard routine, we unleash the Scrum Witch on them, screaming and howling for everyone in the office to hear.
The witch has been pretty successful as we're sticking closer to the routine and there's less gossip-talk during the scrum. Scrums end in under 10 minutes now (where they previously would linger for 15, 20 and even 30 minutes) and everyone is focused. I've only had to activate the Witch twice, and both times were with the same PM who charged off asking all kinds of questions (not even related to the current sprint!).
Mike Vizdos over at Implementing Scrum has a cartoon this week called Work Naked on dysfunctional things he sees at the daily scrum and yes, the Scrum Witch made an appearance (although it would have been awesome if she made it into the cartoon, ahh someday...)
The message here is simple. The daily scrum is your commitment to the team, not a report to the PM or Scrum Master on what you did. Be kind and respectful and the pain will last only a few minutes.
Watch later this week for more scrum fun as I have a few posts on the go right now.
-
Introducing... the Scrum Witch!
My co-worker came by today and dropped off something at my desk. He calls it the Scrum Witch. Here she is:
She's a crazy one alright (and loud). We've had some challenges getting everyone to follow the daily Scrums as side discussions start happening, water cooler gossip, etc. and 10 minute standups turn into 30 minute meetings. We're also all about fun and trying to enjoy our jobs.
So anyone who starts to stray from the Scrum rules (a watered down version from various places like here that we've printed out and put up in the Scrum Room), we unleash the "Scrum Witch" on them. A small button on her back lets out a screaming wail to let the speaker know we're off on a tangent and a reminder to get back to business.
We'll see how it goes over the next few weeks (or until the entire team gangs up on the Scrum Master and beats him to death with, in which case this might be my last post).
-
The "need" for Scrum Tools
I got an email from Mike Vizdos about a blog post he was writing up. Mike is the author of a blog called Implementing Scrum. It's a great blog where he posts a cartoon to describe a Scrum concept in a very acceptable way (see below for an example). It's an excellent communication mechanism. I find myself printing out Mike cartoons all the time and putting them up around my office (aka the Scrum room) to hit home the Scrum concepts to people.
Mike recently blogged about Scrum tools and mentioned my own Scrum Tools Roundup post (thanks Mike!). His post talks about the value (or lack of) Scrum tools and I partially agree with him. There are times I've said exactly "Please make sure you update tool X so that we can report our burndown to [someone who is not even in the room]."
I personally just print out the burndowns (we use the Conchango Scrum Plugin for VSTS) and put them on the wall along with a splash screen for the project and the post-it notes that represent the tasks (our task board). We still use VSTS for tracking, but the wall is the conversation piece. Each morning (currently 2 Scrums soon to be 3) we get together and do our daily standup with everyone sort of huddled around the "wall" (a giant 14 foot wall I have in my office that holds all the post-its). People talk about what they did and what they're working on, move stickies around, and all is well.
I agree with Mike in that if you're burning 50% of your time in a project on maintaining a tool, a backlog in a tool (VSTS, spreadsheet, or otherwise) then you're spending about 49% too much time. However as the Scrum Master I keep the tool up to date, the PM uses it (constantly) to report progress to a heavenly body, and I personally try to get the team to not get hit too much with any administrivia tasks. The most any team member should do is to a) change the state of a task to In Progress or Done and b) knock down the work remaining on tasks as they're doing them say from 8 hours to 4 (or 0).
That shouldn't take more than a few minutes a day before the daily standup. Really.
If you're donig more than for sure you're spending too much time and you should read Implementing Scrum on a more frequent basis (and maybe change how you work).
-
Scrum Tools Roundup
Working this weekend on some new SharePoint stuff which you’ll see in a few weeks but thought I would pull together a list of tools to help people with Scrum. These are tools that help you plan iterations, keep track of your updates, and generally make life easier for the ScrumMaster or those working on Scrum projects. Not to say a plain old whiteboard with post-it notes or Microsoft Excel won’t do the trick, but these tools take you a little bit farther and help you keep track of things holistically.
Some are open source, others are not so check them out if you’re looking for something extra to add to your Scrum process. Where noted, I’ve given some suggestions about using these tools where I’ve already taken a look at them for you, but please make up your own mind with your own eval if you’re serious about a product (especially one that costs $$$).
Scarab
Java server based artifact tracking system, highly customizable. Distributed under a BSD/Apache style license.Double Chocco Latte
Sounds more like a special at Starbucks but this is a package that provides basic project management capabilties, time tracking on tasks, call tracking, online document storage, statistical reports, and a lot more. PHP based, supports both Apache and IIS, MySQL or SQL Server (and others), web based client. Distributed under the GNU General Public License (GPL).VersionOne
This is a commercial product that provides program, project, and iteration management and fully embraces the Scrum process through requirements planning, release planning, and iteration planning and tracking. Trial version can be downloaded and run locally. Runs under ASP.NET and IIS with a SQL backend. I’ve given VersionOne a test-drive in the past and it’s complete and a good, solid product. The only thing is that it’s got a LOT of options so if you’re looking for something simple, this isn’t the tool.GNATS
GNATS is traditionally a bug tracking tool, but according to Jeff Sutherland it’s Scrum-ready (whatever that means). Licensed under the GNU General Public License (GPL).Select Scope Manager
A commercial web-based package that provides planning capabilties to all aspects of Scrum and XP projects. Evaluation version available to download from site. I’ve worked with some Select products in the past and they’re not bad, but not very customizable.XP Plan-it
This is a hosted solution so you only need download the client and retrieve data from their servers. Commercial package but doesn’t seem to be anywhere you can download anything or even see the product. I would stay away from this one.Iterate
This is an interesting tool and very simple in appearance. It basically provides an electronic version of story cards and does some tracking (like your velocity). It’s simple but maybe too simple and personally I felt the interface seemed like an old VB app that someone threw together. Still, I think it works.TWiki XP Tracker Plugin
Here’s a bit of a switch and not a stand-alone tool but a plugin for a wiki system (TWiki). It provides custom templates and helps you track information on XP projects. While not really Scrum related, it does let you track stories and releases so you might have to modify it in order to fully use it for Scrum (Scrum != XP). TWiki is released under the GPL and is Perl based (blech) so as long as you can run Perl you can run TWiki.XPCGI
This is an open source Perl based system built for Linux and Solaris running Apache 1.3 or higher. They claim it will work on other platforms, but YMMV.XPWeb
Another web based project that’s distributed under the GNU General Public License (GPL). Uses PHP and MySQL so running under Linux, Windows, or Mac should be fine. The demo doesn’t render under IE7 so I couldn’t check it out for you.XPlanner
Probably the grand-daddy of the open source projects of this type, XPlanner is distributed under the GNU Library or Lesser General Public License (LGPL) and free. Requires Apace Tomcat to run so expect to spend a little time setting this up on Windows (but it does run as I’ve done it). Lots of options, pretty stable, respects Scrum and XP and how they work, and very simple to use. Actively being worked on and many open source projects use it for their own planning (Hibernate, JUnit, Log4J, Struts, etc.) so updates are pretty frequent.ScrumWorks
A professional looking product that touts features to support all aspects of Scrum. Support single or multiple teams working on the same or different projects. Client based but has a Web Client as well for some members of the team (say your PO that doesn’t need to get down and dirty with Sprint Backlog Items). Requires a trial license but you can get a copy for free just by requesting it. Nice piece of software that is backed by support forums, a wiki, and an API for extending it’s capabilities.ProjectCards
An interesting project that offers the ability to cover all aspects of Scrum (and then some). Very customizable down to custom fields you can display and use in reports. Client/Server based but features a plug-in for Eclipse if you have it in your environment. Guest accounts are unlimited and free (so POs and non-core team members can just use it to view the status of a Sprint). Downloadable trial but the full version will set you back some Scrum bucks.TargetProcess
I really like this tool, but maybe because it’s .NET web-based. It’s simple to use and setup and cost-effective for teams. While it doesn’t feature as many screens as other products, what it does supports Scrum and Agile projects with simple inputs and direct reports and charts. Nothing fancy but then neither is Scrum. Free trial avaiable and demo available online and you can download a 1–user pack completely fully featured and free (but with no support) so it’s great if you’re doing little one-man projects and you just want something to keep track of your progress and work. Supports SQL Server and MySQL but requires IIS and ASP.NET so it’s Windows only.ExtremePlanner
Lots of features for this commercial package, but not a lot of customization available so you can’t completely tailor it to your process. Requires Windows, Linux, or MacOSX platforms to run on (with Java 1.4.2 or higher and Apache Tomcat 4.1 or higher) or you can let them host your projects for you (for a fee of course). Simple interface makes it easy to enter information and covers all the aspects of Scrum planning including test case tracking and typical burndown charts.Rally
Enteprise level hosted project solution. Tons of features and lots of customization available (even for an online hosted system). Met these guys in Calgary during Agile World a couple of years ago and back then the product was impressive, so I can only imagine what they’ve improved on. Free demo online to check out and setup a project to see if it works for you.Scrum for Team System
Saving my personal fav til last. We’re using this on a few projects now and it rocks. An add-in guidance package for Microsoft Team System, it fully covers Scrum and lets you get work done fast. No customizable available but it works without it. Co-developed with Ken Schwaber so it reflects how Scrum needs to be done. Let’s users create their own views but comes with a dozen or so that are quite sufficient. Supports single team or multiple team projects and is currently being updated to version 2.0 where it’ll have more flexibility. If you have Team System in place and are struggling with the MSF for Agile package then take a look at this, you won’t be disappointed.Bottom Line
If you’re a one-man shop, I suggest you check out TargetProcess as it can be setup in a few minutes on a server or your own development desktop. If you already have Team System in-place, take a look at Scrum for Team System. If you have nothing but could run say Tomcat, then XPlanner might be the way to go as it’s simple but works well. Give a couple a test drive and see what’s best for you. -
Getting started with Scrum
Mike Cohn over at Mountain Goat Software has been in the Agile software development river since 1993. He's the author of the most excellent book Agile Estimating and Planning and really knows his stuff.
For those wanting to greenfield Scrum at your organization, he's got an excellent powerpoint slide deck to start from. It talks about what Scrum is and highlights the key things that you can use to show benefit to management. Mike encourages people to download the presentation and run with it, making adjustments as you need to adapt it your environment. The killer thing about this is the presentation is available under the Creative Commons Attribution 2.5 License. This is excellent for the Scrum community as we can go off a base from a respected source. I encourage everyone to join the bandwagon and help promote this by making it work for you. Scrum isn't a silver bullet, but it just plain works. You can grab the slide deck from here. Also available is a French version generously translated by Claude Aubry.
To add some icing on the cake, there's some great pictures of the Scrum process that Mike has made available of the process itself which really sums it up. These are great for decks or just print them out as a poster to hang in your team area to let everyone know the simplicity of the process. You can check out the picture files, also released under the CC license, here.
Watch for the Scrum tatoos coming soon to a blog near you.