This was our welcome to 2013 meeting. Apologies for the lack of blog posts lately. Our meetings have been going on strong but I need to streamline the blogging process.

Uploading photos of notes is great in concept but I have struck quite a few technical headaches I won’t bore you with, so here are the notes:

What Are 20 Questions I Can Ask to See if Someone is a Scrum Expert

1. Describe scrum roles
2. Describe an iteration – what happens, what ceremonies when
3. Where is Scrum defined? (Do they know about the Scrum Guide?)
4. In scrum who is responsible for (be careful of text book answers here, roles here need to be carefully constructed)
   1. Database design
   2. Architecture
5. Who prioritises the work?
6. When do you do retrospectives?
7. What real world modifications to scrum have you used?
8. What definitions of done have you used?
9. What is the best day of the week to start the sprint?
10. How do you handle refactoring?
11. How do you handle design and architecture in scrum?
12. How do you handle risk in scrum? (Interesting area – my Scrum Trainer proclaimed he had ‘never done risk management in his life’, I have the deepest respect for him so my interpretation of that is that he did do it, he just didn’t call it that and didn’t use any traditional approaches to manage it)

We went off then into an interesting discussion on S.O.D or “Sign Posts of Danger”. One attendee has  a long list of project danger signposts and shares these with the team at kick offs. They then add to it and all agree that it is everyone’s responsibility to highlight when you see any of these.

How to Combine Lean Startup with Scrum

• be careful of expectations – the outcome of 1 sprint won’t be a ‘finished product’
• need to balance generating a backlog / estimate with focusing early sprints on learning and delivering basic way to solve the problem

Creating a Culture that Embraces Failure

• Every project should have a business case and a business owner that signs up and will be accountable for that – “agile or not”
• ie failure to do this is not a failure that should be tolerated easily

And in relation to combining Scrum and lean startup and failure:

• at the end of each sprint – ask can the business owner sign up to benefits and can the dev team sign up to estimate and do we know what the next MVP is

We had lots more discussion on failure, but I didn’t keep too many notes. Some key ideas:

• this culture must be supported from the top of the organisation
• it’s ok to fail just do it early and ensure everyone has the same picture of why it failed and what you plan to do to stop that happening next time – value the learning