Your SlideShare is downloading. ×
The things we weren't told about Scrum
The things we weren't told about Scrum
The things we weren't told about Scrum
The things we weren't told about Scrum
The things we weren't told about Scrum
The things we weren't told about Scrum
The things we weren't told about Scrum
The things we weren't told about Scrum
The things we weren't told about Scrum
The things we weren't told about Scrum
The things we weren't told about Scrum
The things we weren't told about Scrum
The things we weren't told about Scrum
The things we weren't told about Scrum
The things we weren't told about Scrum
The things we weren't told about Scrum
The things we weren't told about Scrum
The things we weren't told about Scrum
The things we weren't told about Scrum
The things we weren't told about Scrum
The things we weren't told about Scrum
The things we weren't told about Scrum
The things we weren't told about Scrum
The things we weren't told about Scrum
The things we weren't told about Scrum
The things we weren't told about Scrum
The things we weren't told about Scrum
The things we weren't told about Scrum
The things we weren't told about Scrum
The things we weren't told about Scrum
The things we weren't told about Scrum
The things we weren't told about Scrum
The things we weren't told about Scrum
The things we weren't told about Scrum
The things we weren't told about Scrum
The things we weren't told about Scrum
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

The things we weren't told about Scrum

4,575

Published on

This is a version of the presentationI delivered last year to the MIH Tech Conference in Prague. …

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 teams

