Oxymoron: Enterprise Agile Project Management Software
Monday, August 18, 2008
My favorite agile software development topic of them all — tools. More specifically, agile project management tools. If you’re old school, you bust out some index cards, some butcher paper, some writing utensils, and you get to work. If you’re trying to use one of the simplest of agile project management software tools (that most are introduced to as part of their Scrum training), then you open up an Excel template. If you’re looking for something a bit more comprehensive or even just a little more automated, then you do a search on Google for “agile project management software”. You click around, see quite a few options, look at some screenshots, screencasts, and likely research mailing lists and blogs to see what people think of these tools.
At some point you’re likely tempted by some vendors making amazing promises. These vendors aren’t simply selling software project management tools; they’re selling you the keys to enterprise enlightenment. They show screen after screen packed full of nondescript icons, drop down menus, and incredibly detailed forms that make you wonder how you got by in the past without tracking all that information. They integrate with version control systems, integrated development environments, issue trackers, testing tools, portfolio management systems; some will even have integration with customer relation management systems. What more could you want? A lot more. Actually, a lot less. But, as the saying goes, “less is more.”
The inspiration for enterprise software?
The problem I see with a number of the agile project management software offerings available today is that they have lost sight of what it is to be agile, at least when it comes to managing their own products. It seems like these solutions are trying to be all things to all people. Featuritis has hit these products in the worst way. I think the UI designers of these products were forced to get their daily dose of inspiration through slide shows of Enterprise Resource Planning (ERP) software screen shots and other “enterprisey” offerings that cause many of their users to go home each night wondering why they can’t master the art of using the software to get their jobs done more efficiently.
Beyond the usability issues I see with this new breed of agile project management tools and the attempt to “be all things to all people”, I think these tools are missing the mark in an even bigger way. If you want to provide the ultimate agile project management software, then you might as well leap frog the old project management tools by looking at what the open source community is doing and using. The offerings by sites like java.net, Sourceforge, and many other open source project hosting sites are where these agile project management vendors likely need to turn their attention to. There is a reason tools like Trac, Redmine, and others are utilized by more and more open source projects to manage development of the software. These tools acknowledge the need to manage the software development process in a distributed environment where there can be many contributors and many users. 
The focus of these tools does not start with a project manager view of the world, but rather with a project contributor and user focus. This means that an issue tracker becomes the central nervous system. Version control is a first class citizen, not something you leave for third party integrations. Mailing lists, forums, and RSS/ATOM feeds are often key features in these open source software project management tools.
I will admit to being biased in this post. I am not a fan (in general) of most software that is aimed at the “enterprise.” I believe that many of the best practices in open source software development should be adopted by agile tool vendors looking to address the problems faced by those involved with software development projects. I’ve held off writing a post about agile project management tools for over a year now, but after recently re-evaluating the options out there I felt it was time to give my thoughts on the topic. It’s a way more popular topic than it should be in my opinion. It’s much easier to talk about the merits of one tool over another than it is to address the more difficult (and more critical) challenges involving changes required in human behaviours.
Topics: Agile | 3 Comments »
Mr. Gates, Mr. Ballmer…Thank You & Congrats on Vista!
Tuesday, August 12, 2008
There’s at least a couple of hours of my life I’ll never get back thanks to Microsoft Vista and everything that is wrong with the world of Windows. I was helping my father-in-law setup his new laptop (running the ever so awesome Microsoft Vista) and wireless router — remotely. I wouldn’t wish this kind of pain on Beelzebub.
"We knocked the ball out of the park with this one. Vista is gonna rock the world!"
While Vista is not solely to blame for my experience this evening, Microsoft as a whole takes a majority of the blame. They have created a user experience that is chock full of “Are you sure you really want to do this?”, “Blocked suspicious activity”, and every other pop-up message known to man. Some will point out that many of these messages and pop-up windows are not from Microsoft, but from stellar software like anti-virus, anti-malware, anti-everything Windows add-ons that come from the usual suspects: Symantec, McAfee, Micro Trends, etc. Well, guess who built this cestpool of an ecosystem now commonly referred to as Windows that requires such nonsense?
The only saving grace in this whole experience was using the Copilot service Joel Spolsky’s interns originally put together. While not the best software experience on the planet, it did work fairly well (albeit slow) and made a near impossible task (of remotely supporting a Windows Vista newbie) possible. Compared to the Vista experience, Copilot felt like a gift sent straight from heaven.
P.S. Note to the IT industry as a whole: When referring to WiFi security, can we be consistent in our use of the words: “key”, “password”, and “passphrase”? These words are often used interchangeably and confuse the life out of ordinary users as a result. Pick one and stick to it.
Topics: Microsoft | No Comments »
Death of a User Story
Thursday, August 7, 2008
In my last post I wrote about user stories and how it’s easy to write a user story and forget to include the value statement. Now that we’re all writing user stories with value statements, I thought it would be interesting to look at another phenomenon I’ve seen far too often when it comes to user stories - their death. Yes, all good things must come to an end, but the way too many user stories die is not fitting.
Let’s take the example user story from the last post, which was from the Apple iPhone product owner (who am I kidding, Steve Jobs):
As an iPhone 3G user I want to be able to make VoIP calls over the 3G network in addition to wi-fi so that I can save money by not using my crazy expensive voice minutes.
The team working this user story thinks they’ve got it during their backlog selection. They’re excited to put the screws to the carriers as they prepare to expand beyond AT&T and turn the cell phone industry on its head. The team does their task breakdown and they’re off and racing. Daily scrums are happening, team members are communicating, impediments are being raised, tasks are getting done, and all is good in iPhone VoIP call land. The sprint review rolls around and the team is ready to show off their solution. They demonstrate making VoIP calls on a 3G network. Only one little problem. The team mentions that in order to complete this story in time they decided it was best to use a VoIP service provider that would make the user experience far superior to any the team could develop in a reasonable amount of time. The VoIP service provider charges a monthly fee. On top of the monthly fee there are hidden charges around certain types of calls. The product owner does his own demonstration following this. He demonstrates how the iPhone 3G can be used in combat by chucking the sleek devices directly at the team members’ heads.
So what happened? The user story was viewed during backlog selection, placed in a sprint management tool, and forgotten about until the sprint review. The team understood what they were doing, or so they thought. They were focused on completing the tasks to get the user story done. The team lost track of the actual user story - out of sight, out of mind.
The trick is to make sure the user story doesn’t get lost throughout the sprint and die a quick (yet too often) painful death. I haven’t figured out how to do this. Posting the user stories up on boards/walls is one idea. Temporary tattoos (that last the length of a sprint) of each user story on every team member’s forearms is another. Wait, that’s it. Sorry, I’ve got to make some calls now. My temporary tattoo parlor is calling.
Topics: Agile | 2 Comments »
So That…
Saturday, July 12, 2008
One of the most overlooked parts of user stories is the content that follows those two little words, “so that.” I’ve found that we (those of us working on agile projects) tend to do a good job of writing user stories until it gets to those two little words. For example, let’s say the iPhone team has a backlog and one of the stories is:
As an iPhone 3G user I want to be able to make VoIP calls over the 3G network in addition to wi-fi.
Sounds pretty good in terms of a user story. It’s likely more an “epic”, but I won’t get into the size of user stories. Let’s start the conversation with the product owner and the team and estimate this story. Not so fast. Notice that we have no idea why the user would want to make voice over IP (VoIP) calls over the 3g network. I think the assumption is often made by whoever is writing the user stories that the team and others already understand the value of the story. That is not a safe assumption to make. Not only is it not a safe assumption to make but the focus of the team will turn to “how” to make the user story a reality. I think we’d all rather discuss the value of the user story before we start jumping into questions about how it might be implemented. But when the value isn’t present in the story it’s easy for everyone to overlook. Let’s see what that story might look like with the value statement added to it:
As an iPhone 3G user I want to be able to make VoIP calls over the 3G network in addition to wi-fi so that I can save money by not using my crazy expensive voice minutes.
Now we understand why the user wants this functionality. Before we could’ve assumed it was for any number of reasons. The cost savings is the driver for this story. The team and anyone else reading this user story can now better understand what the real drive for the desired functionality is.
I read a while back an InfoQ article about changing the format of user stories. The traditional format is what we’ve already used in the example above:
As a <type of user> I want <some functionality> so that <some benefit>.
The new format suggested by the Elizabeth Keogh, the author the InfoQ article points to as the one suggesting the new format, looks like this:
In order to <achieve some value>, as a <type of user>, I want <some functionality>.
I think the new format is worth considering in light of how many user stories lack value statements. T
he only thing holding me back from this new format is that it reads too much like Yoda speak. Yoda was always known for putting those awesome sentences together, like: “Named must your fear be before banish it you can.”
I think whether we change the format of user stories or simply use the existing format, the important thing to remember is to communicate the value driving the user story. As Yoda might say: Focus we must on business value lest we lose reason why user story exists.
Topics: Agile | 1 Comment »
Your Search is Over: The Definition of Done in 3 Easy Steps
Tuesday, July 1, 2008
Has your team struggled to define “done” for user stories? You are alone. Everyone has this one figured out. You must be new to this thing called agile software development. What’s that? You’ve been doing this agile thing for some time now? Wow, that has got to be depressing. I’m sorry to hear that you’re struggling with such a simple concept. Fortunately for you I’ve got the answer. Follow these three simple steps:
- Listen to this podcast with Scott Hanselman interviewing one of the founding fathers of Scrum, Ken Schwaber
- Sit down with the team, Product Owner, Scrum Master, and maybe even major stakeholders to define what success is for your project in a clear and simple manner
- Make a list of all the activities required to achieve the level of quality required by step 2 for a typical user story in the backlog
Easy, right? That’s fine. When you punch the picture of me on the screen I don’t feel a thing. I’m still smiling, see?
Topics: Agile | 1 Comment »