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.

One Comment

  1. Steve Bockman:

    Well said. I especially like the part about taking smaller steps when trouble crops up.

Clicky Web Analytics