Accomplishing More by Doing Less
The day began with a keynote by Marc Lesser on “Accomplishing More by Doing Less.” This session revisited some concepts from Monday’s talk, offering a clearer and more concise understanding. It was a valuable refresher.
A standout quote was: “Find the One who is not busy”—whether that’s in yourself, a higher power, or something else that resonates with you.
Scrum – Why It’s So Hard to Implement
Jens Ödegaard’s talk addressed the challenges of implementing Scrum. It was reassuring to see that my struggles were not unique. Key takeaways included:
- Organizations must be willing to abandon traditional management styles.
- Teams should support each other—if you can’t directly help, at least show solidarity (even if it means bringing coffee).
- Problems in Scrum often existed before but were unnoticed.
- A ScrumMaster should educate the organization about Scrum and remove impediments to help the team focus.
- A ScrumMaster has no formal authority but must coach people to commit.
- Daily scrums are team meetings, not reporting sessions for the ScrumMaster.
- Define “DONE” collaboratively with the team and Product Owner.
The presentation’s conclusion was much stronger than the beginning, which covered basic concepts. I would have liked more depth on the practical aspects.
eXtreme Programming in Practice
Neal Ford delivered a compelling session on eXtreme Programming (XP). Highlights included:
- XP’s success is attributed to various feedback loops operating on different timescales (minutes for pair programming, hours for unit tests, days for standups, etc.).
- Ford introduced “Quality of Service” as a term for non-functional requirements, which I found appealing.
- Instead of asking how long a task will take, gauge its complexity on a magnitude scale (1, 2, 4, 8, 16, etc.) relative to other tasks.
- “All models are wrong, but some are useful”—a humorous yet true statement.
- Track initial estimates, “sprint” estimates, and actual values.
- Stories are 0% complete until they are 100% done, with criteria expressed in business terms (user stories in the format: As [X] I want [Y] because [Z]).
- The “Truck Number” represents the number of people who must be absent (e.g., hit by a truck) before a project fails—aim for a number greater than 1.
- YAGNI (You Aren’t Gonna Need It)—avoid building frameworks on speculation; extract them from completed projects.
This session provided a great overview of XP and was thoroughly enjoyable. Neal’s slides are available for download here.
ÖreDev continues to impress, and the best parts are often the conversations between sessions.