This post is from the CollabNet VersionOne blog and has not been updated since the original publish date.
Enforced Workflow is inherently NOT Agile
One of the ironies of being a technologist in the Agile world is that while we love our tools and toys, we also know that some things should be done by hand. One of my jobs as a consultant at VersionOne is to help people understand what the tool will and won’t do. Needless to say, I believe wholeheartedly that the tool does all that it should, and is a fantastic tool for understanding where we are as a team, and where we intend to go. Its a very interesting balancing act, and I have always been impressed, especially when I was a customer, at how well the product management team performs this act.
I am often asked “when will you automate the workflow for a [epic/story/task/test]”? My answer has been the same for quite some time now: “hopefully never”. This gets me some interesting responses, mostly disbelief. The fact that the workflows are not predefined is not a missing feature, but a fundamental understanding of a basic fact. Automated workflows are inherently not Agile.
Let’s start with the most glaring evidence of this statement. The Agile Manifesto’s very first identified value is Individuals and Interactions over Processes and Tools. Tools are valuable when they enable interactions between individuals. When they start to replace those interactions, we are hurting ourselves. Agile is about being able to be quick on our feet and embrace change, even late in development. Having a tool enforce what should happen next slows that down. Let the tool represent what is going on, not try to decide what is going on.
The next challenge is the fact that Agile teams understand the pitfalls of Big Design Up Front. If we acknowledge that trying to create an entire design and architecture up front is a waste of time and energy, why don’t we acknowledge the same for designing a process up front? There are just too many different states that a story, etc. can be in during development to be able to predict the flow. Any attempt to do so is taking energy away from our primary purpose, which is providing value to our customers. Obviously we will have some agreements of general ideas, like Test comes first, and a story isn’t accepted until all of the tests pass, but we don’t need to automate that.
Lastly, let’s remember the main difference between Agile planning ideas and traditional planning ideas. The idea around Agile processes’ planning is to reflect and react to reality. VersionOne provides many ways to do this, my favorite being Team Rooms. I want a wall sized monitor where I can project my Team Room on the wall in my workshop, providing me with a giant informed work-space. Traditional processes try to bend reality to some arbitrarily decided workflow. And guess what? Whenever there is a battle between our planned workflow and reality, reality will always win.