That’s our Sunday morning Lean Coffee practice. Here’s where we landed after a good 1.5-ish hours of structured-and-friendly conversation.
- You must be very familiar with the SCRUM Guide, and especially the “Why” behind each practice – so that you can address real questions about when you’ll recommend a practice and when you’ll recommend evolving past it
- Should be very comfortable with trying new things AS EXPERIMENTS
- Must avoid “always pitying the SCRUM team” at the expense of the overall business goals, or else business will hamstring your influence and bypass your role
- Relies heavily on Situational Leadership abilities
- Starts with CI, graduate to Continuous Learning
On the subject of what’s changed and what is changing
- According to our discussion of Crossing the Chasm, once those beyond the chasm start adopting, then rather than chasing the downward slope, you should chase a new curve starting from the other side of the chasm
- We’re seeing signs that other non-software disciplines are adopting Agile practices eg. Marketing functions, DevOps
- Perhaps we’re merely waiting for the rest of the org to catch up to those of us who are post-Agile and delivering continuously
- The VUCA model (Volatility, Uncertainty, Complexity, Ambiguity) made it into a Harvard Business Review article
- Neurodiversity is getting broader consciousness
On the subject of creating success as a Scrum Master
- The basic SM is a “boundary manager”
- They’re there not only to help the team “learn to be a team” and more to help the team “learn how to be Agile as a team”
- They’re there to work with the team and enable them to determine what process solutions to try, rather than dictate or even “guide” the team to specific outcomes
- Tip: should be very familiar with the Agile Fluency model
- When interviewing for a SM role, an insightful question is to ask what are the inputs and outputs of the engineering team?
- Geoff Watts published an article asking What kind of support a Scrum Master would need?
On the subject of no estimates
- Analogy of a cook: asking for precise estimates is like asking them to cook a dinner with a menu they’ve never cooked before
- Analogy of car mechanic: they can only give predictable, tight estimated of when the repair will be completed for operations they’ve already done before (enough time to have codified the standard timeframe) and with mechanics who are highly experienced
- Meetup (as in the collection of fluid communities) is like a grand ongoing Un-Conference – people announcing a topic they’d like to talk about, those who wish to attend come, people obeying the law of two feet as the meetup’s theme no longer keep their attention
- Check out Rachel Davies’ Agile Coaching book
- There’s growing insight that SAFe can find better flow mechanics across the portfolio if it uses Kanban rather than SCRUM – but that a prerequisite is that the teams must already have in place high-quality technical practices (eg. low big output, continuous integration, short distance from idea to value) and functioning teams before Kanban at scale will create consistent results
- Book: check out the free mini-book on Scrumban by Henrik Kniberg
See you there next time (if you’re lucky).