Peter Provost and Alan Ridlehoover from the MS P&P team talked Agile and how to introduce it while sharing their experiences in doing that at MS. The stuff in italics are some thoughts of mine pertaining to my projects related to the stuff Peter and Alan were presenting on. The notes are kind of rough – but stuff in Tech Ed 2006 comes pretty fast and so in order to keep up I am going to pass it along as fast as I realistically can.
Communication is King – the most important part of that is to Listen – Listen, Listen, Listen
Real-Time code reviews/Pair Programming
Get help when you need it – if you are blocked for 15 minutes on a problem (and even less if you are pair programming and blocked) go ask someone – get some help – communicate – a corollary (I think that is the right word) to that is that you have to be available to members on your team to provide help when needed
Peter Provost and Alan Ridlehoover talked about how they evolved their work at MS. They started out by booking a conference room for 3 months. After the admins complained and said they couldn’t do that – they each took a day and booked the room, after the admins complained again they worked through management and got things changed. They gave up their offices at MS (everyone at MS gets an Office) to get a team room where they could work
This made me wonder if we as a distributed team should push management to lets us get together quarterly. Perhaps two meetings a year with customers and customer focused (like our F2F in May) and then two a year that are dev focused where we get together and code together (and in this case perhaps we go away from home all of us and get the team together – so that we are at dinner together, etc… – strengthening our team bonds, etc…)
Give the team time to gel – don’t expect miracles in the 1st and 2nd iterations
Encourage continuous education
Avoid knowledge silos – the joke around this was that this was the “Hit by the bus” now called “Winning the lottery” (more politically correct) concept.
Get a coach or mentor – a coach will help keep you honest – gives you a different and perhaps more objective perspective.
We currently don’t have a coach – perhaps we should use the consulting money that potentially we might have to bring a coach in to help us?
Encourage questions – a team should question each other – for understanding and to make sure that we are doing the right things – it is okay to challenge people (although you should make sure you do this logically – I have worked with people that challenged everything and you quickly learned that they were just being difficult and rarely did their challenging help anything).
I would go even farther and say that if no one says anything they either don’t care, didn’t understand, weren’t listening, etc…
Work on the most important things first
Stack rank your work by its importance to the customer
Reevaluate the stack and the plan frequently
If a developer gives you an estimate longer than 3 days he is lying – he doesn’t know. Provost said that he was a terrible estimator even as long as he has been doing software development
Don’t, Don’t, Don’t Gold Plate – Don’t do what the customer hasn’t asked for
TDD, Refactoring, continuous integration, and emergent design
When you need to explain the refactoring cost to a user – don’t use refactoring with the customers – use soft technical language like – it will take me a couple of days to make room for it and a couple of days to add the feature
Came back to pair programming – code reviews, code reviews, code reviews
Reward individuals for behaviors that are team focused – how do we do this?? Represents a culture shift and while not a core Agile practice – as Agile methods proliferates this may come as a natural shift as the org values the team over the individual
Don’t encourage rock stars – encourage team players (we want everyone to be rock stars) – no cowboy coders
Remove roadblocks to success – that can mean a lot of things – he emphasized removing those who won’t play as a team. The slide initially said – fire those who won’t play along.
People work on features, they don’t own them – everyone does
Stick with it there will be hard – Constructive Confrontation is key – we need to be open and honest