The Agile Architect
Good Agile Is Messy Agile
Our Agile Architect explains why a clean, well-organized environment is bad for your Agile project.
- By Mark J. Balbes, Ph.D.
- March 15, 2012
I was looking out over my war room the other day, thinking about what a cluttered mess it was. There were chairs at random locations, some at pairing workstations, some in the middle of the floor. Tables were strewn with papers, books, pens, markers, index cards, butterfly clips, and hand-held whiteboards with scribbled diagrams (but not UML diagrams..."Is UML dead?" will sadly be the topic of a future column) and writing. Our Kanban board was a Frankenstein-inspired patchwork of push-pins, various size ropes to mark our swim lanes and queues, index cards, photos and hastily-written WIP limits.
And I thought to myself, why? Why are we such slobs in the war room when our code is so clean and well organized? We work hard to follow strict disciplines of Test-Driven Development, refactoring, continuous integration, working builds and all the other practices that lead to high quality code.
And then it struck me: It's all about lowering the barrier to change. With software, the more organized it is, the easier it is to have tools that let you change the code en masse to support new features, processes, and techniques. Uniformity and consistency create the opportunity for change, enabling continuous improvement.
However, the war room itself is a physical environment. We can't just invoke our refactoring tools and make mass changes to it. Creating a well-organized environment takes significant work. Once we've done the work, we are going to be reluctant to change it. Thus, a clean well-organized environment is actually an impediment to continuous improvement.
Let's take an example:
Two years ago, our Kanban corkboard started out with four queues: On Deck, In Development, Testing and Ready For Demo. We hung ropes vertically to create the queues and placed push pins to hang stories from. The push pins were also a simple, natural way to enforce our WIP limits.
A few months later we added a Review queue after Development. With a few quick moves of the rope, we created the queue. No muss, no fuss.
Later still in a retrospective, we recognized that we were creating incomplete features because we were always looking at the product from the story level, not the feature level. So we changed the board again -- this time rather drastically to manage groups of stories called Minimal Marketable Features (MMF). Now we needed to add additional queues at the end of our process so we could review and test the functionality as a whole before calling the MMF done. We drew out what we wanted on a white board and then took the few minutes to change the Kanban to match.
But what if we had been neater? What if, in our original Kanban, we had taken the time to create a beautiful, neat, organized, professional-looking Kanban board with an aura of permanence that inspires the confidence, "Yes, we know what we are doing!" That might have been the last change to our Kanban process we ever made.
I'm currently spinning up a second team at a client site. The client's office is the typical cubicle-based corporate environment where everything is neat, tidy, and medicinally clean. Except for our war room. We are on day two of the project and the war room is a glorious mess. No one knows yet where to put our whiteboards, corkboards, workstations, coats or us. It's a tumultuous mass of moving parts as we develop our first stories, figure out how to self-organize as we go, and put just enough effort into our physical environment to keep ourselves and our software moving forward effectively.
I'm sure there's a limit to how messy is too messy. Over the last four years, we've brought it up twice in retrospectives. But in general, we seem to effortlessly maintain a blissful state of messy equilibrium.
So if you get flack from your boss about the messy state of your war room, show your boss this column and know I've got your back. But if you try to use this column at home, you're on your own!
Dr. Mark Balbes is Chief Technology Officer at Docuverus. He received his Ph.D. in Nuclear Physics from Duke University in 1992, then continued his research in nuclear astrophysics at Ohio State University. Dr. Balbes has worked in the industrial sector since 1995 applying his scientific expertise to the disciplines of software development. He has led teams as small as a few software developers to as large as a multi-national Engineering department with development centers in the U.S., Canada, and India. Whether serving as product manager, chief scientist, or chief architect, he provides both technical and thought leadership around Agile development, Agile architecture, and Agile project management principles.