« May 2006 | Main | July 2006 »
June 30, 2006
Agile Project Engagement Roadmap
(Parts of this posting were adapted from an email written by my business partner, Dale Kiefling)
We recently had the disconcerting experience of having a client cancel our engagement because they'd felt that we weren't being agile enough. In hindsight there were a number of reasons why this might have happened but I think the most important one was simply that we did not provide a clear overview of the engagement. This meant that the client was confused about the value of what we were doing. I myself am confused about how the situation arose. I thought we had been very clear but obviously that was not the case.
In our practice we typically combine a discovery phase and a prototyping analysis and design phase. What some people in the agile world might call iteration zero. For our client this discovery seemed open ended and they didn't have a clear understanding of how it fit into the project as a whole. This was a communication failure on our part. The process of discovery can indeed feel open-ended as it is the very nature of discovery to explore the domain of the business opportunity in an open way. The purpose of this "openness" is to find the appropriate scope, workflow, practical boundaries, and hidden benefits in an exploratory and visual manner.
The primary advantage of doing this work at a high level early on in the process is that it is much easier and cost-effective to identify boundaries and priorities on a whiteboard rather than during the construction phase or even during prototyping. We should have done a better job explaining this prior to our first discovering meeting which might have helped our client better understand our process and purpose. We also never really established a timeline beyond having one or more discovery meetings which may have added to their confusion.
Let's chalk this up to another lesson on the importance of managing client expectations.
Posted by David Chilcott at 01:16 PM | |
ScrumMaster Training in San Diego - Jul. 6 + 7
An excellent, experienced coach that I have had the priviledge of working with is giving a class in just a few days. He has spots left, and I highly recommend taking the class from him if you can schedule it. The details for his ScrumMaster training are here.
Posted by Mishkin Berteig at 12:28 AM | |
June 23, 2006
Managing "Leaderful" Groups
In agile development circles self-organizing teams are all the rage nowadays. And I often hear people bemoaning the "evil managers". And no doubt in many circumstances and organizations there is real work to do here and real dysfunction to resolve. But I'm less concerned with the analysis of what's wrong and more concerned with what can we do differently and better. IE: How can we develop the skills necessary to practice effective self-organization.
So what does it mean to be a participant in a "leaderful" group?
The implication of "leaderful" is that many or most of the people in the group are exercising leadership. It seems that leadership is necessary, humans can't engage in group activity successfully without leadership. Successful group action always requires leadership and leaders. Someone, at least one person, must think about the effort as a whole and not only about her or his individual role in it in order for the group effort to succeed. A group can have more than one leader, but must have at least one to function successfully. Leadership is thinking about the well-being of the group as a whole as well as that of the individual group members. The essential commitment of a leader is to see to it that everything goes well.
I assume that leadership is an inherent capacity of every person and that leadership is not a "special" role or activity only for "special" people. The skills of successful leadership can be taught, learned, mastered, and practiced.
Further, I assume that people are fundamentally peers and that we are all doing the very best that we can at the moment. So the question becomes how do we reconcile assuming leadership with our peers? And how do we support each other in developing our leadership skills together?
More on this later...
Posted by David Chilcott at 04:58 PM | |
June 22, 2006
The Trouble with Consensus
A friend of mine, Bettina Grassmann, has written a very insightful short piece on consensus called "Consensus Killed the Cat". I have a few additional comments to make to connect what she has written with Agile Work.
In my work I am frequently working with self-organizing teams. This problem with consensus comes up frequently. One of the best solutions to the problem is to have a very clear long-term goal or vision that everyone agrees to. In corporate environments, this is usually imposed. In a coop or other volunteer situation, it can be difficult to articulate this goal, but the effort in getting there is worth it. Once the goal is in place, it is (relatively) easy to get consensus on decisions if they are relevent to the goal. If the group is trying to decide on something irrelevent to the goal, then again consensus is very difficult, mostly because the decision "doesn't matter".
Posted by Mishkin Berteig at 02:26 PM | |
June 19, 2006
A Ninth Barrier to Effective Listening
I provided a link in a previous entry to an article about eight barriers to effective listening. Well, I was recently talking with someone about this and he pointed out a very important ninth barrier to effective listening.
The Ninth Barrier to Effective Listening
Exhausted, sleepy, tired, spent, wasted, enervated, asleep.
This is not rocket science folks. If you are too tired to listen to what others are saying, then you can't listen effectively regardless of the existence or lack of the other eight barriers.
In the courses I run, I always remind people to get a good sleep so they can be alert for the course. It is wasteful of their time to be unable to concentrate or even actually falling asleep. I do my best to make my course interesting and active, but I know myself that if I'm tired, no matter how interesting the material, I can't learn it.
For myself, I don't drink caffienated beverages regularly. Why? So that I can use them as "emergency fuel" when I really need them. It sometimes happens that I can't get to sleep at a decent hour before an important meeting or a course I'm delivering or some important reading I need to do. Caffiene helps, but only if I'm not using it regularly.
Posted by Mishkin Berteig at 11:45 AM | |
June 15, 2006
Upcoming Agile Training and Certification
Agile training including ScrumMaster Certification, Introduction to Agile Work and Adult Learning for Agile Coaches. Toronto, Edmonton, Calgary, Ottawa, Beijing. Reserve your spot on the schedule of public agile courses offered by Berteig Consulting Inc.
The Berteig Consulting agile training courses are designed to help the attendees of the course learn about agile methods, make the needed mental shift towards agile concepts, and start the change in their habits of behavior. We do this in the following ways:
- Extensive simulation and discussion exercises to practices and investigate core agile principles and practices
- Opportunity for participants to see agile methods modeled (demonstrated) by the instructors in the running of the training course itself
- Several "Aha!" exercises designed to viscerally affect attendees' mental models and kick-start the shift to agile thinking
- Full disclosure of the difficulty of implementing agile methods and the radical change of thinking and habits required
- Reflective exercises about the learning process itself so that the attendees learning needs are dynamically met during the training course
- And of course, sufficient time for in-depth coverage of the materials so that most questions about agile methods, agile practices, agile experience and agile principles can be answered
Posted by Mishkin Berteig at 12:01 AM | |
June 14, 2006
Agile Work Artifacts - Tasks
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.
What is a Task
Normally, an item from the Work Item List is broken down into multiple Tasks. These Tasks are all the things that need to be done or built to get the item into a deliverable state.
In general, the process of creating a bundle of Tasks for a given Work Item is a design or analysis process. It is a problem-solving process. The Tasks themselves represent the solution: the building blocks of the structure of the Work Item. Tasks do not normally represent the problem solving or analysis process.
Here are two contrasting (somewhat contrived) examples of Tasks generated for a "Home Office Addition" to make this clear:
Example 1 Bad:
- determine requirements for home office
- design home office layout
- check home office layout with client
- choose furniture and decor
- build home office
- install furniture and decor
- unpack books and files into home office
Example 2 Good:
- 300 sq. ft. maple hardwood
- 4' x 7' custom desk
- Aeron chair
- red leather sofa
- 16' custom bookshelves
- 22" double French doors
- 8' 4-panel vinyl triple glaze bay window
- 36 2x4x10' metal studs
- ... drywall
- ... other building materials and furniture and decor
Generating Tasks
The whole team works together to come up with the Tasks for every Work Item being worked upon during the iteration. The majority of the Tasks are determined during the timeboxed iteration planning meeting. Sometimes, the iteration planning meeting is not long enough to get all the Tasks defined. Sometimes new Tasks are discovered during the course of the iteration. Either way, it is fine to make changes to the bundle of Tasks as the work proceeds.
Special Tasks
Due to the timeboxed nature of the iteration planning meeting, a Team will sometimes find itself knowing that there is more analysis or problem-solving needed for a given Work Item. In this case, a special Task can be created to indicate that this analysis work needs to be completed. For example, the task might be labled "Finish analysis for Work Item 62", or it might say "Team meeting to finish Task generation for Work Item 62". Other ways of writing these Tasks include "Research...", "Solve..." or "Discuss...". Everyone needs to recognize that these tasks represent risk and uncertainty about how to get the work of the iteration complete.
Sometimes work needs to be done that is outside of the control of the Team. The Team should always try to find creative solutions to avoid this situation, but it is almost inevitable that Tasks will come up for which the Team does not have the expertise or the authority. These Tasks need to be treated very carefully since they can seriously hinder a Team's forward progress. The Process Facilitator should usually consider these Tasks as obstacles to be removed.
Working on Tasks
Typically, a single person takes responsibility for a single Task at a time. A person may end up working on other tasks for two reasons. First, if the Task he/she is responsible for has an unavoidable wait, then that person may go find someone else to assist until the Task is ready to be worked on again. Secondly, another person may have an urgent need for assistance and call other people away from their current Tasks.
Tracking the Work
In their most basic form, Tasks are assumed to all be roughly the same size or effort and small enough that they are only done or not-done. Therefore, tracking the work on the Tasks throughout the course of the iteration is kept very simple: how many tasks are remaining to complete in the remaining time of the iteration? There is no ambiguity: Team members report on completion of tasks to the Process Facilitator who updates a burndown chart to show the quantity of remaining work.
Gotcha's
Tasks must be written to avoid including wait time. For example, a Task that says "Get the parts delivered" actually includes three steps: make the request for the parts, wait for the parts to be delivered, receive the parts. Since it is often hard to predict how long a "wait" will be, it is important to break this down into two separate tasks: "order the parts" and "receive the parts" and then treat the wait time as an obstacle to be removed/minimized.
Posted by Mishkin Berteig at 09:34 AM | |
June 13, 2006
Fantasy Estimation
In software development (and in many other types of projects), there is a typical non-agile approach to estimation of project size. This method starts with a high-level understanding of the work to be done, the requirements, and uses that to make an initial estimate of the project size. This estimate is often stated in units such as man-months. There is a very important piece missing here that makes this estimate completely useless... that makes it pure fantasy.
The Team
Any estimate made by anyone other than the team doing the work is useless. For any sort of project, software or otherwise, estimates made by a project manager or leader on behalf of an existing, or, even worse, a non-existant team, must be subject to the highest degree of scepticism.
Team Maturity
Not only does the team need to make the estimates for its own work, but the team must be mature! If the team is newly-formed, the team members will have no sense of the team's capacity other than their own individual capacity.
Work History
Not only must the team be mature to make reasonable estimates, it must have a recorded history of their own work capacity in order to be able to estimate their capacity to do work in the future. If there is no record of their capacity, then the usual factors of optimism will be unaccounted for, and the team will almost always over-estimate its capacity.
Knowledge of Domain and Tools
Not only must the team use a recorded measure of their capacity, but they also must be experienced with and knowledgeable of both the subject of the work and the tools they will do to perform the work in order to come up with a reasonable estimate of a project's size. If they need to learn about the project and how to execute it, then again, the team will almost always over-estimate its capacity.
Fantasy
If someone gives you an estimate for project duration, ask them the following questions:
1. Was this estimate made by the team which will actually be doing the work?
2. How long has this team worked together?
3. Has this team measured their own actual capacity and used that measurement for this estimate?
4. How well does the team know the domain and tools to be used?
If the answers to these questions are unsatisfactory, then the estimate is pure fantasy, it is a lie.
Posted by Mishkin Berteig at 09:06 AM | |
June 09, 2006
Agile Work Cheat Sheet - Retrospectives
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.
Posted by Mishkin Berteig at 01:00 PM | |
June 08, 2006
Interview with Alistair Cockburn - Agile and House Renovations
Alistair Cockburn is the author of several important books in the agile software development literature including Agile Software Development
AA: Could you please provide me with a 3 or 4 sentence blurb about yourself?
Alistair: Armed with a B.S. in Computer Engineering (note the "engineering" in the degree ;-) and M.S. in Computer Science, I spent 8 years designing high-speed, custom computer graphics hardware, largely at Evans & Sutherland, the next 8 years in IBM Research researching the way people specify and test communications protocols, and the next 15 years consulting around object technology software and methodologies, starting at the IBM Consulting Group in 1991.
I got my doctorate from the University of Oslo in 2003 on the basis of my interviews with projects in the early and mid 1990s. It was on "People and Methodologies in Software Development." I was really proud about getting the word "people" into a doctoral dissertation in the Informatics / Computer Science field.
These experiences led me to help write the Agile Manifesto in 2001 and the PM Declaration of Inter-Dependence in 2005. More about my personal side is exposed in my answers to the infamous "Proust Questionnaire" and on my website, Alistair.Cockburn.us.
AA: How did you apply agile methods to your home renovations?
Alistair: Many people argue about whether house construction it is or isn't like software development. I have been making extensions to my house for several years. You can imagine that I would like to make a house extension incrementally, using a venture-capital funding model, and in a close collaboration with both the architect and construction contractors, exactly following the agile model.
In our first conversation, the architect suggested creating a "master plan" of all the desired changes, then doing the work incrementally. I declined, because I was pretty sure that we would change too much for the initial plan to have meaning by the half-way point, and it would end up being a waste of my money. As it turned out, I was correct.
We ran each idea as a stand-alone project, but were careful to ask at each key moment, "If we were to extend in [some particular way] next year, how would that affect our decision now?" Surprisingly, we found no cases where the future choice affected the present decision.
Our first project was to put a basement under our house. (I have fun with this ... people tell me that it is normal practice to build the basement first; then I get to say that we agile folks like to sequence features in business-priority order, so who knows, the basement may get put in last!). Anyway, it turned out to be easier than expected, because our house is built on short stilts (to provide an insulating air cushion over the ground). This probably wouldn't have mattered, because the construction people are used to putting basements under existing houses under normal circumstances.
Rather than excavate the whole basement, we decided to excavate only 1/3 of the basement. This gave us the basement entrance we needed, and left open the question whether we would extend the excavation or build a side wing in the next project. We learned that there would be no cost savings for excavating more than we needed now, even if we chose to expand the basement later. The XP community calls this the YAGNI principle, for "You Aren't Gonna Need It". We excavated only what we needed. Three years later we still have no plans to extend the floor space, either above or below ground. YAGNI is holding.
The next part of the "agile" story was watching the architect and the contractor work out how to hold up the house while they excavated. The architect looked underneath the house and launched into a dissertation on the various choices. The contractor cut in with, "Why don't we just run a giant beam right down the center and hold the whole thing up while we excavate?" Note here the application of the 11th principle of the agile manifesto: "Simplicity - the art of maximizing the amount of work not done - is essential." The architect adopted the suggestion, and after that, the architect, the contractor and the construction crew had excellent conversations that merged their best ideas with. To this day they always trade construction ideas back and forth along with how those might change the design of the house itself.
The next thing is illustrative of the relationship between construction and software development. On the first day of construction, they knocked a hole in the concrete wall where they were going to excavate, peeked in, and discovered that the beams under that part of the house ran perpendicular to those where they had looked under the house. This ruined their plan for the support beams, and showed that once again, civil engineering is ahead of software engineering. I find that it usually takes software teams a week or two to invalidate plans. These people were able to do it within two hours!
As we progressed I quickly noticed that the contractor kept changing his "fixed-price" bid for the project as new information appeared. I finally suggested we drop the "fixed-price" facade, and just work to time and materials. His reply surprised me: "If you are willing to carry the extra risk, that will be fine with us." I said, "I don't see any extra risk. You'll just change the price whenever something changes any-way." He said, "That's true but most people don't recognize that." In exchange for my accepting the "extra risk," he lowered his profit margin from 13% to 10%. We each felt we had benefited from this change.
With the new contract in place, his crew was able to do any number of other small projects for us, such as changing the kitchen counters, adding closets, and fixing the fence around the yard. Neither these, nor the other usual surprises, twists and turns on the project worried either of us any more.
I noticed with some interest that he and his crew held a daily stand-up meeting each morning to set their day's work goals. In this short meeting, they checked that they knew what they were working on, and had the materials to get it done.
The project came to a successful conclusion, and we gave a small bonus to the contractor and the workers. Unbeknownst to me, our prompt payments made us "preferred customers," which proved useful for the next projects.
We then did a second project, to sculpt the yard, move in stone slabs and do some general landscaping. Although this was considered a "minor" project, the contractor was delighted to help. He sent digging and moving crews to help when we needed it, and even operated machinery when his key men were ill. This was part of us being preferred customers, a roll-forward benefit from the first project.
We're on a third project, to add a fancy porch to the side of the house. At this point, we are glad not to have done a "master plan," because what we have in mind for the changes to the front porch are completely different from anything we had originally had in mind.
By now, there is trust and good communications between the architect, the contractor and us. The small wins with reflection, the venture capital funding model, the willingness to dance with the situation, are all paying off. The contractor passed along our preferred customer rating to his suppliers, so we got extremely fast service. He also took it upon himself to see that they give us good rates, so we saved money. Since we contracted by time and materials, it is natural to have the subcontractors do additional projects around the house as we need. The final bill for all this extra work has been much lower than it would have been had we contracted each one separately.
The point of this long story is to illustrate how the lessons from agile software development transfer to a completely different field. Incremental development, architectural changes, daily standups, YAGNI, time-and-material contracts, venture capital funding, customer involvement and steering, small wins, process miniature, and developing collaboration and trust - each of these proved useful.
(The above story is an extract from the forthcoming 2nd edition of "Agile Software Development", celebrating the 5th anniversary of the writing of the Agile Manifesto.)
AA: You have a great deal of experience using agile methods in a software context. How did you get the idea to apply agile methods to your renovation project?
Alistair: It is more the other way around: After interviewing successful projects for over a decade and seeing how incremental development and close collaboration make such a difference in project outcome, it would be hard for me NOT to apply agile methods to any project at all. I even tried it with conference organization (the Agile Development Conference in 2003 and 2004) – agile techniques didn't help us much on the first year (a conference is a one-pass, big-bang integration project if there ever was one), but they helped a great deal the second year.
Also, since we were spending our own money, the venture-capital funding model made sense.
The rest I just made up along the way, kind of as an experiment to see if it would work. I was surprised at the way YAGNI held up and pleasantly surprised by the really positive roll-forward of the close collaboration, communication, community, morale issues.
AA: Your family were also stakeholders in this project. How did they react to the lack of long-term planning, the lack of a master plan for the renovations?
Alistair: My wife has a harder time than I do with the notion of "build a little and then let's live in it and see what we need next" Her difficulty is not with completing one project at a time, as we did in the house, but in the garden, where I want to make steps and paths out of plywood and dirt and "feel how we use them" before committing to a design.
On the other hand, she is at least as good as me at taking last-instant advantage of serendipitous information. For example, we had an excavator ready to flatten a section of the yard, and he asked where he should put the dirt. I suddenly had the bright idea of building a mound in the yard. She saw it immediately, and in the next 30 seconds the two of us sketched out a first-cut redesign of that section of the yard based on the presence of a mound, sufficient for the bobcat operator to start moving dirt. (She then went and made a sculpture of the yard out of play-doh to serve as his spec!)
AA: Many agile methods include the concept of a timebox for planning and delivery which is used to provide formal feedback and adjustment points with stakeholders. How did you accomplish this feedback on your renovation project?
Alistair: Timeboxing didn't work for us, because we were subject to the really varying hours of the contractors – lots accomplished one week, nothing the next. We're small fish and they have bigger contracts to fulfill. So we had to / have to sometimes make do with leftover scraps of time.
However, we have an "on-site customer," so we have no trouble giving feedback. And since Deanna and I are willing to make adjustments in design really quickly, we can change direction in minutes. There were several times when they ran into some sort of obstacle, and we ran around for minutes or days (if the architect wasn't on-site at the time) drawing different drawings, checking prices and materials and designs, and then changing directions.
They had ordered tan planks of the Trex material for the porch, and it was sitting on the ground ready to be nailed in place. Neither Deanna nor I really liked the color. I was online looking for aluminum railings, and ran across a Trex site that listed many more colors than they had told us were available. I printed out the sheets, ran downstairs and showed everyone, and we changed to a burgundy color that day. It delayed the schedule a whole day.
With respect to financing, we were paying time-and-materials, so we could stop or delay the work at any time. (We still haven't figured out how speed work up, of course!)
AA: What was the biggest challenge you had to overcome in adapting agile practices to this project and how did you overcome the challenge?
Alistair: None come to mind. We used agile practices from A to Z easily and profitably.
AA: What aspects of agile methods did you _not_ apply to this work? What thoughts do you have about applying these missing methods to future work of this sort?
Alistair: Test-first design doesn't apply, as far as I can tell. Timeboxing didn't apply, in our case. I can't think of anything else.
AA: What part did trust and truthfulness play in your renovation project?
Alistair: Lots, all described earlier in the project story. We're inviting the architect and the contractor to the open-house barbecue, because they are interesting people and we like them. We get preferred treatment from the contractor, who passes that on to his network of specialist contractors.
He sometimes has to warn his specialist contractors that we're unusually frank. We expect them to counter our ideas with their ideas, and vice versa. We ask for hourly prices up front (and if he thinks those prices are too high, he'll bargain the rates down for us) and tell them to expect changes in direction. He likes all this and helps the other contractors recognize we're not the usual buyers that they have to protect themselves from.
AA: How would you sum up the most important things you have learned from trying this?
Alistair: Collaboration, open communication, feedback. Work incrementally, so that the feedback within and from each increment can improve all of those on the next round.
Try to remain open-minded when adverse events drag you out of your good mood.
Keep looking for ways to improve collaboration, communication, feedback, then everyone's best ideas have the best chance of coming forward. With everyone kicking in their best ideas, you'll get the best ideas possible for the project.
David Anderson has a brief blog entry called Construction time Again that claims agile doesn't work with house construction.
James Shore has also weighed in about "That Damned Construction Analogy".
And I have to admit that even I have written extensively that The Construction Analogy is Broken.
Seems we're all wrong, but that's good as far as I'm concerned!
Posted by Mishkin Berteig at 11:56 PM | |
Twelve Games to Play With Your Customers
My associate Deb Hartmann who writes at VitalBrew let me know about a set of twelve "innovation games" to play with your customers. I have never used them, but in reading through them, they appear to be compatible to an agile approach to working with customers.
Posted by Mishkin Berteig at 02:32 PM | |
June 07, 2006
Updated 2 Older Articles: Agile Work Roles and Waste vs. Value-Added
The Agile Work Roles article has been updated with more detail about all three roles and some additional commentary and links. This is a useful article to share with people who have already been introduced to agile methods, particularly if you are having trouble with a command-and-control management style (by management or team members).
The Waste vs. Value-Added article has an extended quote from the book Lean Six Sigma : Combining Six Sigma Quality with Lean Production Speed
Update 20060608: added the second link!
Posted by Mishkin Berteig at 09:01 PM | |
June 06, 2006
Agile Work Artifacts - the Work Queue
Agile Work requires only a very small number of simple "artifacts". The most basic is the Work Queue. This is very similar to the Scrum Product Backlog but there are some differences too. The Work Queue is like a carefully managed To-Do list. This article details the use of the Work Queue.
Basic Description
The Work Queue is a list of work to be done by a person, team, organization or community. The list consists of brief descriptions of what to deliver, not how to do it. The list is prioritized so that the item on the top of the list is the single most important thing to get done, with items below that being successively lower priority. All items on the Work Queue contribute directly to an overall goal. The person holding the Product Owner role manages the list.
Place in the Process
The place of the Work Queue in the process is very simple. The Work Queue is initially created after the overall goal is determined. Ideally, it is created before work towards the goal is started, but often Agile Work will be adopted for an ongoing effort, in which case work has already started. The Work Queue is constantly maintained by the Queue Master so that it maintains the above mentioned qualities. One or more of the items from the top of the Work Queue are selected to be worked on. As an item on the list is completed, it is removed from the Work Queue. The number of items on the list that are being worked on simultaneously will depend on the capacity of the people doing the work. If iterations are being used to plan work, then the Work Queue is updated every iteration.
How is it Created/Managed
The Product Owner is responsible for creating and managing the Work Queue.
The initial creation of this Work Queue is a simple process: based on the goals to be attained, and based on an other factors that are relevent, the Product Owner drafts an initial version of the Work Queue. The time spent on creating this initial version should be minimized using three techniques:
1. Keep the Work Queue small by recording only high priority items that need to be done immediately. Don't add items that are uncertain or will be done far in the future. (See "The Horizon of Predictability" for more information about this.)
2. Keep the Work Queue simple by focusing on point-form high-level descriptions of the items in the list. Don't worry about any details about how the item will be accomplished, who will do it, when it will be done, dependencies with other items, or technical or conditional details.
3. In advance, allocate a fixed amount of time to draft the Work Queue... and don't spend any more time on it than that. Get the assistance of the Process Facilitator to keep on track. The list doesn't have to be perfect or complete... you only need enough on the list to allow the work to start.
Ongoing management of the Work Queue consists of removing completed items or items that are no longer needed, adding new items as they are discovered, merging or splitting items as more is learned about them, and reprioritizing items. All of these tasks can be performed at any time. As well, the Work Queue should always be in a state of readiness such that the top items are ready to be selected for work.
The Product Owner is responsible for answering any questions that may arise about the work as it is progressing. If someone doesn't know what is meant by an item, then work on that item should halt until the Product Owner can clarify.
At no time is the Work Queue "frozen" or finalized. It is changing throughout the entire time that people are working towards the goal. Items that are completed are removed from the list, and do not need to be archived or recorded anywhere else, nor is it necessary to save versions of the list as it is changed.
Gating/Queuing
The Work Queue is a queue of work in process (WIP) that is built up in front of the people who are doing the work. As such, it is advisable to keep the list short. The Product Owner acts as a gate to the list: only those things that reasonably contribute to the goal and which are relatively immanent in implementation should be added to the Work Queue. If someone suggests something be added to the Work Queue, the Product Owner must, of course, take that under advisement and collaborate with the suggestor, but is not obligated to add the suggestion to the list.
The Product Owner can manage the size of the Work Queue by deciding how many iterations of future work are allowed on it. In other words, the number of items on the Work Queue is limited to how many can be accomplished in a fixed number of iterations. As the Team takes a number of items off the Work Queue, space is freed to add an equivalent amount of work back onto the Work Queue. The specific number of iterations chosen for this will vary depending on your circumstances.
Differences from the Scrum Product Backlog
The Work Queue does not require two things that are part of the Scrum Product Backlog: item estimates and item values. Adding this information to the Work Queue can be useful in many situations, but is not an essential part of the list.
As well, the management of the Work Queue is different from the Scrum Product Backlog in that the Product Owner is not obligated to put every suggestion that comes their way onto the list.
Advanced Use of the Work Queue
Consider adding the following information to each item on the list:
1. An estimate of effort. Make sure that these estimates are created by the whole group of people who will be doing the work.
2. An estimate of value. The Product Owner needs to be responsible for determining value, but the whole group of people doing the work and all the other stakeholders need to understand how that value was determined.
3. Cycle time tracking. When an item is added to the list, record the date/time it is added, then record the the date/time it is completed and removed from the list. The use of cycle time can assist in making a work process more efficient.
Posted by Mishkin Berteig at 04:24 PM | |
June 05, 2006
Good Intro to the 3 Questions in the Daily Team Status Meeting
Jeff Sutherland has written a very good summary article of the benefits of the three questions asked in a team's daily status meeting.
Posted by Mishkin Berteig at 04:13 PM | |
June 02, 2006
Cueing Agility - Creating a Supportive Environment for Agile Teams
In Blink : The Power of Thinking Without Thinking
In one experiement, researcher John Bargh designed a scenario to test how sensitive we are to written cues that are structured in a way that we are not consciously aware of being cued. Bargh created two lists, each composed of five words per list item. Of the five words, four were chosen to form a sentance, and the fifth word was selected so that it would not fit with the other four. Then the five words were jumbled.
For example:
rang phone peace the loudly
The people who came as subjects of the experiement were given one of the two lists and told to go through their list as quickly as possible and un-jumble the sentances.
Unbeknownst to the participants in the experiment, each group of five words also contained a word that was selected to suggest a feeling or attitude. In the first list, each group of five words contained one word that would suggest impatience, rudeness and aggressiveness. The second list contained words to suggest patience, politeness and calm.
All the subjects of the experiment were also given additional instructions to come to a particular office once they had completed their lists. At the office they were to receive final instructions. At the office, each participant encountered the experiment administrator deep in conversation with another person. Neither the administrator nor the other person acknowledged the just-arrived subject. Now the real purpose of the experiment was tested: how long would the subjects wait before interrupting the ongoing conversation?
The results were astonishing: those people who were cued with the list containing words suggesting impatience, rudeness and aggressiveness
eventually interrupted - on average after about five minutes. But of the people primed to be polite, the overwhelming majority - 82 percent - never interrupted at all. If the experiment hadn't ended after ten minutes, who knows how long they would have stood in the hallway, a polite and patient smile on their faces? (p 55)
Gladwell gives several more similar examples in his book. I strongly recommend reading this book to see just how powerful this cueing or priming effect can be.
For organizations, teams and even individuals, this effect can be harnessed. The most obvious ways include using posters, screen savers, banners etc. to constantly impress people with positive messages about teamwork, effectiveness, creativity and other values and qualities that might be deemed valuable. This should obviously go hand-in-hand with a conscientious removal of all negative messages.
For agile teams, there are some particular values that should be emphasized: truthfulness, courage, creativity, teamwork, trust, cooperation, hard work, learning, adaptability.
The message can also be communicated in more subtle ways - and this is actually likely to be more effective! Incentives, the power of exemplary behavior, and the physical environment itself all can contribute strongly. In Built to Last : Successful Habits of Visionary Companies
(p 122)
- Fervently held ideology...
- Indoctrination
- Tightness of fit [for employees]
- Elitism
Interestingly, agile methods do tend to require "buy-in". In order to fully feel comfortable in an agile environment, people need to understand and fully accept a small number of very important beliefs:
(These are the generic, non-software version of the Agile Software Manifesto.)
See also: Optimizing a Team Room
Posted by Mishkin Berteig at 11:26 AM | |