The Agile Coach on ‘Individuals and interactions over processes and tools’

It’s one seemingly simple word repeated four times in the Manifesto for Agile Software Development http://www.agilemanifesto.org

Over

Experience has shown me that some folks overlook the meaning of this word, sometimes leading to a fundamental misunderstanding of the entire Agile Manifesto.

In fact, the authors of the Agile Manifesto went on to provide a bit of clarification, as follows:

“That is, while there is value in the items on the right, we value the items on the left more.”

But what does that really mean? How much more should we value the items on the left? A 70/30 split? 60/40? How can we even measure that? Should we?

In this blog post, I’m going to concentrate on the first value statement in the Agile Manifesto…

‘Individuals and interactions over processes and tools’

Certain tools contain definite advantages, particularly if you’re rolling out an Agile adoption and transformation effort across your organization. There’s the Agile software management tool, the various Agile engineering and development tools, the bug tracking tools, and the automated testing tools, just to name a few.

I’m sometimes asked the question, “With the Agile software management tools becoming more and more prevalent in organizations, are we getting away from the importance on ‘individuals and interactions’?

I think it depends on the organization, and even the uniqueness of individual teams. It doesn’t have to be some predetermined division between the two. Simply trust that your organization and teams will determine what that right mix is. In typical Agile fashion, it will likely change, as we inspect, adapt and become more mature along the way. If teams aren’t collaborating well with one another, a good Agile Coach or experienced Scrum Master can help drive these behaviors.

If you’re like many organizations these days, you’re likely thinking about how to scale, how you’ll handle remote work / off-shore development, storing project data safely and securely, reporting metrics, visibility, et al. These thoughts typically lead to discussions around acquiring an Agile software management tool that can provide you with that ‘one stop shop’. And as you might imagine, most Agile software management tools follow your typical Agile/Scrum process (Product Planning, Release Planning, Sprint Planning, Sprint Tracking, Sprint Review).

But just because we’ve acquired this wonderful new Agile management tool that stores all our stuff in one place, provides visibility, metrics, etc. doesn’t mean we can now go back to ‘cube farmville’ and put on our headphones all day long. We should be interacting with one another, collaborating on stuff, ironing out details, confirming understandings, asking questions, going to lunch, getting to know each other better, developing trust and bonds. Face to face interaction. In this new Agile world we live in, producing software requires us to be more social than we may have been in the past. And that’s not something that’s going away. The folks that got into IT specifically because they didn’t want to deal with people may be in trouble. Yes, we all still need our quiet/focus time. That’s what focus spaces are for. Most companies recognize this and in addition to providing small focus spaces outside the team room, are issuing laptops or tablets now, and not desktops. Mobility provides the opportunity to get away and focus when necessary. Ironically, it also provides greater opportunity for collaboration.

One of the best and simplest examples I can think of in terms of successfully marrying up these values (‘Individuals and Interactions’ with ‘Processes and Tools‘) is the Daily Stand Up Meeting. The Scrum Master might display the Team’s active Sprint on a wall/screen using a projector plugged into a laptop running an Agile software management tool. Along with the Sprint backlog items and tasks, the team can review the Sprint Burndown chart and the Cumulative Flow as it stands each day. This common visibility via the tool, along with the process of meeting each day for a DSU meeting helps drive discussions and collaborative meetings, driving you to plan, track and advance as you go; empiricism – one of the main concepts of Agile methodologies. And as a result of utilizing both values, there are no real surprises any more. The risks, issues and impediments are being addressed daily with the team, and are transparent in the tool and as part of the process. If folks know what these issues are, they’re more likely to help you remove them; yet another good thing.

By the way, did you catch the change in the first sentence of the previous paragraph? I even italicized it. Used the word ‘with’ instead of ‘over’. Is that wrong? Does that change the way you think about this value?

This entry was posted in Agile Adoption, Agile Management, Scrum Methodology. Bookmark the permalink.

3 Responses to The Agile Coach on ‘Individuals and interactions over processes and tools’

  1. Alan Dayley says:

    I like your last statement. I have found such word changes from “over” to something else to be helpful to understanding the original meaning in the Agile Manifesto.

    For example, it is instructive to replace “over” with “before.” An example application is if the teams discover that they are creating a higher number of bugs. We should look at how we as individuals are interacting to create bugs BEFORE we look at bug tracking processes and tools.

  2. Mike McLaughlin says:

    I like your use of the ‘before’ language. The example you gave is spot on.

  3. Matt Badgley says:

    Hey Mike, you might even say — the right tools will help collaborate better and teams shouldn’t be reliant on the tools for collaboration. Also, you made me laugh by making the daily stand-up an acronym — DSU. I thought you might have been talking about Delaware State University or Dayton State University.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>