This article is part of the Agile Manifesto 10th Anniversary series that is being published on InfoQ.
I was not one of the original signatories of the Agile Manifesto. I wasn’t even one of the early adopters of some of the agile practices such as TDD. But looking back, I was an early adopter of agile principles, even though I didn’t realize it at the time.
I’d been using timeboxes, incremental development, continuous integration, rolling wave scheduling, inch-pebble planning and reporting, parallel development and testing, and other practices that we now associate with agile for many years, because they work.
I’d never been a proponent of command-and-control project management—I knew that didn’t work. But I was concerned that agile was a license to hack.
Back in 2001, the developers were the ones hawking agile. All they could talk about was “no documentation,” not the fact that the cost to fix a defect dropped like a stone, or that you could see running software immediately, or that you could honestly integrate testers into the project from day 1. Nope, all we ever heard was, “You don’t have to write any documentation. You just write cards.” Well, you do write cards, and you have conversations, so you still learn the requirements, you just don’t try to substitute low-bandwidth poorly written documents for high-bandwidth interpersonal communication.
Then, in 2003, a funny thing happened. I was doing an assessment for an organization that was working in 6-week iterations. Their iterations were helping, but not enough. It was clear to me that they needed to shorten their iterations.
When I wrote my report, I suggested they shorten their iterations to a maximum of three weeks, preferably two weeks. I also thought if they reduced their feature sizes to something they could complete within a few days, they could see progress faster and be able to demo it to others. I suggested they move to continuous integration, and abandon their staged integration. I also suggested they integrate their development and testing teams and their development and testing activities. I had turned into an agilist!
Later in 2003, I was writing and speaking about agile, saying things such as, “Agile is not a license to hack; agile requires more discipline from the team than any other lifecycle.”
I didn’t think if myself as an agilist, of course. I decided to experiment with some practices, such as pairing and TDD. I’d worked closely with a couple of people one-on-one, back when I was a developer, and I wasn’t sure if it was really pairing. So I tried pairing and TDD with a colleague, Keith Ray, at an AYE conference, and sure enough, it was just like what I had done at work. Except, Keith was much nicer than my work colleague back in the ‘80s.
Later, in 2005, Esther Derby and I pair-wrote the final draft of Behind Closed Doors: Secrets of Great Management, the draft that went on into print. Yes, we sat there, with one computer and one keyboard, and took turns writing and navigating. Yes, we had questions we had to answer before we wrote a single word.
You see, we’d started to write the book in 2000. Our first draft took us a couple of years to write and when sent it for review, our reviewers said, “Great content, too boring.” So, we spent another couple of years revising it, rewriting it, and sent it for review again. Our reviewers said, “Great content. Even more boring than the first draft.” We were in trouble.
Esther suggested we change the format and that we pair-write. I don’t remember which one of suggested we ask questions for each chapter, effectively making it also test-driven. But, instead of this draft taking us two years to write, we wrote the draft in six weeks. And, it wasn’t boring!
Even as long ago as 1994, when I first started teaching project management, I taught scheduling with yellow stickies and iterative approaches to scheduling and that your scheduling approach depends on your lifecycle. Now, I include agile in my list of lifecycles and teach how to use iterative scheduling for all the lifecycles.
I became concerned in the early 2000’s when people who had never tried agile decided agile was a license to hack. When I challenged their experience, and they replied loftily that they didn’t need experience to know that a project with no documentation was hacking, I asked them to explain their project successes using examples. Without fail, they all explained their successes using prototypes (examples of iterations) and features (increments of development). When I explained that they had described elements of agile, and that they could write documentation if there were customers, such as the FDA or other regulatory agencies who might need it, they became less antagonistic towards agile.
There are still people who don’t believe you can use agile for every project. I’m one of them. Not because there are products that are not ready to use agile practices. I’ve even used agile approaches on hardware products, including chip design.
Nope. It’s because there are still people, teams and organizations who are not ready for the transparency that agile brings.
A serial lifecycle allows people to hide:
- It allows management to hide multitasking and lack of decision-making, a form of management debt.
- Serial lifecycles helps architects hide from realizing they don’t know enough to make architectural decisions without enough data.
- It allows developers to hide from defects and from testing code.
- Serial lifecycles allow project managers to weave a fairy tale of a Gantt chart, and invite other people to believe the schedule—to create write-once, read-never schedules, and then hide behind the schedule.
- Serial lifecycles allow testers to hide from automating testing where it makes sense to do so.
In short, serial lifecycles allows all of us to hide from all of the practices we know will improve the quality of our code, our projects, and our technical lives.
Until we are all willing to embrace the transparency that agile brings, we will talk about becoming agile, but we will not embrace agile as a system—a holistic approach to work. And there is plenty of talking about becoming agile and much less about doing around.
Now, in 2010, I’m expanding my use of kanban boards inside timeboxes, and instead of timeboxes in some cases. That’s because some of my clients cannot commit to anything inside of a timebox, but they can commit to completing a feature or a fix, and that’s good enough for me—and more importantly, for them.
Back in 2001 I thought of myself as a pragmatist, and I still do. I want to work, and I want my clients to work, in whatever way or ways that fits best for them in their particular circumstances. Often, that means a combination of approaches, practices, and techniques.
I may be an accidental agilist, but I am firmly in the agile camp now. What’s most important to me is to look at the context of the people, the product, and the project and help the people make the best decision for now, moving towards effective agility as best they can.
About the Author
Johanna Rothman works with companies to improve how they manage their product development--to maximize management and technical staff productivity and to improve product quality. Johanna chaired the Agile2009 conference. Johanna is the author of several books:
- Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects
- The 2008 Jolt Productivity award-winning Manage It! Your Guide to Modern, Pragmatic Project Management
- Behind Closed Doors: Secrets of Great Management
- Hiring the Best Knowledge Workers, Techies & Nerds: The Secrets and Science of Hiring Technical People
She writes columns for Stickyminds.com and on “extreme project management” for Gantthead.com, and writes two blogs on her web site, jrothman.com. She has just started blogging on http://www.createadaptablelife.com/. She is a host of the Amplifying Your Effectiveness conference.
