So you’ve decided you want to do Agile, you’ve got yourself a white board and gone crazy buying all the colours of Post-Its and Sharpies you can find. You’re ready to go!

But who do you have in your team? And how can you make sure it all works?

A few things that I have found to be really important are:

  1. Keep the team small

You have your Agile team, and you have your stakeholders (customers, providers, ancillary skills). Your core team should be small – no more than 8 people ideally. Your stakeholders can be brought in as and when you need them.

In an ideal world you would have:

  • A business/product representative: someone who knows what the business needs out of this product and can prioritise the user stories.
  • A ‘doer’: in software, this is 1 or more developers. People who can actually make the Thing, whatever your Thing is. But this could be a designer, a photographer, an engineer etc.
  • An architect: in web, this is a user experience expert; in systems this is a solutions architect. Someone who understands the intricate details of how the product works and can think of all the problems you might encounter when you try to change something.
  • A tester: someone to make sure all the problems the architect came up with have been thought about and mitigated.

Now, one of those people could be your Agile scrum master/project manager, or you might need to add one of those.

And depending on what type of business you’re in, you might want to add a business analyst as well.

 

  1. Keep the team rigid

To get Agile truly up and running, you need the core team to be 100% focused on this work. ‘Oh the BA will be 75% yours, but 25% of their time will be for Dave’s project’. This won’t work, you can guarantee that when you need your BA they will be tied up with an urgent request for Dave.

shutterstock_151790957It’s hard to do, but you must dedicate your people 100% of their time to the Agile team and their project. In a more traditional matrix structure, this is quite a tricky thing to do as everyone is shared as necessary and covers many projects. However one of the core tenets of Agile is that you pick one thing, do it until it is finished and then move on to the next thing. So you can’t distract your team by allowing them to work on other projects.

That’s not to say they can’t help a colleague in another team with a problem, just that their personal focus must be on their Agile team.

 

  1. Collaboration

Easier said than done. Many people claim to collaborate however it’s not as simple as telling people. Instead, start by treating your core Agile team as a single unit.

Got a question for the architect? Have a huddle and let everyone hear the problem and the solution. Need to ask the business person how they think a particular feature should work? Have a huddle and let everyone hear the problem and the solution. Want to go through the testing results? Have a….well you see where this is going.

“If you can’t have a huddle, talk to the person you need then email/message round the notes from that conversation to the whole team”

 

If you can’t have a huddle, talk to the person you need then email/message round the notes from that conversation to the whole team.

By involving everyone in all conversations, you:

  • Ensure no information is missed between members of the team
  • After a while, time for collaboration is assumed and delivery work that is committed to becomes a bit smaller – however the quality is better and the speed is faster
  • Think through problems earlier, everyone is an expert in their own area and brings a different perspective to a situation. This is great for noticing risks earlier and mitigating them more quickly

 

  1. Remove risk

Do this by removing as many dependencies on other projects and teams that you can. A dependency is a risk. You can do this in many ways:

  • Install a devops culture where you are not passing work downstream and waiting for someone else to put it live – instead you are seeing everything through to the end as one team
  • Ensure your business rep can sign things off – then you are not completing work and waiting for someone who has no involvement in the detail to say yay or nay
  • Avoid the big bang approach – don’t bundle up a lot of work and try and get it all out to the market in one go for maximum effect. There are too many variables and dependencies, instead release quickly, frequently and where possible independently of other pieces of work.

 

  1. Be strong

Don’t falter on the rules above.

“Your Agile team won’t work if you don’t follow these rules”

 

It’s hard, when someone asks for a favour or a senior manager wants something done super quickly your first instinct is to try and squeeze that work in. But your Agile team won’t work if you don’t follow these rules. Otherwise your delivery speed will be at the pace of the busiest team member which will be slower than your potential productivity.

See more from Storm Fagan on Agile working:

 

Working practices