The things we weren't told about Scrum


Published on

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 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
  • Very good slides, thx
    I posted on a related topic.

    I got some new ideas watching your slides.
    Are you sure you want to  Yes  No
    Your message goes here
  • Great set of slides, learnt some useful stuff - thanks!
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • my name is Tim GregoryI work for 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 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 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, 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
  • The things we weren't told about Scrum

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