Skip to main content
Enterprise Agile Planning icon with arrows

This post is from the CollabNet VersionOne blog and has not been updated since the original publish date.

Last Updated Nov 17, 2014 — Enterprise Agile Planning expert

Enforced Workflow is inherently NOT Agile

Enterprise Agile Planning

balancing act

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.

needless complexity

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.

More from the Blog

View more
Digital.ai Government Cloud
Apr 12, 2022

Digital.ai Government Cloud receives FedRAMP Authorization through sponsorship from the United States Department of Veterans Affairs

Enterprise Agile Planning
Flagship Digital.ai Agility solutions can effectively scale agile deve ...
Read More
Nov 22, 2021

What are the qualities of highly effective agile teams?

Enterprise Agile Planning
A team is the core unit of productivity in an agile organization. Wher ...
Read More
Nov 15, 2021

How an open-first attitude revolutionized government tech development

Enterprise Agile Planning
Public perception of government is often that it is slow-moving, reluc ...
Read More
cross functional
Nov 08, 2021

6 best practices for building resilient cross-functional teams

Enterprise Agile Planning
Agile frameworks prize the quality of resilience within every facet of ...
Read More
Contact Us