I’ve been researching the requirements and variations on the Product Owner Role for a client that I am assisting. Here is a small collection of links and notes.
Updated (Originally posted Nov. 18, 2005).
Agile Work consists of seven core practices. These practices form a solid starting point for any person, team or community that wishes to follow the Middle Way to Excellence.
In a training course I recently delivered, I tried a new simulation exercise. Using the game Sudoku, I divided the class into two groups: a group that would solve the game in pairs, and a group that would solve the game solo. My hope was that I would be able to demonstrate some interesting aspects of working in an agile team, particularly around communication and problem solving.
Agile Work requires a team to take work items from a prioritized list, break those items into small tasks and then execute those tasks inside of the timebox of an iteration. When first trying agile, many teams have trouble with the task breakdown done in the iteration planning meeting. Here are some hints and tips for making this critical part of the agile process more effective.
Last December, I wrote about a nice simulation exercise that can be done in a small group to demonstrate the difference between waterfall, lean and agile approches to work. I have now run this exercise approximately 40 times and I would like to share the results.
Yesterday, an important and interesting story passed through the scrumdevelopment yahoo group. It seems that a team was experiencing substantial pain using Scrum. This story shows an interesting and effective method of addressing that pain during a retrospective. Pete Deemer, who is Chief Product Officer of Yahoo!’s 700-person Research and Development organization based in Bangalore, India, tells the story:
I’ve written a few previous entries about the artifacts of Agile Work: the Work Item List (or Backlog), the Iteration Tasks, and the Record of Obstacles. But I’ve left the most important for last: the actual delivered final results.
The Process Facilitator has only a few key responsibilities. One of those is to remove obstacles that are preventing the team for completing its work quickly, effectively and with high quality. The team’s primary tool for tracking this work is the Record of Obstacles. Like the Work Item List, this is a fairly simple artifact.
I recently described the Work Item List. The second type of artifact used in an Agile Work environment is the Task. At its most basic, a Task is a simple description of how to do some bit of work towards completing an item in the Work Item List. However, there are some important things to remember when using Tasks.
I’ve created and published a new cheat sheet for Agile Work on running retrospectives. It’s basic information, but it is a nice one-page reminder of two methods of doing a retrospective, things to consider, and how it fits into an Agile Work environment.
Jeff Sutherland has written a very good summary article of the benefits of the three questions asked in a team’s daily status meeting.
On the Retrospectives Yahoo Group, Michael Webb posted a link to his article Eight Barriers to Effective Listening. This article provides practical advice on how to improve communication. Since one of the basic practices of Agile Work is to maximize communication, this article is essential reading!
The topic of prioritizing requirements came up in a recent meeting. Often the customer will say that all the requirements are top priority and are unwilling to place priorities in individual items.
Sometimes an agile team is innundated (or maybe just slightly distracted) by requests for individuals on the team to do work for people or groups outside the team’s official stakeholders. This can happen, for example, in a corporate culture that promotes the exchange of favors. This past weekend at our Agile Coach’s gathering, Deborah Hartmann shared her method of detecting, exposing and discouraging this unofficial work.
In Jean Tabaka’s new book, “Collaboration Explained : Facilitation Skills for Software Project Leaders