the things we weren't told about scrum
Post on 17-Oct-2014
5.232 views
DESCRIPTION
This is a version of the presentationI delivered last year to the MIH Tech Conference in Prague.About 2 years after the introduction of Scrum to 24.com I take a look at some of the things we've learned, in particular how to manage innovation in a Scrum environment, and how to use Scrum techniques in non-Scrum teamsTRANSCRIPT
The things we weren’t told about Scrum
February 2010
3 Topics today
• Scrum-techniques in non-Scrum teams• Scrum & Innovation• What we’ve learned about Scrum @ 24.com
A bit about 24.com….
The dark days of the Project Office
The dark days of the Project Office
• 400+ “Projects” in the pipeline at any time• No regard to complexity or duration• Sausage-factory approach – Each project tackled
in sequence, with little regard to business value• Long project delivery times – after 12 months,
business requirements can change!• General misery & dissatisfaction – something had to change
The dark days of the Project Office
• 24.com started a Scrum trial about 2 years ago• Very successful, rolled Scrum out to 4 teams in
the organisation• Has become our preferred way of working, but
we choose either a formal SDLC process or Scrum (or a combination) depending on the project
Scrum overview
3x3x3:• 3 Roles– Product Owner, Scrum Master, Team
• 3 Rituals– Sprint Planning, Daily Stand-up, Retrospectives
• 3 Artefacts– Product Backlog, Sprint Backlog, Burn-down chart
Scrum overview
©Mountain Goat Software
Scrum techniques in non-Scrum teams
Scrum is not suitable for all teams…..
(more on that later)
But… scrum techniques can be used to improve the performance of any team
Scrum techniques in non-Scrum teams
1. Whiteboards – “information radiators”
Scrum techniques in non-Scrum teams
2. Cross-functional project teams– Developers– Designers– Project manager– Editorial staff– Operations
No more strictly sequential work, throwing work “over the fence” between teams
Scrum techniques in non-Scrum teams
3. Daily stand-ups –15 min project meetings
Scrum techniques in non-Scrum teams
3. Daily stand-ups –15 min project meetings
Scrum techniques in non-Scrum teams
4. Milestone demonstrations
– Developers demo their own work to the team (and to the business owner for the project)
– Builds ownership and commitment
Scrum techniques in non-Scrum teams
5. Retrospectives – every few weeksFacilitated team meeting
“What went well?”“What could be done better?”“What will we try that could improve efficiency?”
Creates a cycle of continuous improvementWorks for any team, scrum or not(Even trying this technique with Operations team)
Scrum & Innovation
• In Scrum, nowhere to hide
By Clark & Vizdos© implementingscrum.com
Scrum & Innovation
• Scrum pace can be relentless
– Product Backlog contains months of work– Continuous efforts to improve efficiency– Daily status meetings– Scrutiny from Product Owner (and peers!)– Teams are self-managing, but don’t always have
representation on the backlog
Scrum & Innovation
How do we ensure that developers are stretched, stimulated, motivated, and keep their edge?
?
Scrum & Innovation
How do we ensure that developers are stretched, stimulated, motivated, and keep their edge?
– Hold back capacity from the business?– Sneak extra time – developer’s own initiative?– Gap-days?– Innovation Stories?– Innovation Sprints?
Scrum & Innovation
“Innovation Stories” are the solution for us…Must be:– Technically challenging– Not related directly to current projects – Of long-term benefit to the business– Encourages team-work and sharing– Story must have some “Cool factor”– “Enablers” – must build technical capabilities
Scrum & Innovation
“Innovation Stories” are the solution for us…
Important for the technical teams to have a voice – must be able to put tech stories into the backlog
Success story - Solr search technology
Scrum: Lessons Learned
“Stuff that works for us”
(might not work for you)
Scrum: Lessons Learned
1. Full transparency – everything on the board:Whiteboard sessions, QA, testing, deployment, investigations, optimisation, innovation stories
Scrum: Lessons Learned
2. Deployment stories at the beginning of the sprint, innovation stories at the end
– Deploy code after your demo, not before (you may have to tweak after the demo)
– Stay focussed on most pressing business needs– Motivate the team to get onto the fun stuff– Push hard, and drop stories if you really have to
Scrum: Lessons Learned
3. Pair-programming works: reduces bugs, improves skill-transfer, reduces testing
Scrum: Lessons Learned
3. Pair-programming works: reduces bugs, improves skill-transfer, reduces testing
BUT – shared responsibility is no responsibility:Who will: check-in code, write documentation, unit-
tests, logging, deployment scripts etc?Ensure that nothing slips through the cracks when
pairing
Scrum: Lessons Learned
4. Design processes around process profiles
At 24.com:Production work / Publishing support:– 150 – 250 tasks per week
Projects– 2-5 larger projects run concurrently– Duration 3 weeks to 6 months
Scrum– 3 Week Sprints, measured in story points / sprint
Scrum: Lessons Learned
5. Social elements of Scrum are a powerful factor:– Team co-location– Standing in front of the board– Ownership of problems– Commitment to delivery– Demo your own work to the business
Beware of online Scrum tools….. Good for distributed teams, but you shouldn’t lose the
social elements if you don’t have to
Scrum: Lessons Learned
6. Scrum will expose inefficiencies in other parts of your business – be prepared for it!– Process issues– Prioritisation issues– Problem staff– Bad planning habits– Hiring strategies (Team fit becomes v.NB)
Scrum: Lessons Learned
7. Avoid “dead documents” if we can
– Don’t create lots of paperwork– Use a Wiki for all documentation– Ensure documentation is in use and updated
constantly
Scrum: Lessons Learned
8. Make sure the technical stories make it onto the backlog – convince the Product Owner!
– Optimisation and code-refactoring– Framework and tool updates– Security and patching– Migration & testing, e.g. IIS6 > IIS7– Investigations and prototypes
Scrum: Lessons Learned
9. At crunch times, business people and editors are embedded in the Scrum teams
– Co-locate with Developers for site development & launches
– Bonds project teams and gives common purpose– No misunderstandings– Ensures focus from the business on task at hand
Scrum: Lessons Learned
10. Scrum is a management framework, not a development framework
You still need to define your dev processes:– Continuous integration & automated builds– Unit tests– Automated functional tests (Selenium)– QA process– Documentation style & standards– Release cycle, Release process, Tools
Kweshuns???
?