Day 2 of the class went right into it and had a lot of good, hands-on excercises. Here are some notes from the day:
Team
- Includes everyone required to deliver the “slice of the pie” (the functionality for the sprint)
- Extended teams are teams that you have to interface with to deliver your software. Peripheral teams may be doing waterfall and include vendor and/or teams external to the company.
- The core team should all be co-located, and shouldn’t be interrupted during a sprint
- All teams go through the forming, storming, norming, and performing phase… even teams built with experienced scrum members. Team dynamics are always different. Mark (the trainer) wanted to stress that there is an additional phase here called “Adjourning.” This implies that you have to let go of your previous team if it’s not bringing value. Don’t do things a certain way just because “that’s how we did it last time.”
- Good Scrum Coaches address problems by holding up a mirror rather than a stick. Get the team talking and let them come to a solution. Good coaches know how to set things up to get them talking and then shutup.
- Recommended books: Project Retrospectives by Norman Kerth, and Agile Retrospectives by Esther Derby, Diana Larsen, and Ken Schwaber.
- Role of Managers often comes into question in Scrum. Are they pigs or chickens?
- Most of the time chickens
- sometimes the product owner / customer, but depends on the project
- Managers still have forsight of team impediments, so they can be very valuable.
- Managers help the ScrumMaster remove impediments to the team
- Scrum scales via Scrum of Scrums
- 1–2 Members from each team are part of Scrum of Scrums. Important to get the right people in the room (need problem solvers and cross-functional SMEs)
- goal is to re-sync team efforts, share impediments (find common ones)
- helpful to have someone of VP level present so that common impediments can be taken care of quickly
- “Distributed teams are hard. Period. Scrum doesn’t make them any easier.”
- Distributed Teams
- NEVER as productive as co-located teams.
- 90% of communication is non-verbal so stand-ups over the phone are hard
- Effective distributed teams START co-located, then distribute.
- Spend the investment to bring people together or “accept it and have bad teams.”
- The best distributed Scrum teams share a product backlog and task list (via tools or Spreadsheet) so that they still feel part of the same team.
- User stories
- Stories are not contracts.
- Rather they are a placeholder for future conversation
- Stories are not Requirements! Requirements are meant for defined system behavior for contractual purposes and not business-user friendly. User strories are meant so that business users understand them.
- INVEST in good user stories that are
- Independent
- Negotiable
- Valuable
- Estimatable
- Small
- Testable
- Stories can be large at first (called Epics) then are broken down into (Themes), then finally into stories. Epics or themes never make it into the sprint, so break them down as soon as you can.
- Purpose of stories: (3 C’s)
- Card
- Conversation
- Confirmation
- Estimating
- Use story points (or gummi bears… whatever) rather than hours. Hours decay. You don’t want to have to re-estimate because your initial estimates were wrong. If you estimate that you can accomplish 24 story points and you only get 18, then you can only count on getting 18 the next sprint. If you estimate a task at 4 hours and it takes 8, then what about the other 4 hours tasks on the board?
- Planning accuracy
- 20% of the efforts gives you 80% of the benefit
- Planning beyond that yields little return
- “Plans are useless. Planning is everything.” – Eisenhower.
The course was AWESOME and I strongly encourage others to take the course if you are interested in agile/scrum.
Afterwards we took Mark Pushinsky and Kert Peterson out to dinner and shared some stories and laughs. I hope to see these guys again in the future.
(oh yeah, and Jimmy and I worked on something super secretive during our free time on this trip… more on that later on)