Published in: Technology
2 Comments
6 Likes
Statistics
Notes
  • Very good slides, thx
    I posted on a related topic.

    http://according2albert.wordpress.com/2012/04/30/how-scrum-backfires-at-top-developers/

    I got some new ideas watching your slides.
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Great set of slides, learnt some useful stuff - thanks!
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total Views
4,575
On Slideshare
0
From Embeds
0
Number of Embeds
4
Actions
Shares
0
Downloads
139
Comments
2
Likes
6
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • my name is Tim GregoryI work for 24.com in Cape Town, South AfricaI’ve been with the company about 3 years, but on and off I’ve been working with the Naspers and Media24 group companies for 11 yearsI manage a couple of teams at 24.comI’m currently responsible for all the central production teams at 24.com:DevelopersProject ManagersScrum MastersDesignersWeb Developers (HTML, JS, CSS)
  • I’m going to tell you a bit today about the things we weren’t told about Scrum, and things we’ve discovered along the way in our use of Scrum over the last few years
  • I’m going to touch on 3 areas:How to use Scrum techniques in teams that don’t use scrum to manage their workHow to innovate with Scrum teamsAnd a couple of things we’ve learned about Scrum at 24.com over the past couple of years
  • Collection of internet and publishing businessesWe’re South Africa’s leading Online PublisherWe publish a number of brands and servicesOur best-known site is News24, with a local audience of well over a million users.We’re about 250 people in total, with about 40 dedicated technical staff.As you can imagine, a lot of activity generated by the various sites and products….
  • Begin my story with a bit of history regarding the project and production management processes at 24.com, and why we were all miserable We had a very formal traditional software development approach.It wasn’t wrong per se, simply inappropriate for our environment and the speed with which we wanted to work.
  • Overview of roles, rituals, and artifacts
  • Incremental delivery of products and features that the business values most
  • Not going to go into any detail now with regard to why scrum is not suitable for all teams, will explore that later this morning.Assuming that scrum will not work in it’s entirety, I would still encourage you to adopt some scrum techniques.
  • Whiteboards are placed in the hallwaysMeetings are often held around the boards
  • Point out roles of people in the teamsOps, Developers, Product Owner, Project Manager,, Editorial
  • Point out roles of people in the teams
  • Discovering that we were getting through a lot of work, but we weren’t keeping up with the technology landscape.Developers not getting stretched.Problems all tackled using their existing toolset – no chance to try anything different
  • Discussed the challenge, and came up with a couple of approaches to the problem
  • Example – Solr search
  • Example – Solr searchWe were experiencingcomplaints from the editorial teams about the poor quality of SQL search results within the CMS.Created a story to investigate an Opensource, Java-based search technology called Solr.Based on the strength of the technology, replaced the SQL search inside our CMS with Solr, and then deployed it as our search solution for Food24 Restaurant and Recipe search shortly afterwards.Now being rolled out to a number of non-search applications – content recommendation, content aggregation, geographic search
  • We colour-code cards for different types of tasks
  • Pair-programming was something I was a little uncertain about at first..I thought that if you put two developers at a single workstation, our productivity would drop in half.But the team wanted to try it, and in the spirit of self-managing and empowered teams gave them a chance.
  • Not all projects lend themselves to Scrum..Match your processes to the the project requirements.Use Scrum where it makes sense – incremental product improvement, rapid iteration, emergent architecture, changing requirements.Use a traditional Software Development Lifecycle approach where you need a rigorous approach with a lot of upfront planning
  • Need to make sure that the business is focused on the outcome, not the process.
  • Any Questions
  • Transcript

    • 1. Tim Gregory
      Head of Development
      tim.gregory@sa.24.com
    • 2. The things we weren’t told about Scrum
      February 2010
    • 3. 3 Topics today
      Scrum-techniques in non-Scrum teams
      Scrum & Innovation
      What we’ve learned about Scrum @ 24.com
    • 4. A bit about 24.com….
    • 5. The dark days of the Project Office
    • 6. 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
    • 7. 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
    • 8. 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
    • 9. Scrum overview
      ©Mountain Goat Software
    • 10. 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
    • 11. Scrum techniques in non-Scrum teams
      Whiteboards– “information radiators”
    • 12. Scrum techniques in non-Scrum teams
      Cross-functional project teams
      Developers
      Designers
      Project manager
      Editorial staff
      Operations
      No more strictly sequential work, throwing work “over the fence” between teams
    • 13. Scrum techniques in non-Scrum teams
      Daily stand-ups –15 min project meetings
    • 14. Scrum techniques in non-Scrum teams
      Daily stand-ups –15 min project meetings
    • 15. Scrum techniques in non-Scrum teams
      Milestone demonstrations
      Developers demo their own work tothe team (and to the business owner for the project)
      Builds ownership and commitment
    • 16. Scrum techniques in non-Scrum teams
      Retrospectives – every few weeks
      Facilitated team meeting
      “What went well?”
      “What could be done better?”
      “What will we try that could improve efficiency?”
      Creates a cycle of continuous improvement
      Works for any team, scrum or not
      (Even trying this technique with Operations team)
    • 17. Scrum & Innovation
      In Scrum, nowhere to hide
      By Clark & Vizdos
      © implementingscrum.com
    • 18. 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
    • 19. Scrum & Innovation
      How do we ensure that developers are stretched, stimulated, motivated, and keep their edge?
      ?
    • 20. 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?
    • 21. 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
    • 22. 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
    • 23. Scrum: Lessons Learned
      “Stuff that works for us”
      (might not work for you)
    • 24. Scrum: Lessons Learned
      Full transparency – everything on the board:
      Whiteboard sessions, QA, testing, deployment, investigations, optimisation, innovation stories
    • 25. Scrum: Lessons Learned
      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
    • 26. Scrum: Lessons Learned
      Pair-programming works: reduces bugs, improves skill-transfer, reduces testing
    • 27. Scrum: Lessons Learned
      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
    • 28. Scrum: Lessons Learned
      Design processes around process profiles
      At 24.com:
      Production work / Publishing support:
      • 150 – 250 tasks per week
      Projects
      • 2-5 larger projects run concurrently
      • 29. Duration 3 weeks to 6 months
      Scrum
      • 3 Week Sprints, measured in story points / sprint
    • Scrum: Lessons Learned
      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
    • 30. Scrum: Lessons Learned
      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)
    • 31. Scrum: Lessons Learned
      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
    • 32. Scrum: Lessons Learned
      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
    • 33. Scrum: Lessons Learned
      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
    • 34. Scrum: Lessons Learned
      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
    • 35. Kweshuns???
      ?
    • 36. Tim Gregory
      Head of Development
      tim.gregory@sa.24.com

    ×