The things we weren't told about Scrum

Tim Gregory

Head of Development

[email protected]

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


• 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


• 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


1. Whiteboards – “information radiators”


2. Cross-functional project teams– Developers– Designers– Project manager– Editorial staff– Operations

No more strictly sequential work, throwing work “over the fence” between teams


3. Daily stand-ups –15 min project meetings


4. Milestone demonstrations

– Developers demo their own work to the team (and to the business owner for the project)

– Builds ownership and commitment


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)


1. Full transparency – everything on the board:Whiteboard sessions, QA, testing, deployment, investigations, optimisation, innovation stories


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


3. Pair-programming works: reduces bugs, improves skill-transfer, reduces testing


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


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


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


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)


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


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


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


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???

?

Tim Gregory

Head of Development

[email protected]

The things we weren't told about Scrum

Technology

Transcript of The things we weren't told about Scrum