Skip to content

Check out our O’Reilly Week in Review podcast interview

Wednesday, May 27, 2009 - by Andrew Stellman

Edison Phonograph

James Turner’s weekly O’Reilly Week in Review podcast this week features an interview with Jenny and me about Beautiful Teams, and what goes into making a team work well.

I’ll transcribe a quick excerpt from the interview – we’re talking about our interview in the book with NASA manager and team leader Peter Glück:

Jenny: You hear all your life about what it’s like to work at NASA. There were so many times we’d want to put in place a practice, and you’d hear, “Well, this isn’t NASA”. So to hear about how NASA actually did stuff was really exciting. It was such a revelation that they pretty much do stuff like everybody else, you know?

Andrew: I kind of had a feeling of, “They put their pants on one leg at a time, just like everyone else.” They build the same way, they test the same way, it’s just that they put a whole lot more time, money and effort into testing. And there are some things they can’t to. We talked about continuous integration. I asked him, “Do you do continuous integration?” Well, no, they don’t do continuous integration, because that involves integrating with a hardware platform that they have to take into a clean room. If your inegration process involves a clean room, it probably can’t be automated.

If you want a little background about what goes into building an O’Reilly book, working with the folks there, and some of the thought process behind Beautiful Teams, definitely have a listen. You can hear the whole interview here!

Did you like this post? You can help us out by sharing it! These icons link to social bookmarking sites where readers can share and discover new web pages.
  • del.icio.us
  • Digg
  • Reddit
  • Slashdot
  • Technorati
Filed in Q&A | Comments (0)

The Secrets Of Great Teamwork

Wednesday, May 13, 2009 - by Andrew Stellman

Beautiful Teams and Tim O'Reilly

Forbes picked up our Beautiful Teams interview with Tim O’Reilly and published it as an article called The Secrets of Great Teamwork.When Jenny and I talked to Tim, he had some intriguing things to say about what makes people work together. There’s plenty of good stuff in the interview, but one bit that really sticks in my mind is this excerpt:

Andrew: Do you think it’s possible to have a great team that doesn’t have a great leader? That has more of a collective leadership?

Tim: Yes, it is possible. But here’s the thing. Take Apache, because I think Apache is a great example of that. Tim Berners-Lee laid down the blueprint. He said, “I’ve created this idea for this hypertext server, this hypertext client.” And the genius of Apache was in embracing the constraints. I still remember back in the mid-’90s, this moment where Netscape had added this, Microsoft had added that, and everyone was saying, “Apache seems to be standing still. They aren’t adding all these features. They aren’t keeping up!” And the guys at Apache said, “Yup. What we do is a hypertext server, and we have this nice extension mechanism where people who want to do something else can add it on.”

And that goes back to that architecture of participation. They didn’t build this big, conglomerate, complex application. They kept to a pure vision. The vision did actually come from a visionary leader; it just wasn’t part of Apache. Apache came from a group of people who were abandoned by the NCSA server team when they all went to found Netscape. And there were a bunch of customers, so they said, “We have to maintain this, and keep it going.” What was wonderful about that kind of team was that they accepted the constraints that were laid down by the design of the system. They didn’t try to show off their ego or their creativity.

I think a lot of the work done by the IETF (the Internet Engineering Task Force) in the early years did the same thing. There were some wonderful principles laid down, and people really honored them. If you read some of John Postel’s stuff in the TCP RFC about the robustness principle, it sounds like something out of the Bible, for Christ’s sake! “Be conservative in what you do; be liberal in what you accept from others.” Literally, that’s what it says.

The point is that if you have the system architected right, you have a better chance of success for teams. You don’t want teams that are dependent on a single vision or leader, because if you lose your leader, the whole team goes “pop.”

Something that came up over and over again throughout our many interviews and stories is the connection between teamwork and architecture.  I think Tim hit on exactly the right example with Apache, but there are a lot of other examples throughout the book. Peter Glück had some really interesting things about how the architecture restrictions of NASA projects affected the teams (and especially the practices they used). And Auke Jilderda talked about the “use-use-reuse” model for designing reusable code, and how it impacts teams. I have to be honest: before working on Beautiful Teams, I definitely didn’t make such a close connection between how great (or lousy) teamwork affects architecture.

You can read the entire interview — which, incidentally, is one of my favorites in the book! — on O’Reilly FYI.

Did you like this post? You can help us out by sharing it! These icons link to social bookmarking sites where readers can share and discover new web pages.
  • del.icio.us
  • Digg
  • Reddit
  • Slashdot
  • Technorati
Filed in Books, Teams | Comments (1)

Requirements 101: User Stories vs. Use Cases

Sunday, May 3, 2009 - by Andrew Stellman

Business Analyst

Here’s a question that I get over and over again:

What’s the difference between user stories and use cases?

— Ron K.

