Tales from the Scrum Bowl
Servant-Leadership in the Dual Role of ScrumMaster and Developer
An anecdote by Rob Friesel @founddrama
Rob Friesel
* played a bunch of diff roles at DDC over the years
* currently Sr. UI Developer
* originates 2001; Kent Beck, Bob Martin, Martin Fowler
* ...Jeff Sutherland
* emphasize: value on the left *over* the right
* (the right still has value, but isn't *as* valuable)
The many flavors...
* and others
* variations on these
* "covariates" (e.g., XP + Scrum)
* "just another way of doing business"
* j/k (sort of)
Agile at Dealer.com
* tell the story of Agile at DDC
* a little of what "They" told us
* and what it's been like "on the ground"
----
* after dabbling w/ "Agile" on a small scale for a couple years...
* ...co. decides to go all-in
* w/ Scrum
* and/but/so Scrum works OK w/ small teams
* but... what about something at enterprise scale?
* Scaled Agile Framework (SAFe)
* (look scary?)
* we'll just be focusing on the bottom row
* which anyway is basically just scrum
* but inside of this larger machine
focus on learning
* about ourselves
* about our customers
* about our products
focus on adapting
* (adapt != thrash)
* adapting == learning
* adapting == improving
focus on delivering value
* take that learning & adapting...
* ...and make better stuff
----
* b/c isn't that what everyone wants?
* "the business" & devs alike?
* and isn't that why co.s _really_ adopt scrum?
* to learn
* to get a better cadence
* ultimately: to be more profitable?
What the ☞✯☭☂ is a ScrumMaster?
Team Member
(not a project manager)
* NOT a project manager
* embedded member of the team
* this is The Scrum Way
* and an important tenet of Scrum
Facilitate Scrum
* that's the SM's MAIN MISSION
* "That means..."
* promote the principle of "self-organization"
* facilitate the scrum ceremonies
(stand-up, retro, sprint review, sprint planning, &c.)
* UNBLOCK! (remove impediments)
* _retro retro retro_
(help the team to self-discover & improve)
Servant-Leadership
* ...and the point of facilitating scrum?
* to help guide the team through sprints
* a little bit coach, a little bit role model
Why be a ScrumMaster?
(...when you're already a developer?)
* TELL YOUR STORY
* started when Sean left
* ("Who is Sean?")
* for another team
* CHANGE! crisis? or opportunity?
1. seemed a good way to represent the team
(after all, these are guys I've worked with for years now)
2. recent projects had left me feeling...
- unfulfilled?
- under-utilized?
EXPECTATION:
"It's like maybe two hours per day."
REALITY:
Not at first.
* knew there'd be some transition
* wasn't prepared for the initial perspective shift required
* granted, it's not _necessarily_ a full-time thing
* but there's an (initial) investment to be made
EXPECTATION:
"Mornings for Scrum, afternoons for Dev."
REALITY:
Maybe on a good day.
* b/c that's how I naïvely thought this would be
* in the morning: do the stand-up, sum the board, unblock everyone and... done
* in the afternoon: head down on dev task
* reality was that being a successful SM meant allowing for interruptions
* b/c the team comes first
* and the only way to ensure that THEY maintain perspective
* is if you can allow them to focus & flow
* and/but/so *as* a member of the team
* (who is also a developer at heart)
* I want in on that flow too
* after all: I got into this game to build cool stuff too
* AND/BUT/SO on a good day that *was* the rhythm
* some days it was unavoidable
* (esp. around sprint boundaries)
* but that was certainly what I strove for
EXPECTATION:
There will be friction between two roles.
REALITY:
Some, but mostly in the beginning.
* not something I thought of at first
* question raised by our out-going SM
* one that I did not anticipate
* and/but there was definitely that friction
* esp. when there was work I wanted to do...
* ...but knowing that the SM work needed to come first
* b/c being entrenched in it: you start to see how valuable the SM work is
* e.g., going to another team and explaining how your team is blocked
* e.g., meeting a critical deadline by running interference on escalations
(or else handling it yourself)
It’s the equivalent of spending years counting the number of apples you picked each day, and changing to a job picking bananas, only to say to yourself at the end of each day, "I didn't pick any apples," handily ignoring the giant pile of bananas sitting next to you.
-- Fitzpatrick & Sussman, Team Geek (2012)
BUSINESS:
Elevated ScrumMastering
* this one from Ross
* esp. at beginning of Agile at DDC...
* ...almost every SM was a former TPM
* and whereas a TPM could manage multiple projects
(and thus across multiple teams)
* being a SM is more intense (b/c you're embedded in the team)
* so by taking that bold 1st step: demonstrated to more teams that it could be done
* ...to take SM'ing seriously
* ...and that you (yes, YOU) Mr. or Ms. Developer, could do it
* (i.e., more _capable_ SMs)
* EXAMPLE: at least 5 other technical people became SMs
BUSINESS:
Lose Less in Translation
* "Don't get me wrong..."
* TPMs have made careers of doing _exactly this_
& I've got the utmost respect for what they do
* and/but/so: in some fast-paced situations, having the SM _be_ technical is an advantage
* e.g., you already have the code checked out
* and/or you have the trust of the team
* ...and so when you are over with another team trying to unblock
* ...you can just make a call about what to do
(b/c you have some technical insight and you have the team's trust)
* EXAMPLE: somewhat frequently, we would escalate to SE
and I'd be able to _just tell them what they needed_
TEAM:
Has a Trusted Advocate
* 2 slides ago I was defending TPMs
* but let's admit it:
* even on the most healthy teams there's some friction b/w devs + PMs
* DDC did away w/ (T)PMs in favor of SMs when we "went Agile"
* but SM still fills a lot of the roles that TPMs historically did
* like creating the "artifacts"
* like coordinating w/ other teams ("unblocking")
* like being the one that gets called into this or that meeting
* and/but/so there's that historical friction w/ even the best TPM
* but when your SM is also a dev, it's a different relationship
(b/w the SM and the team)
* EXAMPLE: when representing them at meetings...
* ...they know that I'm able to (say...) defend the estimates
TEAM:
Learning Leadership
* so many leaders...
* Managers & Directors...
* Tech Leads & Architects
* Product Owners
* &c.
* but SM is a leader for _learning_
* SM is there not to push the team
* ...but to coach the team into high-performance
* you get to high-performance by...
* trying and failing
* failing and learning
* EXAMPLE: estimates!
* something we learned pretty early on in our Agile journey
* beginning: fine-grained tasks - "That should cover everything!"
* except: it never does (something is always missed)
* TO THE RETRO! part over-thinking; part sand-bagging?
* try it: _resist_ the urge to spell it out
* use higher-level tasks
* seemingly larger estimates
* ...but we wound up closer, and our velocity improved
PERSONALLY:
Top-Down for the Big Picture
* "to go way back"
* time as Support Manager
* time as Production Manager
* big picture was thrust upon me
* and/but - didn't feel ready for the responsibilities?
* as a dev = wind up task focused
* and/or project focused
* and/or story focused
* the point = not thinking at the level of "the business"
* SM role gave me a lot more exposure to other teams
* what they needed from us
* and vice versa
* EXAMPLE: this became an every day thing
* we would do stand up
* I would tally hours
* I would tally escalations
* I would go try to unblock
* ...and be the one field questions about "Can you unblock us...?"
* started to look at the business in a more holistic way
PERSONALLY:
More Confidence
* came directly out of looking at the business holistically
* when I had a chance to do dev work
* ...I felt more confident that I was working on THE RIGHT THINGS
* felt MORE AWARE of priorities
* had an EASIER TIME of separating the important from the urgent
* _started_ to master "The Art of the Positive No"
* (I'm still not _great_ at this, but I've gotten pretty good)
* e.g., listening, ack'ing, and explaining Why-Nots and Alternatives
* _some of that_ comes from the VISIBILITY that is one of the central tenets of Scrum
* SEEING the backlog on the wall every day
* SEEING the stories we're actively working on
* KNOWING that anyone else can come down and see the stories &c.
Where does the story end?
* SPOILER ALERT: after about 9 months...
...I got out of the SM game
* got out of it what I wanted
* felt it was time to return my focus to dev
* but: good career move
* new perspective on the business
* but it's that... "meta-learning"
* about how to relate _to_ the business
(and what it needs)
* a good _kind_ of leadership role to have
