Scenes from an Agile Workplace

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

Do these statements sound familiar? That’s because they are clipped from the manifesto from which Agile practice arose.

Agile practices (or Scrum or Lean or whatever version of iterative development methodologies you happen to subscribe to) have become the norm of software organizations large and small. We now recognize the value of building applications incrementally, demonstrating some kind of progress at short, regular intervals along the way. At worst, you build software that has been more regularly scrutinized, tested, and won’t break as easily; at best, you’ve actually demonstrated useful functionality along the way.

Example: Some time ago, I worked in a team experimenting with “extreme programming” in an Agile development practice. In our particular practice, all members of the team worked in programming pairs, with one person on the keyboard and the other left to drive from the sideline. It was intense and exhausting. And in the programming “pit” things occasionally became testy. Nonetheless, the team agreed that if you could push through the interpersonal challenges, paired programming really did result in an excellent end product.

Which makes me wonder – should we adopt the Agile practice manifesto for not just development practices, but across all domains of the workplace? How would it change the way we work with each other?

Let’s take the ideas one by one.

Individuals and interactions over processes and tools

With data driving so much of what we do and understand about our working lives, we should be focused on measuring and understanding the effect of our interactions, rather than obsessing over the processes for governing our organizational bodies. Let’s A/B test the organization. Ignoring formal structures, what does the data show is effective?

Working software over comprehensive documentation

Likewise, though good documentation can be valuable for gaining historical perspective on what has come before, things are just moving too fast for that kind of academic exercise. Instead, we should be learning how to become regular consumers of real-time information about ourselves and the teams we work in. Work products are too ephemeral; relationships last.

Customer collaboration over contract negotiation

Just as we measure and test how we work with one another, what can we understand about our interactions with customers? This too can be measured, hypotheses tested, and interactions improved incrementally over time.

Responding to change over following a plan

Even more important is the idea that organizations should be prepared to be improving all the time, even after they have achieved relative success.

Notice that each of these ideas reinforces the last, with data informing how to make these incremental improvements in your organization over time. Sit back and look at the progress being made in your organization and imagine next steps. It may be time to start down the road (or are you on it already?) to becoming an Agile people organization.