I've spent a good amount of time in the trenches as scrum master in the past. It's not a job I relish and one which requires a unique set of skills (and a high level of continued motivation) to pull off successfully. But similarly to the suggestion that everyone should spend at least a little time in the service industry (e.g., being a waiter, running a cash register), everyone in tech should spend a little time as a scrum master or similar role (some on smaller projects than others ;). This position affords the rolee, if you will, with a unique perspective of seeing all aspects of product delivery from cradle to grave. In this role, one of the largest challenges is being able to effectively communicate the big picture of the project throughout a project while still facilitating the development of user stories and individual tasks at a very low level. With a product backlog, the user stories themselves, and the developers working on them, can lose touch with the big picture as they're thrown into a large bag and prioritized by feature value (the user stories, not the developers). I have experienced this in the past and have wondered what I could have done as scrum master to effectively add "the big picture" to the product backlog.
New ideas are circulating suggesting that the scrum backlog should be converted into a story map which keeps stories well organized within the big picture while allowing a team to focus on activities which will "deliver the highest amount of value in the shortest amount of time" (a common mantra of agile development). I strongly encourage anyone involved in agile development, especially those of you using the scrum methodology (which is most of you in the agile world), to read the new user story backlog is a map which I found on InfoQ.com. As we know, every project requires its own unique set of process tools to get the job done; this is a pretty good one to add to the toolbelt.
02-18-2009 9:46 AM