After reading a comment on Joshua Kerievsky’s excellent post on Modern Agile I started replying to a comment, and ended up here instead. What I wanted to yot down (as that helps learning and thinking straight (event at 4 in the night, sustainable hugh?)), was the key things I press on when I “teach Scrum” (not the PSD-class).
Here’s an incomplete list, which only makes sense to you if you understand agile and know Scrum fairly well.
- It all comes down to “value”.
- Scrum is based on two things: empiricism and self-organization.
- Both of these foundations require trust (and courage, respect, openness, focus and commitment (to bring out trust and putting empiricism to work)).
- Scrum Master works relentlessly on building trust if it’s lacking. Full time role discussion. “Why not introduce a PM again?” Post-it Janitor vs Agile Coach.
- The Dev Team never commits to scope, only to quality (Definition of Done, DoD).
- There’s only one way to fail a sprint - by not respecting transparency (which breaks any attempt at empiricism) by breaking DoD, and/or by not listening (hopefully adapting) from what you’ve discovered/learned (yes, there’s a off by one-error here :-)
- PO drives vision and purpose - Dev Team has access to stakeholders to self-organize on moving towards the vision and purpose.
- Business models drives/limits trust levels, which impacts how to deal with the uncertainty of software development. Is the organization open for closer collaboration, honesty and openness? Why not? What can you do, art of the possible? #NoEstimates
- Burn up and forecasting, count, no commitment. Need to make promises? See above.
- You don’t get to “value” unless you deploy.
- Scrum is a small framework that suggests feedback loops, to help you inspect-adapt: ie put empiricism to work! You need to do the hard work of listening to it and acting on it. If you’re not open to that, then you’re not looking for agility and then why are you in a Scrum class?
- Scrum is not a silver bullet.
- Is velocity important? (see below)
- It’s all about “value”.
Being a PSD trainer I of course do talk about #TechnicalExcellence and how that impacts agility.
Most of the people that show up in my classes are:
- from IT, and
- their organizations are no way near opening up their business models, or business people’s thinking, so yes, we go into thin slicing, estimating in points, and other stuff you can do to make life less sucky while also trying to empirically show and explain why it’s all a guessing game anyway.
Some classes are filled with waterfallistas, others with people that have come to get help to think outside their dysfunctional Scrum boxes. “I heard I could come here and challenge everything I learned from my certification class 5 years back.” I enjoy both, in different ways.
So I adapt, and hope to shake things up “just enough” for them to come back with tangiable experiments to try out, new thinking - ideas and principles - to help guide their efforts towards their goals, whatever they are. I can’t possibly tell what kind of level of agility is right for them right now, they need to figure it out. If they’re on a Shu-level (or 1,2,3 in Dreyfus’ model), I present some mechanics (training wheels) with proper understanding of what the events/roles/etc are there for. “Purpose is important, not mechanics - remember that empiricism trumps all!” together with some questioning on “do you really need this” around just about everything. (If they can’t answer, we usually do one or more exercises to dive deeper, until they get the point of it and can explain it to their peers in class - be it a role, rule, event or artifact, agile manifesto value or principle.)
You may argue that there are conflicts here. Yes there is. Although Scrum is a small framework that fits on 16 pages, the “playbook” should be unique and context-adapted (and change as the context changes). As such, in order to be adaptive to fit different contexts, there are conflicting statements and not a perfect description (like is what a methodolgy tries to give).
Example: If PO drives vision, how can the backlog be filled with really thinly sliced stories - wouldn’t that be really far from “vision statements”? Yes, of course. The PO is accountable for maximizing value of the product and work, and can happily let anyone manage work in any way they see fit. The PO is accountable to the maximizing of value, not micromanaging some throw away artifact, ie the temporary guesswork that PBIs and backlog is. How you do this, is context dependant.
Now, sleep.