Scrum: Physical or Virtual
•Télécharger en tant que PPTX, PDF•
4 j'aime•3,622 vues
Why do some development teams favour physical story cards and a physical wall over digital? What are the advantages and disadvantages of using physical over digital? When should you use which and how can you combine them? These are difficult questions to answer and often they are the first questions that a team has to deal with when implementing an agile methodology. This session is an experience report rooted in the academic literature. It will aim to answer the questions above using use case examples from the author’s own experience. It will also incorporate the latest academic research into the field specifically using research from Human Computer Interaction in which Agile teams have been analysed to explain the benefits of physical and digital artefacts.
Recommandé
Recommandé
Contenu connexe
Similaire à Scrum: Physical or Virtual
Similaire à Scrum: Physical or Virtual (20)
Scrum: Physical or Virtual
- 1. Scrum: Physical or virtual walls? Paula de Matos
- 2. What is this talk about? versus 2
- 3. About me Paula de Matos Group Coordinator and User Experience Analyst at the EBI Previous incarnations: • Java Technical Lead • Java Developer • Broadcast Engineer • Electronic Engineer
- 4. About the European Bioinformatics Institute • Based on the Wellcome Trust Genome Campus near Cambridge, UK • Non-profit organisation • Close to 500 employees • Aims to provide comprehensive biological data to scientists
- 5. My work We like a physical cards and walls wall Team B (4 people) Team A (6 people) We like software tools to manage our process Team C (4 people) 5
- 6. How I became an Agile fan? Picture attribution, Toby Bradbury (Flickr) – Creative Commons License 6
- 7. Our Scrum-like process Tasks 7
- 8. What is this talk based on? • My own experience • Survey: 23 respondents • Scientific publications Picture attribution, Flickr, The Bees 8
- 9. Unscientific survey: 23 respondents • Open ended questions • Aim to get as broad a view as possible • 65 % of respondents had experience with physical and software tools Picture attribution, Flickr, The Bees 9
- 10. Respondents agile experience < 3 years 3-10 years > 10 years 13% 44% 43% Picture attribution, Flickr, The Bees 10
- 11. The academic literature • Sharp et al. (2006). The Role of Story Cards and the Wall in XP teams: a distributed cognition perspective. • Sharp et al. (2008). Collaboration and co- ordination in mature eXtreme programming teams. • Whittaker et al. (1999) Board meetings: the impact of scheduling medium on long term group coordination in software development. Picture attribution, Flickr, The Bees 11
- 12. The academic literature • Methods: mainly observation and ethnography • Distributed Cognition Analysis: • Physical theme • Physical artefacts • Information flow Picture attribution, Flickr, The Bees 12
- 13. What do I mean by user story and taskboard? 13
- 14. What do I mean by user story? Picture attribution, Flickr, J Beau 14
- 15. How are user stories stored? 15 Picture attribution, Flickr, Natalia Osiatynska
- 16. Picture attribution, Flickr,Mircea Turcan 16 29/09/201
- 17. Picture attribution, Flickr, Drew Stephens 17
- 18. 18 Photo attribution: Roger Greenhalgh (Flickr) – under the Creative Commons license
- 19. 19
- 20. What does the “taskboard” look like? 20
- 21. 21
- 22. 22 Photo attribution: Levent Ali (Flickr)– Creative Commons license
- 23. What are the advantages of physical walls? 23
- 24. Visual 24 Photo attribution: C. Fraser (Flickr) – Creative Commons license
- 26. 26 Photo attribution: Logan Ingalls (Flickr)– Creative Commons license
- 27. It’s easy to update the board 27 Photo attribution: Ha! Designs (Flickr) – Creative Commons license
- 28. Sense of achievement 28 29/09/201 Photo attribution: Welsh government (Flickr) – Creative Commons license
- 29. Encourages personal communication between members 29 29/09/201 Photo attribution: David Cosand (Flickr) – Creative Commons license
- 30. Encourages personal communication between members and managers 30 29/09/201 Photo attribution: David Cosand (Flickr) – Creative Commons license
- 31. Holding a card engenders feelings of task ownership and responsibility 31 Photo attribution: Victor1558(Flickr) – Creative Commons license
- 32. Encourages reflection 32 29/09/201 Photo attribution: Mike Baid (Flickr) – Creative Commons license
- 33. Size limit of cards promotes collaboration 33 Photo attribution: Roger Mateo Poquet (Flickr) – Creative Commons license
- 34. What are the drawbacks of using physical cards? 34
- 35. Ghost cards 35 Photo attribution: Mosieur J (Flickr) – Creative Commons license
- 36. No burndown charts or tie into project management software 36 Photo attribution: Jeff Covey (Flickr) – Creative Commons license
- 37. Hours, points or estimates need to be tallied manually 37 Photo attribution: Yum9me (Flickr) – Creative Commons license
- 39. Readability 39 Photo attribution: Jim Barter (Flickr) – under the Creative Commons license
- 40. Missing in action 40 Photo attribution: Brenderous (Flickr) – Creative Commons license
- 41. Archiving 41 Photo attribution: Damien Oz (Flickr) – Creative Commons license
- 42. Space constraints • Title • Estimate • Description • Stack trace • Bug tracker info • Additional comments • Etc…. 42
- 43. No tie into bug trackers and existing documentation 43 Photo attribution: Ivan Walsh (Flickr) – Creative Commons license
- 44. Unwieldy for large teams 44 Photo attribution: avlxyz (Flickr) – Creative Commons license
- 45. Advantages of software solutions to manage your tasks and wall 45
- 46. Geographical location • Team members and management • Meeting rooms 46
- 47. Automatic features – burndown charts, velocity 47 29/09/201
- 48. Information rich story cards 48
- 49. Access archived sprints 49 29/09/201
- 50. Tie into existing software systems 50 Photo attribution: Paolo Valdemarin (Flickr) – Creative Commons license
- 51. Disadvantages of software solutions to manage your tasks and wall 51
- 52. Can become microtasking hell Task 1 Task 1.1 Task 1.2 Task Task Task 1.1.1 1.1.2 1.2.1 52
- 53. Keeping it upto date is difficult 53 Photo attribution: Yon Garin (Flickr) – Creative Commons license
- 54. Visibility is lost 54 Photo attribution: AV-1 (Flickr) – Creative Commons license
- 55. Cards are not distinctive enough 55
- 56. Computers are full of distractions 56
- 57. Case study: The best of both worlds 57
- 58. We maintained the backlog using an agile software tool 58
- 59. User stories were exported to Excel 59
- 60. Cards were generated using an Excel visual basic script 60
- 61. Cards printed and subtasks were assigned using post-it notes Check Implement Test cases mockups design users 61
- 62. Cards and subtasks were placed on a mobile board 62
- 63. At the end of sprint: post-its were chucked out and new stories printed 63
- 64. Tips on maintaining physical walls 64
- 65. Use effective stationery 65 Photo attribution: Ivan Di Carlo (Flickr) – Creative Commons license
- 66. Place your wall in a prominent position 66
- 67. Use a transportable board if you need your wall to be mobile 67
- 68. Treat your cards with the respect they deserve 68
- 69. Tips on choosing software solutions 69
- 70. Compile a checklist of what you want the software to do 70 Photo attribution: Mistersnappy (Flickr) – Creative Commons license
- 71. Consider your existing software infrastructure 71
- 72. Ease of use 72 Photo attribution: Ha! Designs (Flickr) – Creative Commons license
- 73. Consider how you will replicate the tactile nature of the taskboard Check Implement Test cases mockups design users 73
- 74. In summary 74
- 75. 1st Conclusion Choose a solution that suits the team, organisation, culture and environment. 75 Photo attribution: Jace Cooke (Flickr) – Creative Commons license
- 76. 2nd Conclusion Trial and error. 76 Photo attribution: Everyones idle (Flickr) – Creative Commons license
- 77. 3rd Conclusion Don’t underestimate the sensory nature of physical walls… think carefully about how that can be replicated in a software only solution. 77 Photo attribution: Nikki Duggan (Flickr) – Creative Commons license
- 78. Thanks • Cheminformatics and Metabolism team members • Survey respondents • The authors of the academic literature cited 78
- 79. Contact me Email: pmatos@ebi.ac.uk LinkedIn: Paula de Matos Twitter: @Paula_deMatos 79
Notes de l'éditeur
- This talk about explores the notions of using physical artefacts versus software tools to manage your agile process.I will use the literature and my own experience to show you the benefits and drawbacks of using either of these methods.I hope to convince you that paper is “almost” always the way to go but there are always exceptions….
- I am a group coordinator and UX at the EBI.I have worked in software development for more than 10 years both within Agile teams and also as Product Owners and Scrum masters.I come from a development background primarily in Java and frontend. I have been a part of numerous teams setting up backend systems and web systems.Most of these systems are international collaborations where colocation of the team was not always possible.I recently completed an MSc in HCI and now focus my efforts on improving the user experience both externally (users) and internally (developers + annotators).
- The aim of the EBI is to provide biological data to scientists across the world.Mainly these come in the form of large databases and complex web frontends.
- As a group coordinator I currently coordinate three main project teams and as a User Experience Analyst I am a member of all three teams.My job was to ensure that there was cohesion within the teams and across the teams. That we all worked towards the same goal of developing cutting edge biological databases for our users without reinventing the wheel.All the teams were cross-disciplinary:2 physical1 software basedAll delivering incremental releases of databases for end users.All following Agile processes which have been tweaked to optimise work.
- Daily work scenarioGiven vague specificationNot able to speak to customersBugs and small features interfering with main stream development
- User stories in backlog in excelUser stories prioritised by product owner (team effort)Team estimates storiesTeam/product owner choose next itemsTeam breaks down stories into subtasksStandup meetings and wallDemonstration at end of ScrumRinse and repeat
- Collaboration and coordination: 3 teamsRole of story cards: 1 team
- Wikipedia says “user story is one or more sentences in the everyday or business language of the end user or user of a system that captures what a user does or needs to do as part of his or her job function.”Mike Cohn suggests “so that” is optional.
- How are real user stories collected or storedExcelAgile Software tool Project Management toolBug trackersPost-it notesCardsboard
- How are real user stories collected or storedExcelAgile Software tool Project Management toolBug trackersPost-it notesCardsboard
- The wall or taskboard has normally atleast three columns but often more depending on your procedure.There is the todo list of items that need to be done.Items in progress can have additional columns such as testing, documentation etc….Done is when the task is completed.So what do these taskboards look like?ExamplesColour schemesMovable board
- Software taskboard from agilewrap
- The wall or taskboard has normally atleast three columns but often more depending on your procedure.There is the todo list of items that need to be done.Items in progress can have additional columns such as testing, documentation etc….Done is when the task is completed.So what do these taskboards look like?ExamplesColour schemesMovable boardHow do people keep the sticky notes on the board?- post-its, work ok but they can quickly fall off the wall
- Everyone can see the board.It gives an overview of the work that needs to be done for everyone in the office.Its presence is an enabler.
- When you trying to coordinate resources having an overview or big picture gives you insight into resource usage.For example a spreadsheet like this one make it difficult to see at a glance at what stage backlog items are at, who is doing what etc….
- A physical wall, if used effectively can give you this information quickly and allows pm’s to coordinate resources.This is an example from Flickr. In my own work we used the post-it notes to signify which subteam was working on what so we could easily see if the developers, data annotators or testers were being overworked.That said, many software tools provide very good visual taskboards which also gives you the big picture.
- Some people find it a lot easier to get up and go to a board and move a card.This is subjective – others would find it easier to do it online and not move at all.This was cited in the survey by users.
- Most developers can’t explain it but they get a kick out of moving the cards to the done category.It gives them a sense of contribution to the project.This has been cited by developers in interviews, literature and the survey.
- Direct personal communicationForced to discuss things infront of a boardIn pair programming having the card in front of you instead of a virtual one allows developers to feel a sense of ownership and therefore communicate better.(This again is subjective)
- Direct personal communicationIn order for managers to find out the state of play they need to consult the physical board. This forces them to go into the developers office and encourages them to engage with the developers.If this was a software tool it would be more convenient for managers but requires less engagement with the team.(This again is subjective)
- Both the survey and the literature report that developers really feel like they own the task when they have the card in their hands or on their desk.The team can clearly see who owns the task if its physically moved but if its virtual this requires team members to log and search for this information.Reported in the literature:Sharp, Helen and Robinson, Hugh (2008). Collaboration and co-ordination in mature eXtreme programmingteams. International Journal of Human-Computer Studies, 66(7), pp. 506–518.
- Whittaker and Schwarz (1999) found that the physical handling of cards encouraged a more thorough reflection as opposed to just updating a software document online.Reference: Whittaker, S. and Schwarz, H. (1999) Meetings of the Board: The Impact ofScheduling Medium on Long Term Group Coordination in Software Development,Computer Supported Cooperative Work, 8: 175-205.
- The fact that the physical size of the card limits the amount of information it means developers have to seek further clarification on the card. Thus it improves collaboration of the team with its customers.This has been observed by Sharp et al. (2006)Sharp, Helen and Robinson, Hugh (2008). Collaboration and co-ordination in mature eXtreme programmingteams. International Journal of Human-Computer Studies, 66(7), pp. 506–518.
- In (some teams) XP programming the programmer will often take the card to their desk and keep it their.To circumvent this programmers draw temporary ghost cards to indicate this. This can be tedious and a bit like micro-tasking.Evidence: Sharp (2006)
- Having the status of the project dislocated from the existing monitoring systems is a real problem. How do you keep them in sync…Some solutions:In some teams the physical wall is the primary source of info but project managers will go in and update their own systems to keep it upto date.
- Tallying ours manually is time consuming and boring. Its also prone to errors and over estimation of tasks leading to sprints not being feasibly completed which is demoralising for the team.If you maintaining a digital version aswell, keeping these hours in sync is a problem.
- When colleagues are offsite this is a major problem. They can’t see the state of play. They must rely on a third information source.How to circumvent:Developers have reported placing a webcam infront of board for colleagues away from the office.
- It can be hard to read the cards from a distance. They can get untidy and it depends on clear handwriting.My own handwriting is atrocious. When I wrote down the cards I could barely read them myself and eventually other team members took up the task out of exasperation.
- We all know the scenario…..It’s a hot day, someone opens a window and a gust of wind blows half the postits off the wall. You try to put as many as you can find back on the wall but of course some go missing.At the end of the sprint you discover some backlog items missing…. or perhaps during the sprint you notice and it affects the product deadline.
- How do you archive user stories?You can conveniently find them?You can also see what was planned for each sprint so as to get an idea of velocity, performance issues etc…?
- A user story is often associated with much information. Physical cards have space constraints which means that key information is stored elsewhere and requires developers to go hunting for this information. Furthermore as the sprints progress sometimes additional information/comments need to be added to the cards but they are frustratingly small.Sharp reported on a team which were forbidden to put anything up on the walls… so they used filing cabinets.
- Rather annoying if you have stack traces and extra information that will help fulfill the task.Also a lot of backlog items might originate from bug trackers such as JIRA. You want to be able to
- If it’s a large team then using physical cards and walls can get unwieldy…. Perhaps its an indication that the team is too large.
- It is often the norm nowadays that developers are not colocated therefore using software greatly enables all team members to be informed.It creates a level playing field for all team members.It also allows management to keep track of the project when they are travelling.It allows the team to take the status of the project with them when they attend meetings.
- Putting things in a decent software tool provides opportunities to do some analysis.Burndown charts allow you to see whether the team is keeping up with the backlog items of the sprint.The velocity analysis allows you to see what the optimal velocity of the team is.
- You can document lots of information on digital story cards:CommentsAttachments: mockups, stacktracesLinking into bug trackers
- Advanced tools tie into existing software systems such as your bug trackers…
- Because software can be inflexible you can land up subtasking to the extreme and putting in details because the software asks you.From my own experience using online tools, we migrated to a software tool and a few weeks later they had a major release which required a lot more fields to create the tasks… it quickly became a nightmare.It also allowed you to create trees of tasks which seemed like a nice feature but once we started using it – it became unwieldy.
- With one of the teams we worked on we had a software solution for our taskboard.However we realised we lacked a focal point for our standups. Also we couldn’t remember what was on the virtual board.We invested in a projector but this still did not work. Mainly because we could still not see the entire taskboard on the projector and if we zoomed out the cards were too small to read.
- We lose that tactile feeling.
- Some of these can be embarrassing and unexpected.
- In my own experience the best of both worlds approach has worked best.
- So instead of maintaining these in cards. Each new user story was maintained in
- Index cards and magnets are more effective than post-its.If you do use postits – buy the more expensive ones as they tend to stick longer and not fall off.Stickers can also speed up things and keep things neat. E.g. stickers for number estimates etc…
- We had our some of built in shelves removed so that we could have enough wall space.
- Neat handwriting, keeping cards clean and free of coffee stains engenders respect for the stories they represent.
- Basic needs for an Agile process could be:User story maintenanceTie into bug trackerVirtual taskboardImmediate response and updates when changes are made to the taskboardExport feature
- You want to consider a solution that can be integrated into existing bug trackers and software documentation system if possible. At the very least a new tool should complement the suite you are already using – not compete with it.
- The usability of software is key. You will be using this on a daily basis and you don’t want to get tied into software which is time consuming and difficult to use.Make a list of the main features you will be using on a daily basis.Then test these on the software and see how easy it is to change.You want intuitive and easy software. Consider those in your team who are not computer whizzes (in our case: data annotators).Give them a go on the software before committing. Run an informal user testing session to see how they get on doing the basics such as updating user stories.
- As I have shown in this talk there are a number of advantages and disadvantages when choosing a management solution to the agile process.Geographical location, colocation of team members, office space, management structure, sense of responsibility are all crucial factors in choosing a solution.In most cases there is a compromise to be had between maintenance cost and efficiency. You cannot impose a solution onto a team as it will never work effectively. Instead the team needs to come to a consensus as to what approach will suit them considering all the factors described previously.In my own experience I have found a hybrid approach quite effective.
- Its unlikely the solution you use will be perfect from the start. Be prepared to tweak it after 3 months.Don’t be afraid to move onto another tool if its not the right one for your team.But be prepared to compromise. Managing an agile process requires some investment of time to make it work but you need to make sure that you are not investing more than is required.
- There are many features in physical walls which developers like. The tactile nature of the cards, the visual element of the wall, the overhearing of discussion around the wall… If you intend to replace the wall then consider how you can enable the same stimulation and information flow within the software.For example:Instant messaging within the tool.Instant updates notified to team members.