balancing actOne 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 Face-to-face-marketingfirst 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 complexityThe 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.

Join the Discussion

    • Cesar Brod

      Thanks for the great article. I keep telling the teams I coach that an automated tool can only be used if it does add speed to the process, not bureaucracy, and if it helps communication, not replaces it.

      • Steve Ropa

        Thanks Cesar,
        As I’m sure you can imagine, I absolutely believe that VersionOne can and does add speed to the process, and more importantly aids in communication. But it has to be done right, and not at the expense of the team. Too many times I see someone trying to replace talking to each other with a series of reports and dashboards, rather than using those reports and dashboards as illustrators while talking!

    • Don O’Neill

      Agile Work Flow

      Let’s get down to brass tacks in the discussion of Agile Work Flow.

      The successful Agile Software Development project progresses through the following sequence of Alpha states of the SEMAT Essence Kernel.

      Team selected
      Opportunity selected
      Value Proposition established
      Way of working foundation established
      Stakeholders in agreement
      Work started
      Performing (Initial Release)
      Stakeholder satisfied with deployment
      Performing (Incremental Releases)
      Work under control
      Stakeholder satisfied in use
      Value proposition benefit accrued
      Performing (Final Release)
      Way of working working well
      Closed

      • Steve Ropa

        Hi Don,
        While I suppose these states are actually all passed through, I don’t believe this is a sequence that can be mandated or automated. Many of the states you mention happen organically with a well supported self organized team, such as “Team Selected, Way of working foundation established”, etc. I see this list as a great Meta-view of how teams organize themselves.

        • Don O’Neill

          Steve,

          Without imposing this sequence as an enforced workflow, do you consider this post hoc Agile sequence as evidence of a successful Agile project?

          If not, what would you change?

          • Steve Ropa

            Don,

            Yes, I think that evidence of this workflow emerging is an excellent indicator of Agile success. Not the only indicator, but one for sure.

    • Karen Bruns

      Great article. Thanks for the support! Blogs such as this one help us coaches out in the field.

    • R Douglas Shelton

      The connotation of the quite loaded word “Enforced” influences the rest of this article. As in all things, workflow can be the right tool for appropriate communication depending on the context. Let’s compare it for example, to emails: [see the following article, B-T-W: https://www.recruiter.com/i/email-the-essential-communication-tool-youre-using-wrong/?utm_content=bufferc7fd3&utm_medium=social&utm_source=linkedin.com&utm_campaign=buffer}. In particular I refer to highly distributed teams with major time differences (e.g., 12.5 hours difference between Bangalore and the US West Coast]. The Bottom Line is that not **all** necessary communication between such highly-distributed teams is going to be “real-time” [the preferred approach], because of such time differences. So in such circumstances, I’ve seen emails used as the means for non-real-time communication. My experience is that using email for this is just about the absolute worst way to approach non-real-time communications – particularly when most of those emails involve making some sort of necessary decision. Under such circumstances, I’ve found a condensed customized workflow with escalations and alerts using a product such as Jira, for example, is far, far superior for any such kind of communication, as it “keeps the subject matter {and decisions] “on track”. – and in fact results in a very much condensed {shorter} timeframe for resolving the issue.

      • Steve Ropa

        Hi, lots of good points here, even the ones I don’t necessarily agree with (for instance, I would say that VersionOne is far superior to Jira for communications 🙂 ).

        So, I’d like to address some of these points:

        1. The loaded word Enforced was absolutely chosen for its “loadedness”. A well understood workflow is a good thing. Knowing how a story normally progresses from point A to Z is valuable and informative. Enforcing a workflow means that a story must follow a set, pre-defined path, and can’t deviate. “Thou shall not count to two, unless thou then proceedeth unto three”. I want there to be flexibility, and I especially want humans to make the decision where the story goes from here, not an automated script.

        2. Email. I agree. I feel that Email is the worst form of communication we humans have ever invented. It is Fire and Forget. How many times have we asked someone how something is going, or why it is stalled, and the response is “I sent so and so and email….” It implies that once i send this thing off into the ether, it is no longer my responsibility. At least with smoke signals we had to take time to build a fire, during which time we could consider whether this message is really worth sending.

    • Phillip gadzinski

      Interesting article and I like some of your points.
      The one I don’t agree with is the comment on” not designing a process up front”. Absolutely all teams, agile or not, define their initial way of working up front. Without this clarity there is confusion in the team on what constitutes how work should be moved between States, States considers complete, and when something should be considered done. This is a process.
      So I think we don’t impose one externally, but we impose the discipline of establishing one externally.
      Just my thoughts on the context of offshore, vendor teams running agile models!

      • Steve Ropa

        Hi Phillip,

        Thanks for the comments. I think the trick here is that the team defines their *initial* way of working. But there is an implied flexibility in this. The team does indeed need to have clarity on how things can move between states, but this is a working agreement. My concern is when this gets automated, as it takes away the human element, thus abdicating the responsibility to communicate with each other.

    • L Sunil de Silva

      Agreed that the entire design and architecture up front is waste of time and resources. However architectural and design should be done up to certain level at this point.

      • Steve Ropa

        Thanks for the great comments. I would agree that a very minimal amount of architecture and design should be done up front. Maybe an agreement that we will, for instance, be Service Oriented and what ESB we will use. Or if a database is absolutely necessary and if so which one. Other than those very broad ranging “napkin sketches” I would really much prefer to allow my architecture, of any sized system, be mostly emergent.

    6 + 2 =