As software developers we have this innate belief that another tool will solve all our problems. To that end many agile practitioners search for a tool to track their projects for them.
However in using a tool we miss the benefits of cards posted on a whiteboard/corkboard in a public place.
Let’s compare the options
| Whiteboard/Corkboard | Electronic tool |
| Daily Standup in front of a board keeps the team focused by reminding team members what the stories and tasks are. | No screen is large enough for team members to stand around and read during the standup. Team members interact with a tool not each other. |
| Team members can update their progress by moving a card or changing an estimate. | You must login in to the tool and find the task/story to make changes. |
| Anyone walking past the team area can instantly tell the status of the sprint and project. Since team members see the board frequently road blocks will be quickly spotted. | You must login to see the status of the sprint/project. |
In short the whiteboard/corkboard promote conversations and collaboration among team members. If your management insists on seeing pretty reports and charts on their computer then challenge your management.
- These reports are waste – they don’t get shipped to the customer.
- Invite management to visit the team room on a regular basis and see the progress themselves.
- Have daily Scrum of Scrums that management attends so they can get their status fix that way.
If all else fails then treat these reports as an impediment that can’t be removed. Insulate the team from it – don’t force them to use a tool just because someone else wants a report. Instead as ScrumMaster/Facilitator generate the report from the taskboard.
Distributed/Dispersed teams (ie no shared physical environment) are the only time where I see a good argument for the use of tools. Even then I would try the simplest possible solution first: Google spreadsheets. It allows everyone on a team to collaborate on editing a spreadsheet at the same time.
Update: I should’ve stated my conclusion more clearly. Electronic tools work can be made to work, however I believe that you’re giving up an opportunity to foster interaction and collaboration among your team members.
Mark Levison has been helping Scrum teams and organizations with Agile, Scrum and Kanban style approaches since 2001. From certified scrum master training to custom Agile courses, he has helped well over 8,000 individuals, earning him respect and top rated reviews as one of the pioneers within the industry, as well as a raft of certifications from the ScrumAlliance. Mark has been a speaker at various Agile Conferences for more than 20 years, and is a published Scrum author with eBooks as well as articles on InfoQ.com, ScrumAlliance.org an AgileAlliance.org.
I get your point but somehow I don’t really agree. Because there is one component that seems very important to me in Agile Methodologies and that too many people forget about: constant feedback. Whiteboards are fine to track what is going on, but they are not enough to track what happened in the past and what should be done about it. It’s not just the management, it’s the Scrum Master himself who needs “pretty reports and charts” to make process adjustments. Think of the burn-down chart, velocity values, or even advanced metrics like evidence-based scheduling (https://www.fogcreek.com/FogBugz/LearnMore.html?section=PredictShipDates): if you have to do all of this manually, then you’re adding another impediment to the task of the Scrum Master. And electronic tools can do that for you.
Now of course it’s all a matter of balance and trade-off, as always. But I think that the more natural tools become, the more powerful they are likely to be. Just think of what you can do by combining a projector, Mingle (https://studios.thoughtworks.com/mingle-project-intelligence) and this WiiMote hack (https://www.youtube.com/watch?v=5s5EvhHy7eQ&eurl=https://www.cs.cmu.edu/~johnny/projects/wii/).
Thanks for the post. For sprint planning meetings with the client, what do you suggest using so that everyone is looking at the same information (i.e. where do you keep the product backlog)? Also, what are your thoughts on the client having access to the project status (at all times) as long as they have the understanding that once a sprint starts they cannot change things? Thanks!
I think I have to join Sebastien Arbogast in disagreeing.
We are using Jira for both backlog and task list. Even though Jira isn’t made for Scrum we have managed to use it quite successfully so far.
we have been using scrum as a method for nearly 8 months now, without a status board, and have just resently created a digital scrum status screen that shows us the status for each individual task within a story.
As the part where you have to log in to make changes, that is not quite true. This beeing an internal tool, we do not have to restrict access to the status board. (the sales department is unaware of the existence of this tool 🙂 )
The use of wiimote either to track a IR pen or to point on the screen from a distance can also help us change the status of issues onscreen.
Jira has a webservice we can access from our status screen backend, making updates nothing more than a few hours of work to implement.
Everything is possible, we just have to figure out what is right for us and do it.
As for the no screen is big enough part: How much information do you need at any given time. A short issue summary can fit onto the screen for all issues, with a mouseover/click to show the entire issue status.
The scrum status display is not a replacement of daily scrum meetings, it is an addition. It also helps remote developser to be a part of the team by joining the daily meetings by either phone or webcam.
Andreas
I agree about reports as waste if you have only 1 goal of shipping product to the customer. But if you want to build good team (and company) you will need to gather some data to improve development process with the time.
P.S. Picture and table are very badly aligned: I could read it in RSS but can’t do it on the web (too much ads)
We use a combination approach where I work. During the week, we write hours on the whiteboard, but at the end of the week the story tracker puts them into XPlanner, so that in theory we can track metrics. We actually don’t use XPlanner that effectively, but it’s good to know the data is there.
I really like having the whiteboard, for the reasons you mention, and also the act of writing the numbers on the board always makes me feel more accountable. There’s also the process each week of deciding how to divide up the columns on the whiteboard for tasks, and the constraints of the whiteboard are nice there, because it forces you not to be overly parallel.
We are using electronic tool for more than one year. We use historical data to get better estimation of the next sprint. We can easily compare stories size. Our product owner uses the same management tool as development team use. She is very easy able to collaborate directly with team members. Moreover she doesn’t need to be personnally at daily scrum meeting. I cannot imagine how can distributed teams collaborate by using a whiteboard only. Electronic tool make such collaboration easier and “live”.
Another advantage is an integration with other tools. I mean version systems, bug tracking, project homepages (wiki).
The first version of this tool fully support “no login and go” principle. We had a case when product owner required a protection of his ideas and requirements. So that’s the reason why we started to use a login.
I think, that it is not necessary to learn how to interact with tools. You can use intuitive tools instead. Try to look for example on https://www.scrumdesk.com. Basically it’s desk with story cards, burndown chart and next sprint stories.
Sebastien and Qrilka – I used to think the same way myself. However a well used whiteboard can easily have all the previous iterations to the left and backlog to the right of the current story. So we can have all the history we want.
In addition I’ve never seen the scrum master find a useful nugget buried in the history. When it comes to improvement I usually think the team already knows what it needs. The problem as facilitators is helping them discover it.
Robert – typically we hold sprint planning meetings in front of the white board. In one case where that didn’t work we moved the white board to the room where planning occurred.
As for clients having access to the sprint status – brilliant. As long as it doesn’t come at the expense of the team. If you can find a way of doing it that doesn’t burden the team or inhibit conversation then go for it.
Andreas – I’m not saying you can’t make electronic tools work. I’m just saying that you’re giving up an opportunity to foster interaction and collaboration among your team members.
Dusan – we certainly agree that electronic tools are useful for distributed teams. The question I ask is “Do you really know what you gave up when you started using a distributed tool?”.