Agile
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 | 3 Comments »
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 »
Distributed Agile Teams Don’t Work
Thursday, May 1, 2008
The title of this post is misleading. I think distributed agile teams do work, but only if everyone is remote. I’ve come to the conclusion that what doesn’t work are what I call “semi-distributed” teams. Semi-distributed teams are those where some people are co-located and others are not. I’ve seen all sorts of arrangements over the years. Everyone collocated but one person (experiencing that one currently – me being the odd man out), some collocated in one office and some in another, a few people distributed remotely and others collocated, on and on it goes.
The reason I argue that fully distributed agile teams work is because everyone is in the same boat. Everyone is disconnected and therefore looking for solutions to the problem of connecting with one another. With semi-distributed teams you have some people who are desperate to be a part of the conversation, while others are often quite content with their little collocated circle. I think this fact is often overlooked when people point to Open Source Software (OSS) development working in a distributed fashion and equate that to proof that semi-distributed projects can work just as well. One of the reasons OSS development works is because everyone is (typically) working remotely. The ease of looking across your desk and striking up a conversation with one of your team members is not an option with most OSS projects. Everyone on the OSS project needs to put forth an extra level of effort to strike up a conversation, even if it’s just chatting in IRC, sending an email, or doing a screen share session.
A majority of agile proponents will argue that collocation is a requirement for highly successful agile projects and I agree. The level of discipline required to make distributed agile projects work cannot be understated. But, you can be successful with distributed agile projects. What you cannot be overly successful with are semi-distributed agile projects. The level of effort to make semi-distributed agile projects work is too great for most of us mere mortals to overcome. I’m sure there are those that will point to their success stories of semi-distributed agile projects, but I will argue those are the rare exceptions rather than the general rule.
Some may read this post and have a moment of truth smack them right in the face, “Wait a second, I’m on a semi-distributed agile team!” What do you do in that case? My suggestion is that you figure out a way to make the team collocated. There are many creative ways to make this happen. For example, the team that I’m currently on and am the lone remote person on the team (Scrum Master, nonetheless!),is going to get a local replacement. If you can’t go collocated, then a radical idea might be to go completely distributed. Have everyone work from home and force themselves to deal with being remote. It’s amazing how well teams can stay connected these days when they’re all working from a different location. In other cases, it might be possible to create one team that is collocated and another that is truly distributed. Team to team communication is often tricky, collocated or not. At least with a collocated team and a distributed team you’ve eliminated the avoidable problems of a semi-distributed team. The problems you’ll deal with in this case are the same problems anyone scaling agile is faced with. It’s not an impossible mountain to climb.
If you’re still stuck on a semi-distributed team after trying some of the suggestions mentioned above then I wish you luck. The best advice I can give is to enforce use of constant connectivity through technology like video conferencing. People will likely object to this due to a sense of loss of privacy (understandably so), but it gives you a fighting chance of keeping everyone in the loop. Cool apps like MeBeam provide the ability to have more than two participants on a video conference. You’ll also want to investigate technologies that allow you to share whiteboards. I don’t have personal experience with these but I’ve seen them in a variety of places, especially schools. I can see electronic whiteboards helping where collocated members step up to a whiteboard on a whim and start jotting down some new design, architecture, notes, etc. These whiteboard sessions often turn into important moments of team collaboration. It’s moments like these that get lost by the part of the semi-distributed team that is not collocated. Use every communication and collaboration tool in the toolbox if you’re stuck on a semi-distributed team, you’re going to need them.
Topics: Agile | 2 Comments »
I Think I’m Going To Write a Book
Friday, November 16, 2007
Today was a real break through. I was talking to two senior developers here at Gestalt this morning about how to test some code one of the teams in the Joplin, MO office is working on. I came up with this awesome idea that I threw out there to these two devs. I said, “We need to be able to automagically take some test data, pump it through our module, let it do its voodoo, and then compare the results with what we think we should see in the end. Oh yeah, and this should be able to run constantly, whenever someone makes changes to the code base, this kind of test should run.” They were speechless. I think it was because of my brilliance. I know, that’s not being very humble, but this is a HUGE break through I made today. I can’t blame the guys if they were in awe of a Scrum Master’s ability to revolutionize the world of software development in less than a minute of thought. I wonder if this is how Alexander Graham Bell’s colleagues felt when he invented the telephone?
This new way of testing software certainly demands a book. Imagine, being able to write tests in code that are run continuously as the code evolves. The confidence you’d have in the quality of your code would go way up. Ideally, you would write these types of tests before you write the code. BAM! Another magic moment just happened as I typed that last sentence. Write the tests before you code. WTTBYC is pretty catchy, no? I think I have the title for my first book right there: Write the tests before you code (WTTBYC). Imagine how writing tests first might help improve the design of your code. If you need to think about how you’re going to test the code it might force you to write things a bit cleaner.
I think the only thing I need to work on now is fighting off all the tech book publishers with a stick. I may need to get an agent. What a game changing day it has been!
Topics: Agile, Books | No Comments »
Top 10 Signs of a Troubled Daily Scrum
Friday, November 16, 2007
- Takes longer than 15 minutes
- All team members aren’t answering these three questions clearly:
- What did I commit to and get done since the last daily scrum?
- What am I committing to getting done by the next daily scrum?
- What obstacles are impeding my progress?
No one can remember what anyone else said 30 seconds after it’s over- Team member says he’s not sure what he’s going to do today & no one on the team says anything
- Impediments are rarely reported
- Scrum Master isn’t capturing impediments
- Team members who can’t make it in person don’t call in or email/tell a fellow team member their answers to the three questions prior
- Not reporting out against tasks in Sprint backlog tool (task board, ScrumWorks, etc.)
- Team won’t hold it without prodding from Scrum Master
- Team members report out to Scrum Master
Topics: Agile | No Comments »