1) Gain buy-in from both top management and those implementing changes; 2) Explain how Scrum can reduce wasted time through better planning and transparency; 3) Be pragmatic when applying Scrum principles given organizational realities.

1. Presented by
Paul Sherrill
paul@sherrill.us
Scrum For Cynics
(steps for overcoming scrum transformation obstacles*)
* Meaning people and scrum/agile dogma

2. Get out your post it…

3. • My take on the agile manifesto
• 80/20 guide to scrum transformation
• Story: A successful scrum team ?
• Meetings (uh, I mean ceremonies)
• Wrap up
Todays Chat

4. • Curmudgeon (Carl)
▫ Senior Architect/Devloper
▫ 15 plus years in industry
▫ 10 plus years in company
▫ Smart and liked by many levels of the engineering
community
▫ Respected by management
▫ Specialist in his area and active in SW development
process
• The Horse’s Face
▫ Agile/Scrum coach
▫ Smart fellow
▫ Try’s to take a pragmatic approach towards Scrum
The Actors
Governance Suits of Invincibility

5. • Individuals and interactions over processes and tools
▫ Don’t rely on dogmatic following of process
▫ STW: New process, many meetings, new terms, respect time
▫ Key Theme: Respect (people and time)
• Working software over comprehensive documentation
▫ Produce working software out of the gate
▫ STW: Focus on producing software yet first x sprints seem focused on following scrum dogmatically with lots
of “stuff” (stories/epics/tasks/backlog/retrospective….)
▫ Key Theme: Build (product)
• Customer collaboration over contract negotiation
▫ Don’t hide behind the backlog
▫ STW: “Send me an email, I’ll throw it in the backlog”
▫ Key Theme: Transparent (communication)
• Responding to change over following a plan
▫ STW: “I can’t commit to a date for that feature”
▫ Key Theme: Flexibile
STW = Scrum Transformation Warning
My take on the manifesto

6. Planning
Above the line
▫ Team Capacity
▫ User Story Content - Definition of Done/Acceptance Criteria
▫ Estimate using days NOT points
▫ Assignment of at least one story/task to each person at closure
▫ Time box
▫ Planning poker
Below the line
▫ Points/relative sizing
▫ Full task breakdown
▫ Team “pull” items
Standup
Above the line
▫ Every day
▫ Strict timebox
▫ Scrum master lead strongly (initial sprints)
▫ Blockers
▫ Physical or at least video conference
Below the line
▫ Tracking effort and time left
▫ Update in online tool
My 80/20 for Scrum
Review/Retrospective
Above the line
▫ One meeting, not two
▫ Strict separation on agenda
▫ Demo, demo, demo. Prep team well in advance
▫ Cookies
▫ What rocked
▫ What was “meh”
▫ What sucked
▫ Pick at most 2 to improve
▫ Strong Facilitation (only use cheesy activities if it fits the teams
style)
▫ Measure Velocity
Grooming
Above the line
▫ Pre-meeting so that stories have some structure and
correctness
▫ Respect timebox
▫ Include whole team
▫ Enough stories to populate the next sprint
▫ Team help write stories
▫ Definition of Done

7. • No one trained in scrum
• 1.67 people remote (the “1” was the scrum master)
• Standup meeting length = 90 minutes
• Velocity measurement? I think not
• Product Owner = Manager
• No task level breakdown
But…..
• Respect, Flexible, Build, Transparency
And
• Our process was worked for our team
My most successful scrum-like team

8. Theories/advice/suggestions
• One scrum master full time per team
• PO should be dedicated to team
• Line manager should not be executing these roles
• Scrum master is not a project manager
Reality
• Managers and directors are supportive of your transition up to the point you start
suggesting we need to eliminate their role or give up power. All of the above are
only completely solved by a radical reformation when you are dealing with large
engineering organization. I would not bet my bonus on being able to pull this off
But
• A good project manager can be a scrum master
• Teams can still be effective with the SM or PO role shared between teams or done
by members of the team
• The right manager can certainly play these roles
• If you can pilot an ideal scrum team and show the value you can change some minds
Some words on roles (theory vs reality)

