10 tips on how to prevent business value risk
One category of risk that project teams need to ensure they address is business value failure – delivering a product that fails to provide value for the business investor.
The content has been bookmarked!
There was an error bookmarking this content! Please retry.
Posted by Chris Sims on Feb 23, 2009
The Extreme Programming Yahoo Group has been discussing the pros and cons of low tech information radiators, such as task boards, compared to high tech tools. The original poster preferred a physical task board to a spreadsheet, but found himself unable to explain why to his boss. The ensuing discussion uncovered a variety of reasons to choose simple physical means of reporting information.
A task board is a specific type of information radiator, or big visible chart, that displays the flow of work. The task board shows which tasks are done, which are in-process, and which will be worked on next. The use of task boards has been made especially popular by lean software practitioners, who sometimes refer to these as kanban boards.
The term information radiator was coined by Alistair Cockbun, who described the concept this way:
An Information radiator is a display posted in a place where people can see it as they work or walk by. It shows readers information they care about without having to ask anyone a question. This means more communication with fewer interruptions.
A good information radiator:
- Is large and easily visible to the casual, interested observer
- Is understood at a glance
- Changes periodically, so that it is worth visiting
- Is easily kept up to date
Alistair goes on to say that information radiators are typically on paper and posted someplace where they are likely to be seen, such as the team room or a hallway.
The Extreme Programming community commonly uses the term Big Visible Charts to describe this same concept. Ron Jeffries described the idea this way:
Display important project information not in some formal way, not on the web, not in PowerPoint, but in charts on the wall that no one can miss....A web site doesn't push information at us; we have to go look. A slide show always comes with a meeting and a lecture. A wall chart is there when we are, in our face, always visible.
Milo, the originator of the current discussion thread on the Extreme Programming Yahoo Group, described a situation in which his boss questioned why he was using a task board instead of something like a wiki or spreadsheet. Milo found himself at a loss to justify his prefernce: "Why does a shared wiki seem more cumbersome? Are a few extra clicks between you and a spreadsheet really so much to ask?"
Over the course of the discussion, a list of pros and cons emerged for using a physical task board over an electronic one.
Pros
Cons
With regards to the version control issue, George Dinwiddie shared his experience working with a team that had this concern. He used a digital camera to capture the state of the task board. It turned out that the team never found a need to refer to the pictures.
Arnaud Bailly shared that he had tried using a large TV screen as an electronic task board, but felt that it did not work as well for the team. In examining why, he came to this: "Human beings have more than one sense, and need to connect mind and matter, eye and gesture. You just think and communicate better when you have something to act and focus on." Expanding on this, Dave Smith described the satisfying feeling that comes from getting up from the computer and moving a task card from in-process to done.
Milo's response: "I agree with this, and with Arnaud's statement about the human need to connect the senses. But are these things really that important?" In answer to which Ron Jeffries quipped, "Let me be sure I understand your question. You are asking whether human needs are important?"
Does your team use simple low-tech information radiators, such as task boards and burn-down charts, or do you use high-tech means. Leave a comment and share your experiences.
18 agile and lean practices for effective software development governance
A practical guide to choosing the right agile tools
In today’s hyper-competitive world, later may be too late to adopt Agile development and this Roadmap for Success will help you get started. Download "Agile Development: A Manager's Roadmap for Success" now!
"Let me be sure I understand your question. You are asking whether human needs are important?"
They are not important if the humans are mindless, valueless, robotic, drones. To be sure, there are managers who seem to think programmers are just that. There might be some few programmers who are striving to become that. However, as much as we try and as much as it is expected of us, we are still humans. We cannot be Spock. Hence human needs will be important.
It is always better to work with reality than against it. Reality doesn't care which you do. However, you will.
I vote for the sloppy, disorganized, white board, sticky note, in your face low-tech information radiator. After all, isn't it the agile way to do the simplest thing that works? What could be more agile? But...but...its not Agile. Who cares? Its agile that matters. Isn't it?
One of the things I like is that most people have a limited amount of wall space. Unused documentation sits orphaned on wikis or remote network locations. If a radiator is not used then it will be quickly discarded as someone else stakes a claim on the space. This also encourages people to garner re-use from documenation (i.e. different peeople gain different benefits from the same artefact).
My team started with just physical cards and a hand-drawn brndown chart about 2 years ago, but over time we have moved to keeping things in Excel, but also using that to create physical cards that are posted to a task board, and to update a burndown chart that is posted to the team room door every day. I just recently wrote a blog post where I animated the burndown chart from our last project, and it really helped other folks in the company understand what we were doing.
The post is at my blog on Los Techies and includes the movie, a description, and a link to the spreadsheet template that I use.
In my experience unless you're a really small team colocated you're going to outgrow the physical radiators pretty fast. Even the Scrum guru's will admit that as soon as you have a backlog that's reasonably sized, even a spreadsheet becomes unwieldy.
Reasons to go electronic....I'll just give 3 as I'd prefer to write my own post on this topic
You want/need to keep the history .. R&D Tax Claims for example
You are not colocated and as a result you can't all huddle around a whiteboard
Real-time updates as it happens i.e. more current
Bottom line is do what works best for you based on size of team, how you're geographically situated, size of project etc
My 2 cents
Jack
www.agilebuddy.com
blog.agilebuddy.com
One category of risk that project teams need to ensure they address is business value failure – delivering a product that fails to provide value for the business investor.
InfoQ spoke to the authors of Software Systems Architecture on a couple of new topics, the System Context viewpoint and Agile, which have been added to the second edition.
Alex Papadimoulis discusses ugly code, where it comes from, how to avoid it, and how to get rid of it.
John Davies examines Visa’s architecture and shows how enterprises have architected complex integrations incorporating Hadoop, memcached, Ruby on Rails, and others to deliver innovative solutions.
Sean Comerford unveils ESPN.com’s architecture, what components are used and why, and the current changes the website goes through.
Are there repeated patterns of failure on Enterprise Agile Enablement efforts? Sanjiv and Arlen discuss Seven Deadly Sins to avoid when adopting Agile in an enterprise.
Erik Dörnenburg answers: What is Enterprise and Evolutionary Architecture?, discussing 4 issues: Turning strategy into execution, Ensuring conformance, Where do the architects sit? Buying or building?
Sean Cribbs explains what Map-Reduce and Riak are, why and how to use Map-Reduce with Riak, and how to convert SQL queries into their Map-Reduce equivalents.
5 comments
Watch Thread Reply