Recently, I was approached to classify what I felt were the “Must Haves” of any agile team and I was left stunned and in a stupor of just how to communicate such a thing. Looking back at it I have finally formed what I think I should have said.
Get a list of all the things the customer wants, have the people who will be doing the work estimate it, get it prioritized by the customer, and then start doing small (2-4week) iterations from that list with small crossfunctional (tester, business, programmer, security, hardware, etc)teams (6-8 people) that have all the expertise required to do the work. Demand that they report back with potentially shippable software as the primary measurement of success and require that they constantly reflect and improve themselves. Lastly and most importantly, give them total control of how they do their work, remove any roadblocks/impediments they might have and keep them protected from any outside interruptions.
Now in regards to the constantly improving I found these dials useful for upping engineering skills with your team:
For those not familiar with extreme programming, you may want to read up here.
This information was brought to me by Martin Olsen, one of the thought leaders here in Kansas City who runs Agile KC users group.
Martin uses what he calls “Setting the dials” and basically this comes from extreme programming’s practices.
Get a BIG piece of white paper board. Write on it down the left side these things:
Then all the way across the top write 1,2,3,4,5,6,78,9,10 spanning the width of the board.
Now draw lanes on the board for each of the above items.
These are our dials.
Have the team reflect about their sprint and shade in with a red marker where they think they are in each of the categories.
For example, the team may decide that they are a 5 on the planning game. Have them talk about why they think they are a 5. If people say they’re way higher, ask them why. Have them justify why they are so high. If they say they are way lower, ask them why… again have them justify why they are so high. Don’t fill it in until everyone agrees where they are…
AND
Then agrees to where they are going to get by next sprint. Have them write that on the big board also by drawing a red outline around the area they intend to reach.
Here’s a pretty rough example: (the team thinks they are a 5 and want to be a 6 after this next sprint)
Now the simplicity in this is the big chart that makes the team accountable to what they say and how big and in everyone’s face it is. Of course, management has to stand behind something like this because people are going to refuse to participate. Especially if they’ve been able to get out of participating in the past.
Martin said in fact, take care of any squeaky wheels right away by removing them from the room and have a discussion with them separately. His comment was that it’s simply not acceptable for people to sit and ‘stagnate’ in the way they do their work, everyone should be improving and this is a focused way to improve engineering skills as well as collaboration.
Your business unit that is “On the team” should be in this retrospective as well. Everyone should be accountable in the “Whole team” not just programmers and testers for example.