Accomplishing more by doing less
This day started with Marc Lesser giving a keynote on “Accomplishing more by doing less”. This was a short overview of the day that I attended on Monday, so it was some of the same, but also gave a crisper understanding of the subject. It was great to get a repetition for me.
Great quote of the day; Find “the One who are not busy”. In yourself, or God or whatever you read into it. I know what I do…
Scrum – why it’s so hard to implement
Jens Ödegaard gave this talk and it was one of those: “you’re not gonna get any silver bullets”, but rather a run through the challenges you face implementing Scrum. It was quite nice see that I wasn’t alone in my experiences. Here is some quotes that stuck:
- We want organizations that dare to let go of the old way of management.
- The team is in this together – if you cannot do anything to help you can always show that you want it solved. If by no other means – bring coffee.
- We didn’t have all these problems before Scrum. Well no. You had – but you didn’t see them.
- A ScrumMaster should explain scrum to the rest of the organization.
- A ScrumMaster is the teams best friend, removing impediments to help them focus on the task at hand.
- A ScrumMaster has not authority. You have to coach people to commitment.
- The daily scrum is a team meeting, not reporting to the Scrum Master. Scrum Master is not required to be there but rather make sure to be there
- Define DONE together with the team and the Product Owner.
The end of the presentation was much better than the start which was very basic. It would have love to stayed longer on the “What to do?”-slide.
OK – that was not good. On to the next
eXtreme programming in practice
This session is given by Neal Ford and he’s a good presenter from what I understand.
- One of the things he mentioned is that XP works well because there are built on a series of feedback-loops on different time scales (minutes – pair programming, hours – unit tests, days – standups, weeks – iteration etc.)
- He posed a new name for Non-functional requirements; Quality of Service. I like that.
- Don’t ask how long will a task will take. Rather gauge complexity in a magnitude scale (1, 2, 4, 8, 16 etc.). And do it relative the other stories in the system
- “All models are wrong, but some are useful” – true and funny.
- Track initial estimate, “sprint” estimates (beginning of iteration) and actual values.
- Every story is 0% until its 100% done. These criterias are expressed in business terms, hence user stories (As [X] I want [Y] because [Z])
- Truck number – the number of people that you cannot have hit by a truck. This number should be greater than 1 or your in trouble… Funny
- YAGNI – Don’t build frameworks (on speculation). It’s better to extract a framework from a finished project.
This was a great presentation, also basic overview. On XP this time – I enjoyed that very much. Thank you Neal! The slides are for download here
This is a great conference and as always the best parts are in between sessions, talking to others.