If “Agile” means moving with quick, easy grace.
“Being Agile” as an IT team might mean:

Being able to easily and frequently release useful and quality software.

If that definition is true, so is the following:

• Organizing yourselves in a team so you can easily handle changes
• Being ready for and responding to changes
• Maximizing the work-not-done & the outcome

It’s quite a challenge and in this post I’d like to share some ideas.

Organizing yourselves in a team so you can handle changes

At www.weeronline.nl we’re constantly trying to optimize the way we work together in a team.
The most helpful insight is usually the goal we strive to, and to adjust our workflows to get to that goal.
We try to focus. Defining sprint names and goals. Print them, put them on the wall. Be as transparent as possible on all aspects of our work and the team members themselves.

Our team (14) is responsible for multiple products. The (sub)productteams are (almost) cross functional.
We adhoc add people for a sprint or 2, if the team thinks the outcome needs a specialist. This can be a db-engineer or a sales representative.
This requires agility from everyone. For some team members it’s harder to constantly change, then for others.
We’ve not yet fully optimized this.

Being ready for and responding to changes

To be ready for changes, we need to make sure that our workflow is optimized for change.

When creating a (part of) the product, our engineers think in modules. They have dependancies on top of mind and their goal is to make them disappear, to minimize potential issues when changes come in.

Also, by automated testing, easy deployment streets and using managed AWS we will make sure that we can focus on and release the requested changes. The amount of trust and focus in the team went up, because they’re no longer worrying about the potential conflicts they might have created.

Maximizing the work-not-done & the outcome

By being very clear on roles, adapting the Governance meetings from Holocracy, we try to be able to challenge each other as much as possible to maximize the work-not-done.

In our scrum proces, the PO is about the WhatWhy. It should be one word: only a What, or a Why, is not enabling the team to define the best How. We’re constantly talking, checking, negotiating the requirements from the PO to get a feature released the easiest way (the How) while the Why and What are still valid.

The open mindset that the amount of uncertainty about the stories and specifications requires, is a challenge for some team members.
As a scrum master I’m constantly trying to get stories as clear on the what and why, without filling to much how. The team should fill the How during refinement, but they need to be supplied with the best Why & What.

So, does our team have an agile attitude?

I think that we’re quite Agile: we’re able to release new quality software and getting organized to do so more easily.
We’re learning though.
As we should, because change will come and we should be prepared.

Please let me know what “Being Agile” means for you in the comments!