Inception: How to Create a Good Agile Team

I wrote recently about what I think a good Agile team looks like here.

Therein I said a good Agile team team can answer two questions - To find out what those are go back and have a quick read.

If you did, you'll know that from this Coach's perspective, that's what an Agile team should be able to do, and what defines good practice. And all of the other practices and thinking kind of hang off those behaviours.

But if that's the end-state - the desired goal - how then do we get there? And, perhaps most importantly, regardless of when you join or inherit a team, how do you get started towards that goal?

Now, I hope everyone has noticed at this stage that I haven't singled out a Scrum Master or Product Owner or Customer Journey Manager or Release Train Manager and so on as the person who should be taking the question of how we create an Agile team on board.

Ownership of that responsibility is not just for one person. It's for everyone and anyone on the team. In fact, solidarity on that point underscores one of the key goals of Scrum / framework working: Progressing towards self-sufficiency.

In other words we're trying to work Scrum Masters and the like OUT of the team over time. Those roles are designed, to a degree, as a temporary convenience to remove blockers, help us organise, coax understanding of Agile ways of working, and so on.

And again, over the course of time, the team should then become the coach and trainer to other teams.

So, how do we begin?

Well, the first step in doing so goes by a few names (depending upon who you ask), but for our purposes today we'll call it an "Inception Meeting."

Typically, an Inception Meeting is designed to prepare a team for a new project or piece of work, or to realign an existing team towards a new goal, or to move them away from extreme cases of dysfunction or dissent.

And not unlike a Planning Meeting (Ceremony) in Scrum, it should lead to prioritised and actionable user stories (lightweight expressions of customer / end-user need - even if the end-user is the team itself), thereafter.

The steps for an Inception Meeting are not set in stone, but here's some guidelines for what should get done when you hold one - in this case to set an Agile team off on the right path:

• Facilitation - Get someone who knows about the business to facilitate the discussion. That avoids any one person on the team being seen as superior or as someone that everyone else is answering to.
• Context - Describe what brought the gathering of individuals who are in the room to where they are today at this meeting - Write out on a white board the project vision, objectives, key deliverables, epics, et al. Some of this stuff you night not know yet, and that's ok. Remember that every project begins at its greatest moment of stupidity. Trying to know and plan everything at that stage is like watching a one-legged arse-kicking contest - there's a lot of falling down! As a team you're there to come up with the answers as you go, and to identify value iteratively as you produce working "stuff" in small pieces. Sometimes it's no bad thing to back up all the way to an overview of the company's Agile journey to date. Don't assume everyone knows the direction of travel. Assuming things are absolute or immutable is almost always bad practice. Leave the door open for change
• Stakeholders / End-Users - Bring them. It might help to clarify where the goals for the project are unclear and where additional work needs to be done to refine and agree on the shared goals before the team can start working. Clarity is as wonderful as it is elusive. Learn first instead of labouring on work that will later be thrown away.
• Social Contract - I've also written many times about the problems a lack of clarity causes in teams, ranging from mild dysfunction to outright rebellion. One of the ways of avoiding this problem (as much as is realistically possible - there will always be moments of poor clarity) is to have the team create a social contract. Each team member, or you might work in pairs, writes down what they deem is important as part of social contract or commitment to the team and all of its members. For instance, "The courage to be honest" and "Always respecting team members' points of view" and "Asking first to clarify who's doing what" and "Asking for help without fear of being perceived negatively" and "Sharing work without worrying about your role being subsumed." It doesn't need to be biblically long. I've seen them as short as four Post-It note statements and as numerous as about 25 or 30. And once they're all up on the white board have every team come up and sign the board at the bottom - like a declaration. This picture or piece or white board should be visible in the main working area (if) where you gather regularly.
• Backlog - You now know your goals and objectives as much as possible at this stage. You now need to split these into user stories and, if you have some end-users in the room, try and get them to help you prioritise which ones might be deemed to be the most valuable to be worked on first.

Inceptions are nice way to start off team working or reset perspective and agree common vision, support and understanding. It can take an hour or two or it can take a day. A good guideline is half a day.

And if you think that sounds like a long time to commit to this piece of work, think about the time wasted on addressing dysfunction and working on the wrong things. The latter is exponentially more time-consuming.

Come together. It's the first step towards building a good Agile team.

Ed Emerson, Agile Coach