�ݺ�ߣ

Editor's Notes

• #3: 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….
• #4: 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).
• #5: 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.
• #6: 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.
• #7: Daily work scenarioGiven vague specificationNot able to speak to customersBugs and small features interfering with main stream development
• #8: 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
• #12: Collaboration and coordination: 3 teamsRole of story cards: 1 team
• #15: 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.
• #16: How are real user stories collected or storedExcelAgile Software tool Project Management toolBug trackersPost-it notesCardsboard
• #18: How are real user stories collected or storedExcelAgile Software tool Project Management toolBug trackersPost-it notesCardsboard
• #21: 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
• #22: Software taskboard from agilewrap
• #23: 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
• #25: 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.
• #26: 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….
• #27: 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.
• #28: 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.
• #29: 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.
• #30: 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)
• #31: 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)
• #32: 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.
• #33: 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.
• #34: 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.
• #36: 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)
• #37: 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.
• #38: 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.
• #39: 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.
• #40: 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.
• #41: 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.
• #42: 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…?
• #43: 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.
• #44: 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
• #45: 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.
• #47: 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.
• #48: 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.
• #49: You can document lots of information on digital story cards:CommentsAttachments: mockups, stacktracesLinking into bug trackers
• #51: Advanced tools tie into existing software systems such as your bug trackers…
• #53: 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.
• #55: 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.
• #56: We lose that tactile feeling.
• #57: Some of these can be embarrassing and unexpected.
• #58: In my own experience the best of both worlds approach has worked best.
• #59: So instead of maintaining these in cards. Each new user story was maintained in
• #66: 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…
• #67: We had our some of built in shelves removed so that we could have enough wall space.
• #69: Neat handwriting, keeping cards clean and free of coffee stains engenders respect for the stories they represent.
• #71: 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
• #72: 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.
• #73: 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.
• #76: 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.
• #77: 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.
• #78: 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.