Comments on: Tools, Tools, Tools

By: Sebastien Arbogast

Sebastien Arbogast — Tue, 30 Nov 1999 00:00:00 +0000

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 (http://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 (http://studios.thoughtworks.com/mingle-project-intelligence) and this WiiMote hack (http://www.youtube.com/watch?v=5s5EvhHy7eQ&eurl=http://www.cs.cmu.edu/~johnny/projects/wii/).

By: Robert Dempsey

Robert Dempsey — Tue, 30 Nov 1999 00:00:00 +0000

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!

By: Andemann

Andemann — Tue, 30 Nov 1999 00:00:00 +0000

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

By: Qrilka

Qrilka — Tue, 30 Nov 1999 00:00:00 +0000

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)

By: Mark Levison

Mark Levison — Tue, 30 Nov 1999 00:00:00 +0000

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.

By: Mark Levison

Mark Levison — Tue, 30 Nov 1999 00:00:00 +0000

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.

By: Mark Levison

Mark Levison — Tue, 30 Nov 1999 00:00:00 +0000

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.

By: Steve Howell

Steve Howell — Tue, 30 Nov 1999 00:00:00 +0000

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.

By: Dusan Kocurek

Dusan Kocurek — Tue, 30 Nov 1999 00:00:00 +0000

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 http://www.scrumdesk.com. Basically it’s desk with story cards, burndown chart and next sprint stories.

By: Mark Levison

Mark Levison — Tue, 30 Nov 1999 00:00:00 +0000

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?”.