7 SCRUM insights from Jeff Sutherland and Jens Ostergardt

Jeff Sutherland, the inventor of SCRUM and Jens Ostergardt, the 1st SCRUMMASTER, were keynote speakers at the APN in Auckland last night.

Here are a couple of salient points I took from the talk:

• Jeff was a fighter pilot in Vietnam (Sydney 1967) and flew over 100 missions! This along with Jeff's subsequent experience in medical sciences seems to form the backdrop to the pre-scrum thinking. Jeff said he came up with a process that is in a constant state of response to impediments.
• Jeff appears to be a scientist at heart with an evidence based way of getting his point accross. One of the stats he mentioned was that an average 63% of features change on development projects... I'm still digging for the reference for this... will post it shortly.
• When coaching senior management teams Jeff seemd to emphasize the need to "surface impediments". He cited a great example of a Danish company that was level 5 on CMMI with excellent control over processes. This was used as the test bed for determining the productivity differences between SCRUM & Waterfall... needless to say SCRUM kicked ass ;-)
• Read the MIT iRobot story. I loved this story as it really brought home the need to establish the learning process with simple rules... The world is the database... simple rules give rise to sophisticated behaviours!!!
• Jens gave some valued advice for new ScrumMasters:

1. Don't get fired,
2. Resist the urge to 'help' the team
3. Don't use a SCRUM tool at first! (Help the team find it's feet (low tech) before introducing tools.)

• Jeff seems to enjoy applying Root cause analysis for SCRUM issues... Let the data reveal the causes. He gave one of his Polish companies as an example. The company in question had been advised to implement integration testing... this was ignored and later identified as a root cause of the ensuing spate of iteration failures.
• Lack of integration testing was identified as a major impediment to getting to DONE!

Hope you enjoyed this installment... If you attended the event too please feel free to add your own take on the talk!

This event was arranged by Edwin Dando from Clarus Consulting in Christchurch. A real win for the New Zealand Agile community I'd say!!

Handling 3rd party vendors on SCRUM projects

A friend of mine recently asked me what the best way was to manage a 3rd party vendor on a SCRUM project. (SCRUM is an Agile Methodology for those of you who don't know)

Here's the advice I gave him:

Get the vendor relationship off to a healthy start:

• Make sure there's an open, honest and safe channel for the vendor to communicate with you.
• Be as specific as possible with what you require from them. Try and be results focused and not activity focused. Here's a great article by Marc McDonald on the merits of results versus activity management.
• Urge vendors to give commitments that you can rely on and not commitments that you may want to hear.
• As a rule of thumb question the assumptions behind an estimate and not the estimate itself. This way your vendor is encouraged to use their expertise while protecting their self esteem (improves their perception of safety).
• Try and use the language of 'confidence' when considering estimates. For example, "The vendor is very confident in a 5 day delivery" or "The vendor is not very confident in a 5 day delivery due to an issue with XYZ". This way you're less likely to set unrealistic expectations with stakeholders.
• Ask your vendors to escalate potential issues early and often... better to handle things early & cheap than late & expensive. (See my previous blog article on this)
• Work hard to empower your vendor... especially since their performance has direct impact on your reputation. In other words, your reputation will very likely take a knock if they flounder.
• Prioritise the deliverables you're expecting as much as possible. Be clear about Must Haves.
• Compromise on Scope not Quality where possible. Don't make them deliver things if it can't be done properly. For example if you're time pressured, negotiate with scope.

Integrating vendor deliverables with your SCRUM project:

• Create a user story card for their deliverable and place it in the product backlog.
• When the iteration arrives be sure to schedule integration and testing tasks in the sprint backlog to ensure the vendor deliverables are truly DONE by the end of the iteration.
• For planning poker, Limit the task estimates to just those your team will need to carry out. I.e. exclude any work your vendor will do as this will distort your view of velocity (... thanks Vasco)
• Invite your vendor along to attend the sprint planning meeting for the relevant iteration. A public commitment to the team to meet a deadline is always more powerful than a contract ;-)
• Be sure to regularly ask vendors how they are tracking and to confirm their delivery estimates (weekly should be ok).
• If there are dependancies on the vendor's work be sure to assess the impact of delays. Communicate the potential impacts to stakeholders early.
• The vendor should also attend the sprint review to see how their deliverable has been integrated and to clarify anything should the need arise.
• It's also ideal to have your vendors attend the relevant sprint retrospective to get their input.