I've done a lot of work with Agile development teams in the past few years. I like the Agile methodology. It makes a lot of sense when building software applications and, especially, when everybody is working on only one product for an extended period of time.
In every Agile team I've been in, though, there's always this talk about how working in Agile is being a sport-like team. The project management methodology is full of sports terms like "sprint" and "scrum".
Great teams move like a single unit, everybody knowing their position and their teammates' strengths and weaknesses. This is never instantaneous. Teams have to work together and train together for weeks, months or years before they develop this mutual understanding and exist as a whole.
But sports teams have something else, as well. They have established rules of the game. Preëxisting constraints exist and are known throughout the training period and worked within, long before the team reaches a competition level.
Rules of a game are like contracts. They exist to protect participants, ensure that everybody is treated fairly and, most importantly, they remove assumptions.
Assumptions are a killer. Assumptions will be the reason any team or project falls down. My job in the User Experience field is about identifying assumptions, exposing them and dealing with them in an open and honest manner. I'm like a lawyer for interaction design. I have to either remove the assumption or make everyone aware of it.
Establishing rules is not as much fun as designing interactions or building code that produces kick-arse animations through parallax scrolling. In a world where most people don't even like to try to use the instructions that come with Ikea furniture, convincing people of the necessity for rules and their adherence is almost impossible.
Through the past few weeks I have spoken around town about ignorance and the role it plays in being a better designer and developer. This is not just a talk about working with clients, though. It's also about how we work with each other.
In a team, players have clearly defined roles. When I put a team together I am constantly looking at the roles that we have covered, if there's any doubling up and, more importantly, if there are any holes.
Not everybody in charge of a team will do that, and that's fine. But we can define assumptions in that case. The assumptions by the person putting the team together might look like this:
- We have a job to do with a defined goal.
- We have a sufficient team of dedicated and skilled people to achieve that goal.
- These dedicated and skilled people will communicate amongst themselves to work out how that goal will be achieved.
Assumptions are often exactly like this: a kind of pyramid in which one builds on the next. Identifying problems often means excavating through assumptions until we recognise the source. Excavation takes a lot more effort than building.
It's much easier to remove assumptions before they become problems. It's much easier to establish the rules of the game up front, before strapping on the special shoes and heading onto the playing area with the required equipment. (Note: It's very difficult to create a sports metaphor while also trying to be code-agnostic.)
Earlier I said that rules of a game are like contracts. There's another way this is true. They need to begin with negotiations. New players bring new skills and different experiences. The team needs time to negotiate through these experiences and ways of working or playing. It takes time to find the common ground.
It's okay for this to happen on the field if the stakes are low. But if there's money, livelihoods, share prices or mutual respect on the line, then there better be a lot of pregame honesty, awareness and practice. There must be a way to recognise, acknowledge and overcome assumptions.
Otherwise your whole team metaphor gets thrown out the window and all you have are a bunch of people who didn't want to write a requirements document.