Can I be agile as an individual?

I work for a very large company, and we’re in the process of moving our various software development units to what is called agile development. Some units are there already. Others (like ours) are just starting to look into it. I don’t know when we’ll get there. But I recently went through some training and was pretty inspired.

What agile is

Here are the main values of agile development, as set out in the Agile Manifesto:

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

This means:

  • Simplicity: less planning, more lightweight processes
  • Rapid turnaround
  • Iterative development
  • Constant adjustments
  • More communication
  • More transparency

What agile is not

There are lots of techniques and tools associated with agile: pair programming, stand-up meetings, cross-functional teams, burn-down lists, and so forth. But these are just some ways to work toward the values in the Agile Manifesto — they are not themselves agile. They are neither necessary nor sufficient. In other words, just because I can’t do stand-up meetings or participate in a cross-functional agile team, doesn’t mean that there aren’t things I can do to become more agile-esque and therefore work more effectively.

How can I be agile if my team is not?

As a technical writer, I follow the development environment I work in. We currently work in an old-school “waterfall” environment (first requirements, then planning, then development, then testing, then bug fixing, then beta release, then more bug fixing, then a commercial release) and I absolutely must adhere to that. I have certain things due at the various stages, and I depend on planning documents from other groups. I can’t ignore this structure even if I want to. In other words, for the most part, I must wait for my development unit to become agile before I can truly be so.

However, even though I am beholden to the milestones of the waterfall schedule that rules my project, there are ways that I can be more agile, even as an individual. Many of these are really simple.

The task board

The task board is the single most important information radiator that an agile team has. (Tom Perry)

A public, tangible (non-electronic) task board is a key part of many agile development environments, especially those using scrum as a project management framework. In its simplest form, the board shows task progress. Team members stand around the board every day to move sticky notes and evaluate progress.

Because the board is public and updated daily by those doing the actual work, iraises the project’s transparency and the team’s accountability, and clearly shows when things are behind schedule. It is more likely to be an accurate representation of where things are than is an MS Project file on a project manager’s computer that is updated weekly (or worse). In addition, it’s lightweight: tasks are described by a word or phrase that fits nicely on a tiny sticky note (some say 3-M invented agile): no heavy-duty specifications are needed.


We all have to-do lists. Some are in a notebook, others are online. A task board is really nothing more than a public, tangible, up-to-date, to-do list. And it’s clearly something that an individual can easily adopt.

The secret geek has called the task board, “The most productive and least ignorable system I’ve ever used,” preferring it to tasks managed by software: “Placing an anti-procrastination tool on the internet is like hosting an alcoholics anonymous meeting inside a brewery.”

Better communication

I admit that I prefer email to meetings or phone calls. I work on a team that is largely distributed, and I will send an email over picking up the phone 9 times out of 10. But agile emphasizes individuals and interactions; one of its key principles is: “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.” This lets people work in the same direction and quickly respond to change.

Face-to-face isn’t often possible for me, given the geography, but picking up the phone is something that I can and will do.

“Responding to change over following a plan”

This is my favorite item from the Agile Manifesto. I have spent far too much time planning and replanning my work. And despite all this careful effort, again and again I would find that that my estimates were off, I hadn’t anticipated or mitigated the right risks, and I didn’t always end up in the same place as the software developers (the design had changed since the specs were written!). For this reason, it was good to hear our agile trainer say that perfect long-term planning is impossible in the “cone of uncertainty” we inevitably have at the beginning of any software development project.

This means a few things to me:

  • Plan less (if I can get away with it!), and focus on the short-term
  • Beat myself up less when I “get it wrong”
  • Fail early, communicate, and readjust


Many agile projects fix deadlines firmly, but allow adjustments to the scope. This focuses everyone on the most important deliverables.

As an individual, I can use timeboxing to limit effort on my own work so that I don’t have things hanging out on my to-do list forever. This will help me overcome three of my big weaknesses: procrastination, perfectionism, and over-committing to things.

Reduce work-in-progress

I’m pretty bad for having a lot of stuff hanging out half-done for a long time. This isn’t ideal because humans (even girl humans) aren’t so good at multi-tasking. It makes it more likely that details will be missed. And only things done by the end of a cycle can be considered “done” — work-in-progress doesn’t help us if we’re not finished when the deadline hits.

Kanban (a form of lean programming related to agile) recommends that the number of “work-in-progress” tasks be limited to two. So if there are already two stickies in the middle column of my task board, and I want to start on another, I have to finish one first. This sounds good to me.