Before I dive into an answer to that question, let’s rewind a little bit and talk about where user stories came from. I like them because they’re a great example of how the Agile movement changed the software world. Programmers used to just dive right into software projects and start coding. Whenever one of those pesky users started to tell us what they needed, we’d stop them and say something like, “Don’t worry, I totally get it. I know what you need.” The Agile folks figured out that “I know what you need” is a nasty little trap that programmers — especially good ones — fall into. We’d spend the whole project thinking that we understood our users’ needs, only to deliver software that they didn’t want. The Agile folks realized that if developers had to start working with users throughout the project to understand their needs if they wanted to avoid the code-and-fix trap.

And that’s why I think the user story is one of the most useful tools to come out of the Agile movement. A user story — some people call it a scenario — expresses one very specific need that a user has. It’s usually written out as a couple of sentences. Most user stories are written in the language of the users, so any user should be able to read a user story and immediately understand what it means. A lot of time, user stories are written on index cards, although I’ve put them in Word documents, Excel spreadsheets and Wiki pages (depending on how the particular project is run).

A use case is similar to a user story, because it also describes one specific interaction between the user and the software. When I’m training people to improve the way they write down their project’s requirements, I often describe the use case as a “deceptively simple tool” that helps us find and write down all of the ways users interact with the software.

Looking at those definitions, I can definitely see why there’s confusion about the difference between user stories and use cases. If you look at the last two paragraphs, it might sound like I said the same thing twice! But while user stories and use cases are definitely similar, there are important differences between them. Each serves a distinct purpose, and I think they both have their place on a well-run software project.

I think the easiest way to understand the difference between use cases and user stories is to take a look at an example. Luckily, I’ve got one that I think helps make the difference clearer.

In our first book, Applied Software Project Management, Jenny and I spend a lot of time talking about how to develop use cases and use them to build better software. And as an example, we showed a use case for a software feature that everyone should be familiar with: a search and replace feature from a word processor. Comparing a user story for search and replace with a use case for the same feature helps highlight the differences.

It’s not hard to find lots of user story examples. There are lots of different ways you’ll see a user story formatted (although if you’re looking for a user story template, a 3×5 index card should be a good starting point!). So what would a user story for search and replace look like? I took a stab at writing one:

search-and-replace-user-story-card

(One thing I like to do with user stories is to use “he” or “she”, rather than try to be gender-neutral. I think this makes the user in the story easier to connect with by personifying him a bit. It it also lets me write in a more conversational tone, which makes the user story friendlier and, I think, a bit easier to read and understand.)

