The things we weren't told about Scrum
•Als PPTX, PDF herunterladen•
6 gefällt mir•2,300 views
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
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Andere mochten auch
Ähnlich wie The things we weren't told about Scrum
Ähnlich wie The things we weren't told about Scrum (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
The things we weren't told about Scrum
- 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
- 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
Hinweis der Redaktion
- 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