Archive for November 2008

Take small steps and work close together

I think most Agile advice boils down to two things:

  • Take small steps.
  • Work close together.

When I’m struggling, I try to see if there’s any possible way to take smaller steps, or to work closer together with others on the project.

Take small steps to get to done early and often

In software development we work at many different scales, from high-level business goals to specific user actions all the way down to lines of code. Agile methods emphasize getting to done early and often at all of these levels:

  • We take one business goal at a time and make sure it’s met before tackling the next one (exemplified by the “sprint goals” of Scrum and “minimum marketable features” as described in the book Software by Numbers).
  • We implement one user-level feature in an end-to-end slice (from persistence to user interface) before going on to the next (the “user stories” of Extreme Programming).
  • We write and test a few lines of code at a time (the “test-driven development” of Extreme Programming).

At every level, the point is to get one thing “really done” before starting on the next thing.

How do we know how small our steps should be? Experience and intuition are a starting point. If things are flowing along nicely it’s tempting to take slightly larger steps. But as soon as troubles start cropping up, a good bet is to take smaller steps: Breaking work down into smaller pieces while maintaining, or even strengthening, our definition of “done” helps to get things done cleanly and consistently.

On a recent project, the original plan was over-ambitious, allowing only a few months for what was turning out to be a couple years of work with the available resources. So we got together with the project champion and identified some specific short-term business goals: First, we needed to make sure that the first big client, on the verge of signing the contract, would get what they were promised. Second, we wanted to make a marketing announcement about the general availability of the system.

It turned out that meeting both of these goals required much less than the total vision for the software. In that case, they were both driven more by the content that we were going to be publishing through the system than by the end-user software functionality. We went through all the user stories and put a big red dot on each story card that was essential for the first goal, and a red circle on each story card that was essential for the second goal. Taking our velocity into account, it turned out that the “red dots” fit comfortably into the time available before launching with the client, and it was quite satisfying to have such clarity about what to focus on and what not to focus on for those few iterations.

Work close together to enhance communication

On every software project, we need to communicate with the customer about what to do and what’s been done, and we need to communicate with our teammates about how to do what needs to be done. Agile methods suggest frequent and lightweight communication by finding ways to work closer together, rather than staying far apart and communicating through impersonal means.

Barriers to communication can be both physical and process-related. Physical barriers can be anything from cubical walls and long office hallways to separations of hundreds or thousands of miles. Being separated by thousands of miles leads to both time zone challenges and cultural differences.

Extreme Programming (XP) recommends that the customer and the entire team work together in the same physical location. When this seems impractical for a project, it is often tempting to abandon XP or Agile methods altogether. It is also possible to miss the point, by working nearby but avoiding contact with each other. However, keeping in mind the advice to work closer together, we can be creative: We can do video conferencing, we can pair program remotely using screen-sharing tools, and we can at least visit each other from time to time, especially at the start of the project. Meeting each other face-to-face is an extremely powerful way to cut through cultural differences and interpersonal misunderstandings.

One example of a process-related barrier is individual task assignments, since if I’m on the hook to finish a task myself I will be less inclined to take a break to help you. Agile methods usually recommend whole-team estimating and planning, so that the whole team is interested in working close together to get all the tasks done. If one person is stuck, the whole team feels stuck and is quick to rally around the issue.

Regarding another process-related barrier, Agile methods have a reputation for throwing away documentation. But documentation really isn’t the point.

I was once in a meeting with a product manager talking about the requirements documents he liked to write, where at one point he leaned in close, pointed toward the QA group (not represented in the meeting) and whispered, “Those guys don’t even read the spec!” He clearly thought that was the QA group’s problem, because his spec document was clear and complete — he had put a lot of effort into it.

Agile methods do not recommend, “Throw away the requirements documentation.” Agile methods do recommend, “If the requirements documentation is causing pain, find ways to work closer together with the intended audience.” If the QA group isn’t reading the spec, maybe that’s because it’s not helping them do their job. Maybe it’s just not communicating effectively.

If it’s important, never stop!

One of the most common novice questions about Agile methods is, “When do we do X?”

People always ask this about something important, and I’ve heard it asked about a bunch of things, including design, research, testing, architecture, and optimization. I think that’s a very reasonable question, as other methods have phases for things like that. From the novice perspective, we’ve taken away the phases, so it sure can look like we’ve just discarded everything but the coding.

The agile approach

My answer is that if something is important, you should never stop doing it. Make sure a little of it happens every week, and maybe every day. Close those plan-act-evaluate loops as often as possible:

  • Is the user experience important to you? Then have a designer in the room, giving continuous feedback to developers. Do regular user testing. Instrument your production software and release it often, so you can see how well your theories play out.
  • Is reliability important to you? Then involve QA as part of the definition of the story. Build your acceptance tests alongside the production code. Write your code test first.
  • Is maintainability important to you? Then never stop improving the design of the code through refactoring, promiscuous pairing, and collective ownership of the code.
  • Is making the right product important to you? If so, always have a product manager in the room. Make sure people talk about the why of a feature, not just the what.
  • Is productivity important to you? Then have the team look back every week and find some way to improve your process. Encourage everybody to always be on the lookout for ways to do things better.

And so on, for everything that you think is important to your project.

The error of phases

A big mistake of phased processes is to think that you can get a great product by ignoring important activities for weeks or months at a time. But people only stay good at things that they do frequently. Even worse, spending months with your back turned on some important facet of your project inevitably harms it. As humans, it’s inescapable that we forget the past and insufficiently understand the future. And new information is always coming in, no matter what phase you’re in.

In truth, creating a cohesive product for an ever-evolving environment and audience requires regular attention to every aspect that matters. Instead of treating some important perspective as in the past or part of the future, bring them all into the present. If some activity really matters to your project, make sure somebody on your team is thinking about it every day.

What is “the simplest thing that could possibly work”?

Anyone with even the slightest exposure to eXtreme Programming has heard the phrase “do the simplest thing that could possibly work.” While this precept is typically applied during the process of writing code, I’ve also heard it mentioned during design discussions. I bring it up myself during estimation sessions as a reminder to estimate the simplest implementation of a user story one can imagine.

I’ve also heard it misquoted as “do the easiest thing that could possibly work” and even “do the quickest thing that could possibly work.”

It’s not necessarily the easiest thing

Although the simplest thing that could possibly work might sometimes also be the easiest thing, it often is not. For example, the easiest thing might be to copy and paste a section of code in order to duplicate its functionality in another part of a program. But is that the simplest thing? I believe it is not.

It’s not necessarily the quickest thing

The simplest thing that could possibly work might sometimes also be the quickest thing, but there aren’t any guarantees. The use of short variable and method names might be quicker (because it saves typing time) than the use of longer, more meaningful names, but is it simpler? Again, I don’t think so.

What does simple mean?

Here’s my working definition: Something that is simple is neither complex (meaning having more parts) nor complicated (meaning difficult to understand).

In the first example above, the easiest thing is not the simplest thing because doing the easiest thing (rubber-stamping the code) introduces complexity.

In the second example above, the quickest thing is not the simplest thing because doing the quickest thing (using short names) introduces complication.


If you want to do the simplest thing that could possibly work, look for a solution that is both easy to understand and lacking in unnecessary complexity.

Clicky Web Analytics