Now, if you’re not familiar with user stories, you might think to yourself, “Wait a minute, my word processor’s search and replace feature does a lot more than that!” And that’s okay. A typical user story will have enough information to help the user understand what it is the software needs to accomplish, but it’s not meant to be a complete description of how the software works. I’m not going to try to give a long lesson in writing effective user stories here; I highly recommend reading Mike Cohn’s excellent articles and posts aboout user stories. (Mike, incidentally, is one of the software development veterans who contributed to our latest book, Beautiful Teams [O'Reilly, 2009]. He has some really fascinating things to say about Agile planning.)

So what would a use case sample look like for search and replace? Here’s the use case example Jenny and I built to demonstrate how use cases work:

Name UC-8: Search and Replace
Summary All occurrences of a search term are replaced with replacement text.
Rationale While editing a document, many users find that there is text somewhere in the file being edited that needs to be replaced, but searching for it manually by looking through the entire document is time-consuming and ineffective. The search-and-replace function allows the user to find it automatically and replace it with specified text. Sometimes this term is repeated in many places and needs to be replaced. At other times, only the first occurrence should be replaced. The user may also wish to simply find the location of that text without replacing it.
Users All users
Preconditions A document is loaded and being edited.
Basic Course of Events
  1. The user indicates that the software is to perform a search-and-replace in the document.
  2. The software responds by requesting the search term and the replacement text.
  3. The user inputs the search term and replacement text and indicates that all occurrences are to be replaced.
  4. The software replaces all occurrences of the search term with the replacement text.
Alternative Paths
  1. In Step 3, the user indicates that only the first occurrence is to be replaced. In this case, the software finds the first occurrence of the search term in the document being edited and replaces it with the replacement text. The postcondition state is identical, except only the first occurrence is replaced, and the replacement text is highlighted.
  2. In Step 3, the user indicates that the software is only to search and not replace, and does not specify replacement text. In this case, the software highlights the first occurrence of the search term and the use case ends.
  3. The user may decide to abort the search-and-replace operation at any time during Steps 1, 2, or 3. In this case, the software returns to the precondition state.
Postconditions All occurrences of the search term have been replaced with the replacement text.

Now, if I were a developer building a word processor or text editor, I’d actually be able to write a search and replace feature that implements that particular use case. (Just to be clear: there are many different use case formats; Jenny and I use this use case template in our book because it’s stripped down to the bare minimum sections that we think an effective use case should have.)

Here’s something about use cases that I think is interesting. While you were reading through our use case example, were you thinking of something that looks like the Replace dialog in Notepad or Microsoft Word, or the Find dialog in TextEdit? If so, take another look at the sample use case. It doesn’t have any words like “window,” “button,” “click,” “field” or “checkbox”. It’s all about what actions the user takes, and how the software responds. And there are many different ways that you could build software that implements the use case. Have you ever used the search and replace feature in vi? What about the search and replace feature in Emacs? They have very different user interfaces! Who knew there were so many ways you could implement search and replace? But if you compare each of them with this use case, they all follow the same basic course of events.

So now that we’ve gone through the use case and user story examples, what’s the difference between user stories and use cases? Here’s what I think are some of the key differences:

  • User stories are about needs. When you write a user story, what you’re describing is a “raw” user need. It’s something that the user needs to do in his day-to-day job. If you never build any software for him, then that need will still exist!
  • Use cases are about the behavior you’ll build into the software to meet those needs. A developer who needs to build working software should be able to read a use case and get a good sense of what the software needs to do. It typically has a lot of detail, and describes everything that the developer needs to build in order to meet the user’s need. That’s why it needs to have a lot more detail, and be clear and unambiguous.
  • User stories are easy for users to read. When you write a user story, what you’re concentrating on is writing something that anyone can understand, in the language of the users. We all know that developers have a lot more patience for talking about details of the software they’re building than users do, which is why user stories have to be brief. A user story needs to express a complete thought in just a couple of sentences. (That’s also why it’s good to put them on index cards: somehow, that makes it clearer that it’s self-contained and independent of the other user stories.)
  • User cases describe a complete interaction between the software and users (and possibly other systems). When you’re doing use case analysis, what you’re doing is designing a functional solution that meets the users’ needs. It needs to be something that developers can implement. It’s possible that one user story could spawn several use cases. And when you combine all of your use cases into one use case document, you’ll end up with a complete description of every interaction between the user and the software that you’re planning on building. And if your software has to interact with multiple systems, you may end up treating those other systems as actors in your use case.

Once you get a sense of how user stories and use cases differ, you can start to see what purpose they can serve on your project. And if you only use user stories, or if you only use cases, then maybe on your next project you can try using them both.

Did you like this post? You can help us out by sharing it! These icons link to social bookmarking sites where readers can share and discover new web pages.
  • del.icio.us
  • Digg
  • Reddit
  • Slashdot
  • Technorati
Filed in Agile, Requirements, Software Development | Comments (0)

Our new “Beautiful Teams” talk at Boston SPIN

Thursday, April 23, 2009 - by Andrew Stellman

Andrew and Jenny at Boston SPIN

We unveiled a new talk on Tuesday at Boston SPIN! We love Boston audiences/ We met some great people (hi Abby!), and things went really well. As promised, here’s a PDF of the slide deck.

Beautiful Teams Slide

We were especially pleased to finally meet Johanna Rothman in person. She was our first Beautiful Teams contributor — we’d spent plenty of time on the phone with her, but we’d never met in real life. She made a special cameo appearance, and told her story from the book!

Special guest apparance by JR

Thanks again to everyone who attended and gave us such a warm welcome.

Did you like this post? You can help us out by sharing it! These icons link to social bookmarking sites where readers can share and discover new web pages.
  • del.icio.us
  • Digg
  • Reddit
  • Slashdot
  • Technorati
Filed in Presentations | Comments (0)

Bringing a “teamwork feel” to your projects

Tuesday, March 31, 2009 - by Andrew Stellman

When cheering fails

Jenny and I have been thinking a lot about teams lately. Working on Beautiful Teams really focused us on teamwork: what makes teams gel, what causes them to run into trouble, and what you can do to them. So when I got this question recently, it was really timely:

I’ve been working on bringing more of a teamwork feel to our projects for 2 years.  It has proven to be a non-trivial task. Any advice?

Now, just so we’re clear here, I know this guy pretty well. He’s a very good manager, and he runs a software development group with some of the smartest people I’ve met professionally.  They’re definitely a functioning group: they’ve been building software for years, and that software is used in production in critical applications at his company. By many accounts, his group is successful.

But when I took a closer look at how that particular team works day-to-day – and this should seem very familiar to a lot of developers – I definitely saw what he meant about it being a non-trivial task. There’s definitely a lack of a teamwork feel on the various projects his team works on. Everyone is really good at carving out his or her own piece of work, and is able to work on that piece independently. But even when multiple people would work on a single release of the same piece of software, they’d work independently of each other, not really talking amongst themselves. Don’t get me wrong – they definitely get their jobs done. But they’re working on individual tasks, not team projects. And even when those tasks add up to projects, it just feels like loosely connected tasks to the people working on them.

So what’s the harm in that, if they’re getting the work done? Well, for one, having a group of people working like that doesn’t exactly encourage innovation. There are some genuinely brilliant people on that team, and they do reasonably good work, but I would honestly expect more innovative work from this particular group of people. And I believe that having more of a “teamwork feel” would encourage more innovative work.

What’s more, I got the feeling that this particular team still runs into a lot of the same problems that many other, less talented teams run into, and I think those problems could be improved through better teamwork. They have some serious change management issues, where they often have to rework their code because it doesn’t quite meet the needs of the projects’ users. They have a few code quality problems – they’re trying to address them with better code reviews, which they’re having trouble getting off the ground. And they have an overall client relationship problem, where the people they build software for often feel like they’re somewhat disconnected, like they can’t quite the software that really meets their needs. Again, these are highly talented, very smart developers, with a manager who’s on the ball – and they’re still getting stuck on the same problems that hit everyone else.

Now, I don’t want to make the situation sound worse than it is. The manager has made some very good progress in getting the individuals working in a more team-like way. One thing he did that I really like (and I think it worked really well) was to really encourage everyone to write things down in the Wiki. And this wasn’t just a general edict (“Each person must add X wiki pages, or else!”). It was actual encouragement and support, treating documentation like it was a real and highly appreciated part of peoples’ jobs. Like a lot of new tools, there was a slow start to it, but once a few people dove in and started to embrace it, it started to really take off. And a funny thing happened: as people started sharing information with each other, they started to learn more about each others’ work, and some of them started to get that “teamwork feel” that they were looking for.

So what’s going on with this person’s group? And, more importantly, what can he do to help improve the “teamwork feel” for everyone?

Whenever I’m trying to help a group of effective but disconnected developers become a team, I like to start with this great analogy from Watts Humphrey:

There are different kinds of teams. In sports, for example, a basketball team’s positions are dynamic while baseball team members have more static roles. However, in both cases the members must all work together cooperatively. Conversely, wrestling and track teams are composed of individual competitors who do not dynamically interact, although the members support each other socially and emotionally.

In engineering, development teams often behave much like baseball or basketball teams. Even though they may have multiple specialties, all the members work toward a single objective. However, on systems maintenance and enhancement teams, the engineers often work relatively independently, much like wrestling and track teams.

A team is more than just a group of people who happen to work together. Teamwork takes practice and it involves special skills. Teams require common processes; they need agreed-upon goals; and they need effective guidance and leadership.

When I reread that quote before pasting it in here, something in that last sentence stood out to me: they need agreed-upon goals. Now, I’ve been referencing that quote for almost a decade. But it’s really interesting to me that I always overlooked that last bit. But working on Beautiful Teams really taught me the value of agreed-upon goals. It was pretty remarkable, actually: contributor after contributor brought up the idea that the people on a project all need to be aligned to the project’s goals, and to have a single, overarching vision that the team can rally around.

So if I had to give a single piece of advice to this manager, it would be this: try to find ways to give everyone a good sense of their goals. Two different Beautiful Teams contributors – Mike Cohn and Steve McConnell – talked about helping the team see an “elevating” goal. I really like how Steve put it:

First, the team leader needs to establish an elevating vision or goal, and I think that this is truly a leadership function, not just management. It goes beyond the management function. An awful lot of thought should go in on the part of the team leaders into what is the team’s goal and what is it about it that is not just trying to trick the team into thinking they have a goal that’s elevating or inspiring, but to come up with one that truly is.

A classic example is if you’re out digging ditches, that’s not very elevating or inspiring. But if you’re digging ditches to protect your town that’s about to be attacked by an enemy, well, that’s more inspiring, even though it’s the same activity. And so the leader’s job, really, is to try to determine or frame the activity in such a way that people can understand what the value is.

Now, that’s not an easy thing to do. But Jenny and I heard this message (or one similar to it) from so many of our Beautiful Teams contributors – Keoki Andrus, Neil Siegel and Mark Healey all come to mind, although other people talked about it too – that it actually changed the way I think about how teams work. In the past, I always looked at defining a project’s vision and scope as a straightforward tool for setting the top-level scope of the project and preventing changes. One thing I learned was that I wasn’t giving “vision” part of it nearly enough respect. Talking openly and often about that vision – and coming back to it when you do things like discuss project assumptions, come up with scenarios (or user stories, or use cases… however you figure out how your users will use the software) and plan out the work the team’s going to do – is the first step in really getting your team to have that “teamwork feel.”

Did you like this post? You can help us out by sharing it! These icons link to social bookmarking sites where readers can share and discover new web pages.
  • del.icio.us
  • Digg
  • Reddit
  • Slashdot
  • Technorati
Filed in Q&A, Teams | Comments (0)