Scrum and XP from the Trenches by Henrik Kniberg

Rating: Very interesting.

I've read this one initially at the end of 2006. Lots of interesting,
real-life observations.

Scrum Concepts:

• velocity (aka actual velocity) - the sum of all initial estimates of story points, for stories completed in one sprint,
• estimated velocity -  the sum of all initial estimates of story points, for all stories planned for one sprint,
• external vs internal quality (visible to the user or not)
• yesterday's weather - look back several sprints and average out the estimates
• taskboard - index cards for stories, and post-it notes for tasks on a wall, grouped into: not checked out (stories and tasks), checked out (tasks), done (stories and tasks), unplanned items, next (stories), aka: sprint goal, burndown chart
• seat the team together for audibility, visibility, isolation:  
• audibility - any team member should be able to talk to any other team member without shouting or leaving his/her desk
• visibility - any team member should be able to see any other team member and the taskboard without leaving his/her desk
• isolation - the team does not disturb anyone else, and nobody disturbs the team
• "knowledge bridge" person - a person attending all retrospectives
• insert a lab day between sprints - page 74
• acceptance thresholds - for release planning and fixed price contracts
• all-hands pulse meeting - weekly, 15 minutes, the teams share information about what they are doing
• the firefighting team - a temporary team that protects scrum teams from interruptions by fixing bugs, or finishing old business

Code Branching Tips:
 * trunk should always build
 * tag each release
 * when in doubt, do not branch
 * synchronize often

XP Concepts:
 * pair programming
 * test-driven development
 * incremental design
 * continuous integration
 * collective code ownership
 * informative workspace
 * coding standard
 * sustainable pace / energized work


Interesting observations:

• for keeping product backlog, the product owners preferred shared Excel file to a bug tracking system, because the Excel file required fewer clicks
• internal quality should not be negotiable
• 3 week sprints worked best
• a meaningful sprint goal is important to keep the team focused
• sprint backlog is initially defined as a list of stories from product backlog, not tasks; later in chapter 6, the associated tasks are shown on the taskboard
• product backlog has the following pieces of information: ID, name, importance, initial estimate, how to demo, and notes - all are printed on cards for the planning meeting
• tasks estimated in story points (ideal days), down to 0.5
• demo of a technical story does not have to be a demo on a computer, it can be a piece of paper showing test results - page 66
• code review is an OK alternative to pair programming
• most teams do not include acceptance testing in the sprint, because it cannot be time-boxed

Quotes:

"TDD is hard, but trying to do TDD on a code base that wasn't built using TDD from start... that's really hard! [...] Lesson learned: If you are stuck with having to do manual regression testing, and want to automate this away, don't (unless it is really easy). Instead, build stuff that makes manual regression testing easier. Then consider automating the actual testing."

Tools/frameworks mentioned in context of TDD:
jUnit, httpUnit, TestNG, Selenium, HSQLDB, Cobertura, Spring

Agile Project Management with Scrum by Ken Schwaber

Rating: Intended for Scrum masters.

 

Quick comments:
A bit academic. Dedicated to Scrum masters, not developers. For Scrum essentials go to Appendix A: Rules.

 

:-) Funny bits:

 

"It is possible to have simple software requirements. A single customer who is the only person who will use the system can spend enough time with the developer that the two can agree exactly what to build. Assuming that this customer '''dies immediately [...]'''"

 

"You notice that the commissioner gets increasingly agitated during your presentation, tapping his feet, '''spitting at the floor''', and uttering muffled expletives. He appears to be very unhappy." - page 78.

 

Concepts:
empirical process control (visibility, inspection, adaptation) vs defined process control, stakeholders, complexity assessment graph, scrum skeleton, product backlog (sprint stories [0.5-n days]), Scrum
roles (product owner, the team, Scrum master), sprint, planning meeting, sprint backlog (sprint tasks [4-16 hours]), daily Scrum, sprint review meeting, sprint retrospective meeting, burn-down chart, adjustment (complexity) factor, the art of the possible, self-organizing team, time-boxing, incremental delivery, sashimi,
sprint goal, changes report, product backlog burndown report, suboptimal measurement, scaled project, daily scrum of scrums, staging.

 

Bottom line for us, the developers:
Scrum is about letting the team estimate the work (stories) initially, divide them into tasks, assign within the team, estimate work left to do every day, and present results every 30 calendar days (sprint). Scrum is about product owners defining, prioritizing, and providing feedback on the work. Scrum allows product owners to see in great detail how the work is progressing daily, and change course if necessary.

 

Quotes:

 

"The process of developing functionality includes: analysis, design, coding, testing and documentation."

 

"During this training, I emphasized that '''Scrum Masters have no authority over the development teams'''; they are present only to ensure that the Scrum process is adhered to and that the teams' needs are met." - page 103.

 

Interesting observations/Criticism:

• testers are not part of the team at MegaBank, QA starts at the end of every sprint - page 72, however, in other cases, they are part of the team
• there is a special, 2 week, release sprint at MegaEnergy - page 91
• the definitions and index do not include velocity which is an important scrum concept