9. • “The daily stand up is not a status update meeting”
• “Sounds like group level micro-management to me”
Daily Standup
• “The daily stand up is not a status update meeting to report
out progress to a manager”. It’s by the team for the team. But
yeah it is a status meeting. It would not be scrum if we did not
give it another name.
• Well, it kind of is. But again it’s for the team to communicate
and commit to each other to get stuff done. Besides we don’t
want the managers to step in and ruin our fun.

10. Daily Standup (80/20)
▫ Every day (and have your answer for why?)
▫ Strict time box
▫ Scrum master lead strongly (initial sprints)
▫ Blockers
▫ Physical or at least video conference
----------------------------------------------------------------------------------Line
▫ Tracking effort and time left
▫ Update in online tool

11. • “How can I estimate effort for an area I don’t know”
• “You think we are just cogs that can work on
anything, I’m a specialist”
Planning
• Your “beginner’s mind” is sometimes the perfect perspective
to clarify the effort and refine the definition of done. I heard
you liked a good game of poker.
• OK, you exposed us. Scrum is not a resource optimal process
in the short run. Sometimes we need to rely on the your
expertise. Think of scrum as a “long” con. Over time, you will
get more people who can work more generally on the product.
Never completely but it will get rid of some of the micro
competencies and allow you to not be the one fixing the
customer bug on Sunday at midnight

12. Planning (80/20)
▫ Team Capacity
▫ User Story Content - Definition of Done/Acceptance Criteria
▫ Estimate using days NOT points
▫ Assignment of at least one story/task to each person at closure
▫ Time box
▫ Planning poker
---------------------------------------------------------------------------------------- Line
▫ Points/relative sizing
▫ Insist on full task breakdown
▫ Team “pull” items
▫ Fully canonical user stories

13. • “Another damn meeting? When do you expect me to get
work done”
• “I’ve got an improvement suggestion, dump scrum”
Review/Retrospective
• We do have a bunch of different forums and we account for
that time. Is there a better alternative? Not asking for a
formal presentation or that you sign off on reams of
paperwork. Show us your awesome shit, rock star.
• Hey Carl, 15 minutes before the review I’m having a little
personal celebration (break out Carl’s drink of choice).

14. Review/Retrospective (80/20)
▫ One meeting, not two
▫ Strict separation on agenda
▫ Demo, demo, demo. Prep team well in advance
▫ Cookies
▫ What rocked
▫ What was “meh”
▫ What sucked
▫ Pick at most 2 to improve
▫ Strong Facilitation (only use cheesy activities if it fits the teams style)
▫ Measure Velocity
---------------------------------------------------------------------------------------- Line

15. • If we stack it all up there is a bunch of time in meetings. I mean ceremonies. Be
transparent.
▫ Perceived time sunk
 1 person, 2 week sprint = 80 hours
 80 – company overhead (20%) – scrum overhead (8) = 56 hours
▫ Possible time gained
Hopefully you are giving some time back since the planning/standup hours results in a
reduction of those endless emails back and forth getting clarification. If you get good you will
also reduce needless paperwork and status reporting.
** If your org decides to also continue other forums for project status and the like then
you are at risk of not giving back to the people.
A word about Scrum overhead

16. • #1 obstacle to a transformation
▫ top management buy in
• #1 obstacle to a great transformation
▫ ground up buy in
Hidden key to successful transformation

17. Employers
- Tandem
- Network General
- Cosine
- Genentech
- Ericsson
- Fluke Networks
- Ericsson (yep, liked it
so much I went back)
- Cisco
Me
paul@sherrill.us
Roles
- Build Engineer
- Project Manager (n
times)
- SW Eng manager
- Test/Devops Director
- Devops Manager