« February 2006 | Main | April 2006 »
March 31, 2006
How the Process Facilitator can Help the Team Handle Out-of-Scope Work Requests
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.
The mechanism is actually very simple: track the work in the team space using cards and a variation on the burndown chart.
The Cards:
During the team's status meeting, or any other time that a team member mentions doing some of this outside work, immediately request that that person write it down on a task card. The task card should be visibly distinct from normal task cards: either a different color or a different size or in a substantially different location. The task should also get an estimate in the same units you are using for the other tasks.
For each task identified, contact the person who requested the extra work. If the person who is doing the work has made a committment to the requestor then let the requestor know that the team has accepted the work but that there is a consequence: the team may not get all its other work done on time. As well, the requester should be informed that in the future, all extra work for individuals on the team must be prioritized by the team's product owner.
Encourage the team to reveal this work by mentioning it at the start of the status meeting, in any iteration planning or retrospective meetings, or in any one-on-one meetings you have with team members.
The Burndown Chart:
Now that all the extra work is reflected in cards with estimates, the burndown chart can track this work too. The key difference is that it is tracked as a separate part of the work. If there are 80 units of normal work remaining, and 20 units of this extra work remaining, then the burndown chart will have a mark at 20 and a mark at 100. The mark at 20 should be made in a different color (I recommend red) so that it is highly visible. One ends up with a burndown chart that looks something like this:
The Product Owner:
It doesn't take much more than a single iteration for the Product Owner to get the message loud and clear: this extra work is eating up the team's capacity! The Product Owner now sees the consequences of not being the go-to person for all work items.
Deb's experience with this was that by the next iteration there were no further requests of the team for unofficial work, and the team's capacity to do work for the Product Owner took a nice leap upwards.
Posted by Mishkin Berteig at 11:26 AM | |
March 30, 2006
Bombs and Agile
The coach's gathering last weekend also got me thinking about the ethics of Agile Work and coaching. Is it okay to use agile methods for destructive purposes?
Let's first look at the Agile Software Manifesto for guidance. We see four statements of values and a number of principles. None of them provide an ethical framework that helps us determine where to use agile methods. In fact, there are many types of work that we could ask an equivalent set of questions about:
Is it okay to use agile methods to assist research in bio-weapons?
Is it okay to use agile methods to build software systems for nuclear missiles?
Is it okay to use agile methods to run a hate campaign?
Is it okay to use agile methods to ... ?
The agile community lacks a statement of ethics equivalent to the Hippocratic Oath. Do we even need one? As coaches, should our Middle Way to Excellence be grounded in a strong moral sense or is the middle way adrift?
I feel like we need a moral grounding. I think that the basis of it should be the recognition of the Unity of Humanity. I believe that both justice and mercy are important. Trust and Truthfulness are part of the foundation as well.
Is there any way to state a professional creed for Agile coaches that we can all agree upon? Has anyone tried?
For what it's worth, the ICF has a code of ethics that might be a starting point.
Posted by Mishkin Berteig at 01:04 PM | |
March 28, 2006
FBI's Virtual Case File Failure
Great, looooong article about a massive software project failure. Over $100 million down the tubes. Could Agile have saved it?
Posted by Mishkin Berteig at 12:43 PM | |
March 27, 2006
Dehumanizing Documents
This past weekend, I was honored to host a small gathering of Agile coaches at my home. Our conversation varied over many topics and I'll be covering some of them in the upcoming days. The first I would like to cover came from a comment that Christian Gruber made. In the Agile Software Manifesto there is the statement that we value "working software over comprehensive documentation" and in the Agile Axioms we say "we are creators". These two statements are closely related.
The comment Christian made was roughly as follows (and I've inserted a bunch of words to make the context clear):
When we communicate through documents in large organizations, there is often no specific person that is receiving the document. Rather, the document is being written by a role for a role both of which are part of some corporate process.Since both the writing and receiving are being done in relation to abstract roles, the document itself becomes very abstract. The writer of the document must forget his or her humanity and write as a machine: precise, complete, making assumptions explicit, and carefully structured. In other words, write in a way which is very unnatural compared to normal human communication.
How do you feel when you read such a document? Bored? Insulted? Frustrated? Turned Off? Resentful?
No wonder! It wasn't written for you. It was written for the least common denominator of you, namely, the role you play in an organization. This is dehumanizing. It is an attempt to make the people in an organization predictable and robotic in their communication.
So, in order to change this, Agile methods encourage that we write the least possible amount of documentation (not none). I would add, that when we must write documentation, we write it to a specific person. We find out who will be reading our document, get to know them at least a little bit. Then, write it with their name in it. Write it as an extended conversation. Make assumptions about what that person knows. Put your own personality into it. And of course, put in the crucial information. After all, you are writing for a reason :-)
Posted by Mishkin Berteig at 07:28 AM | |
March 23, 2006
Paper on Agile and Metrics
Deborah Hartmann and Robin Dymond have written an excellent paper "Appropriate Agile Measurement: Using Metrics and Diagnostics to Deliver Business Value" [pdf]. I strongly recommend this as critical reading for any organization adopting Agile Work methods. The paper provides a basic framework for the safe use of appropriate metrics: metrics that will help the health of the organization, not hinder it.
Posted by Mishkin Berteig at 11:33 AM | |
March 22, 2006
Facilitating Groups to Self-Organize
Yesterday I co-facilitated a meeting with another Agile coach. Near the end of the meeting, one of the participants made a comment to the effect that I probably didn't imagine when I was growing up that I would be a meeting facilitator. Strangely enough, in a way I did!
I also had a phone conversation this morning with an individual who is interested in reviewing one of the courses that I facilitate. Part of our discussion reminded me of the story of how I got interested in this sort of stuff.
When I was a boy, I was very interested in science and technology. I read lots of books about biology, electricity, robots. I also had the pleasure of playing with discarded video equipment that my dad would bring home from work. By "playing" really I mean "breaking". I also disassembled adding machines, reel-to-reel tape players, stereos, etc. Aside from Lego though, I wasn't very good at re-assembling. Eventually I really got interested in math as well and then computers. The story of how I got interested in math is also the story of how I got interested in education.
One weekend, when I was in Grade 2, probably seven years old, I went on a trip with my dad to visit my grandpar
Posted by Mishkin Berteig at 12:18 PM | |
March 20, 2006
Organizational Development Coach
A good friend of mine and a fellow coach, Michael Hamman, has a very nice website with an interesting, challenging and engaging manifesto. Please visit his site: http://www.ecosystemae.com/. Michael focuses on organizational development and how people work in organizations. As a person he is both sensitive and intelligent and can see deeply into both what is good and what ails an organization or a team or simply, a fellow human being.
Posted by Mishkin Berteig at 10:31 PM | |
Methods of Prioritization
In Jean Tabaka's new book, "Collaboration Explained : Facilitation Skills for Software Project Leaders
1) Round the Group prioritization:
group size 3-8
item list size < 15
Items are written on cards and placed in random order linearly either vertically or horizontally.
The members of the group each take turns placing the items in the order they think is the proper priority order. While doing so, each person moving the cards is welcome to explain their reasoning. However, the other group members refrain from commenting on the new prioritization.
This continues around the group as many times as it takes to find a stable order.
2) Ping Pong Balls:
group size 1-12
item list size > 15
(Thanks to Ken Schwaber for this method)
A fixed number of ping pong ball units are given to the group. The ping pong balls represent units of one dimension for prioritization such as value, risk or cost.
The group discusses how to allocate ping pong balls to each item in a dynamic fashion until everyone agrees that the allocation makes sense.
For very large lists, this is easiest to do in a spreadsheet with fewer people involved.
3) Variation: 2-stage multi-voting with voter freedom
group size 5-20
item list size < 50
This is identical to the public multi-voting system Jean describes with the following changes:
First, there is no restriction on how votes are allocated to items. A person can put multiple votes on a single item and can withhold some or all of her votes.
Second, after everyone has "finished" voting, the facilitator calls for everyone to step back and think about the results. Some discussion is allowed about the consequences of the results. Finally, everyone is given an opportunity to move their votes.
For large groups with large lists this can be somewhat awkward as people might forget where they voted. In this case, and if anonymity is not required, each person can use small post-it tabs with an identifying mark on them so that they can easily be moved around in the second stage.
Posted by Mishkin Berteig at 01:25 PM | |
March 16, 2006
Carnival of the Agilists
Another great selection of blog articles related to agile at the Carnival of the Agilists.
Posted by Mishkin Berteig at 05:57 PM | |
Unused Features
Software projects have a really bad record. Here's a part of that bad record: on average, 45% of features delivered are never used! This is yet another reason that Agile methods shine: do the highest value work first and stop when you've got enough. Can't do that with waterfall projects!
Posted by Mishkin Berteig at 02:28 PM | |
March 14, 2006
Updated: Agile Advice Recommended Materials
Over the course of the past month or so, I have added many new references to the Agile Advice Recommended Materials page. Thanks to people who have suggested links and books! If you want to suggest additional resources that you think are excellent, please let me know in the comments. I'm going to start tracking who suggested what so that I can give due credit!
Posted by Mishkin Berteig at 12:17 PM | |
Agile or Not Agile?
Every once in a while the del.icio.us tag for Agile turns up something really interesting. This evening, I found this article about the ongoing use of the term "Agile". The article is brief and a little weak, but it brings up a concern that is always niggling in the back of my mind. Interestingly enough, a good friend of mine, Christian Gruber, emailed me another web page of similar import...
In this registration page for Rules of Enterprise Agility, we read about something that really has nothing to do with the Agile Manifesto, nor the Agile Axioms.
Both of these examples are signs of two things:
1. The growing popularity of the term "Agile".
2. The growing dilution of the meaning of the term.
How can we fight this? Should we fight this?
I think it is very important to constantly call attention to the fact that Agile is about the minimum process and tools that can possibly work, and only in the context of valuing individuals, interactions and teams more than those tools and processes.
Trust is the Foundation of Agile Work
Technology, tools, process, even good ideas and good organizations do not create trust. People create trust by being trustworthy: honoring their commitments, striving for excellence, truthfulness, courage. One of the fundamental problems afflicting organizations is the lack of trust: between management and employees, between business and IT, between experts of various sorts, between coworkers.
This lack of trust is institutionalized in many ways including bureaucracy and legal frameworks.
The only way to change this state of affairs is to build trust. And the only way to build trust is to embody trustworthiness in yourself so that by example and by your words you can help others to become more trustworthy.
Agile methods put in place mechanisms that assist in building trust. But those mechanisms are merely a means to an end. Let us never forget that.
Posted by Mishkin Berteig at 12:27 AM | |
March 13, 2006
ScrumMaster Certification Course for Agile Software Project Management in Toronto, Mar. 23+24, 2006
This is an interesting and excellent course that goes into much of the material here on Agile Advice in a software-specific context. Register here, or view the course description.
Posted by Mishkin Berteig at 02:12 PM | |
March 12, 2006
Work Item Backlogs as Queues - Agile vs. Lean
A recent discussion on the Scrum Development list (Start of Discussion) provides a good follow up to my parting words in The Art of Obstacle Removal about agile practices themselves becoming obstacles. I have excerpted a small amount of the discussion and added my own comments here.
In the agile community, most of us have bought into and adopted the Agile mental model. But that mental model has assumptions embedded into that may not be correct under all circumstances. Part of that mental model includes the efficacy of the work item backlog as a tool for tracking, prioritizing and communicating work to be done in the future.
I will be the first to say that Agile is far better than waterfall in almost every situation (the exception being the mythical project with stable requirements, business environment, technology and team).
That said, let's look at backlogs from another perspective: if a backlog was the only thing you delivered to the customer, would they pay for it? If you spent even just a few hours coaching a business representative to build a backlog, but there was no team to implment it, would that person really find value in the backlog itself? Would they be able to deliver ROI just from a backlog? I think the answer is a clear "no".
That set of questions may seem silly, but from a lean perspective, they are among the most important questions. Is an artifact/process value-added or non-value-added?
Since the backlog is clearly not a value added artifact/process (pause for effect)... it is waste!
When one is doing agile effectively, the backlog may in fact be one of the larger sources of waste! If the team has a stable velocity, there will come a point when the backlog becomes the constraint on the overall cycle time going from idea to ROI. If the backlog is large/long, and as Mary Poppendieck said if there is more than ...maybe two or three
sprints of work.... in there, then it may be time to find ways of constraining the size of the backlog. I have two suggestions:
Capacity of Team(s):
Find a way to increase the capacity of the team so that the backlog size reduces and then goes into a steady state. This may mean augmenting the staff.
Gate Backlog Items by ROI
(This is just theory to me at this point.) Make it a condition that all backlog items must have a positive ROI. In other words, the cost of building the backlog item needs to be less than the value delivered, taking into account time value of money. Don't let items onto the backlog unless this positive ROI can be demonstrated.
I believe the lack of this second discipline (assigning ROI to work items) is one of the main reasons that most agile methods such as Scrum allow an unlimited backlog size: there is no realistic way to gate the work that gets onto the backlog!
Until teams get to Agile nirvana (stable velocity, continuous delivery of business value, high-performance cohesive teams), having an unlimited backlog seems like a very reasonable thing: it's not the constraint or the primary source of waste. However, eventually the backlog will become a primary source of waste and it needs to be treated in a disciplined manner.
With a stable and well-functioning team, what other ways might there be to reduce the size of the backlog so that cycle time is substantially reduced?
Posted by Mishkin Berteig at 03:31 PM | |
March 10, 2006
The Art of Obstacle Removal
One of the best ways to go faster is to remove the things that slow you down. This "obstacle removal" is an integral part of many agile methods including Scrum and Lean. Sometimes it is obvious where an obstacle is. There are a few small things that can be done easily to go faster. But to get going really fast, we need to have a deeper understanding of obstacles... and the Art of Obstacle Removal.
What are Obstacles?
An obstacle is any behavior, physical arrangement, procedure or checkpoint that makes getting work done slower without adding any actual contribution to the work. Activities that do add value to our work may be slowed down by obstacles, but are not obstacles in and of themselves.
Obstacles and Waste
Obstacles are the causes of waste in a process. There are many types of waste, and for every type of waste there are many possible sources (obstacles).
Types of Obstacles
Personal
Personal obstacles are related to us as individuals. There are several levels at which these obstacles can show up.
Outside factors in our lives such as illness or family obligations can become obstacles to our work at hand. These obstacles are hard to remove or avoid. Even if we would want to avoid an obstacle such as illness, it is hard to do anything about it in an immediate sense. However, as part of our committment to the group we are working with, we should consider doing things to generally improve our health. Good sleep, healthy and moderate eating, exercise and avoidance of illness-causing things and circumstances are all possible commitments we can make to the group. Likewise, we can make sure our personal affairs are in order so that unexpected events have the least impact possible. This topic is vast and there are many good sources of information.
Physical Environment
Obstacles in the physical environment can consist of barriers to movement or communication, or a lack of adequate physical resources. Sometimes these obstacles are easy to see because their effects are immediate. For example, if a team room lacks a whiteboard for diagrams, keeping notes, etc., then the team may not be able to communicate as effectively.
Other physical obstacles are not so obvious. The effects of physical environment can be subtle and not well-understood. Poor ergonomics take weeks, months or years for their effects to be felt... but it is inevitable. A too-small team room can lead to a feeling of being cooped up and desperation to get out... and eventually to resentment. Again this can take weeks or months.
Here are some guidelines on a good team room.
Knowledge
A lack of knowledge or the inability to access information are obstacles. A team composed of junior people who don't have diverse experience and who don't have a good knowledge of the work they are doing will have trouble working effectively. There may be barriers preventing the team from learning. Common barriers include over-work leading to a lack of time or mental energy for learning. With junior people in particular, there is a lot of pressure to be productive and that can often be at the expense of a solid foundation of learning.
Other times, knowledge-related barriers can be more immediate. If a critical piece of information is delayed or lost this can have a large impact on an Agile team that is working in short cycles. The team may be temporarily halted while they wait for information. Building effective information flow is critical to a team's performance.
Organizational
One of the best sources of information about this is the two books by Jim Collins: "Good to Great" (Review) and "Built to Last" (Review).
Cultural
In organizational culture, one thing I constantly see is a public espoused value of teamwork, but a conflicting behavior of individual performance reviews and ranking. This is cultural. It is also a barrier to the effective functioning of an Agile team. For corporate environments I highly recommend the Corporate Culture Survival Guide by Edgar Schein.
Dis-Unity
Dis-unity is one of the most subtle and common forms of obstacle. Competition, legal and cultural assumption of the goodness of "opposition" and habits of interaction including gossip and backbiting all combine to make united action and thought very difficult.
This is an extremely deep topic. There are many tools and techniques available to assist with team building. If you are interested in this topic, I highly recommend reading "The Prosperity of Humankind".
Removing Obstacles
The ability to identify obstacles and understand why they are causing problems is only the first step in removing obstacles. In Agile Work, the person primarily responsible for identifying and removing obstacles is the Process Facilitator. The Process Facilitator has several approaches available for the removal of obstacles. A process facilitator has similar responsibilities to a change agent.
Direct
Deal with the obstacle directly without involving other people. This can be as simple as getting up and moving an obstacle impairing vision, or as nuanced as running interviews and workshops throughout an organization to gradually change a cultural obstacle.
Command and Control
Identify the obstacle and give precise instructions for its removal to a person who will directly perform the removal. This can sometimes work if removing an obstacle takes a great deal of time, effort or specialized skills that you yourself do not posess. However, the overall approach of "command and control" is not recommended for Agile environments since it is disempowering.
Influence
Identify the obstacle and suggest means to deal with it to a person who has the authority or influence to get others to deal with it. This indirect method of obstacle removal can be slow and frustrating. However it usually has better long-term effects than command and control.
Support
Offer to assist and encourage the removal of obstacles that have been identified by other people. In many respects this is a very effective method. It can assist with team-building and learning by example. People are usually grateful for assistance.
Coaching
Train others on the art of obstacle removal including obstacle identification, types of obstacles and strategies for dealing with obstacles. Observe people's attempts to remove obstacles and give them feedback on their actions.
Creating a Culture of Obstacle Removal
Encourage and measure obstacle removal at all organizational levels until it becomes habitual. In many ways this is the essense of the lean organization.
Strategies for Dealing with Obstacles
Diagrams are a great way of communicating the essense of a concept. Feel free to share the following diagrams with anyone (but of course keep the copyright notice on them).
Remove
Remove the obstacle altogether. This method of dealing with an obstacle is usually the most immediately effective, but is also one of the most difficult methods.
The best way to actually remove an obstacle is to get at the root cause of the obstacle and change that. This type of change results in the longest-lasting and most stable elimination of an obstacle.
Move Aside
Take the obstacle and put it in a place or situation where it is no longer in the path of the team.
In a team's physical environment, this may be as simple as changing the tools that the team is using. For example, if the team is all in a room together, move computer monitors that are blocking team member's views of each other. If there is a useless checkpoint that work results have to go through, get management to eliminate it.
Shield
Build a shield or barrier to hide the obstacle so that it's effects no longer touch your team.
If a team is distracted by noisy neighbors, put up a sound barrier. If a team is unable to see their computers due to late afternoon sunlight, put up window shades. If a manager is bothering the team with meetings or tasks unrelated to the work of the team, then put yourself between the team and the manager (or get someone in upper management to do that).
Shielding is excellent for immediate relief, but remember that the obstacle is still there and may become a problem again if the shield cannot be maintained.
Transform
Change the structure or form of the obstacle so that it no longer affects effectiveness.
In general, this method requires a great deal of creativity and open-mindedness. This is one that works particularly well on people who are obstacles: convert them into friends of the team!
For example if the team needs approval of an expert who is not part of the team, this can cause extra work preparing documentation for this person and long delays while the expert revies the documents. If the expert becomes part of the team, then they are well-informed of the work being done and can give approval with very little overhead.
If done well, this can be a very long-lasting method of dealing with an obstacle. Make sure that the transformation is true and that it takes hold... and beware that the obstacle doesn't revert back to its old nature.
Counteract
Find an activity that negates the effects of the obstacle by boosting effectiveness in another area.
As a coach or Process Facilitator, this is what we spend our time in early in a team's adoption of Agile Work: we get them to work in the same room, use iterations and adaptive planning, we focus them on delivering work valued by the stakeholders as defined by the Product Owner. All these things are enhancing the team's ability to get work done without actually directly dealing with any obstacles.
Watch out for barriers avoided this way to come back and bite you later on.
Removing Obstacles and Learning
Organizational learning, as well as adult learning have a strong relationship to obstacle removal. Organizational learning can be either single-loop or double-loop learning. Adult learning can be either normal or transformative. We can approach obstacle removal from a surface level where we only deal with the immediate symptom, or we can work at a deeper level where we deal with the symptom and its chain of preceding causes. One effective method for examining the deeper causes is the 5-why's exercise.
Obstacles Inherent in Agile
Agile methods do not perfectly eliminate all obstacles. Some obstacles that are inherent in agile methods include overhead due to planning meetings at the start of iterations, the use of a dedicated process facilitator. As well, the use of iterations can become a barrier to certain types of work items: repeating items, investment in infrastructure, one-off tasks that are not directly related to the work at hand.
At some point, our teams will have matured to the point where agile methods are no longer necessary and we can pick and choose what parts of agile we use.
Go Forth and Demolish Obstacles!
As a Process Facilitator, coach, ScrumMaster, manager, change agent or stealth agile advocate, you have the ability and the knowledge to make a big difference in people's lives and in the success of the organizations they work within. Removing obstacles is one of the most important duties you have.
Do you have stories about obstacles you have removed or seen removed that have made a big difference? We would love the hear the anecdotal side of this as well!
Posted by Mishkin Berteig at 01:10 PM | |
March 09, 2006
Facilitation Primer
Another good reference and learning tool: a basic primer on meeting facilitation. It's a PDF linked off the page (I didn't link directly to the PDF). I've read through this and I strongly recommend it if you haven't already seen it! If you are working in Agile methods, this is essential basic material.
Posted by Mishkin Berteig at 03:49 PM | |
Good Blurb on Command and Control
My friend and co-worker Deborah Hartmann has a blog entry that I think is very insightful. The article is called: Hardwired for Command and Control? To me, the most important part of her article is this one sentance:
The shift to Agile values and practices is difficult - for many, it's a significant culture change. And with change comes stress, and with stress... fear and the urge to control.
Posted by Mishkin Berteig at 03:27 PM | |
March 08, 2006
How to Deal with Repeating Tasks? A Question for the Audience
Most agile projects that I have worked on have had very little repetition in them. Each day brings new work, new problems. Each iteration is working on something different. So what happens if there are tasks that repeat? What if you have to do the same thing every day or every week or every iteration? How does this fit in with agile work methods?
In some agile methods, there are certain things that are already repetitive such as the iteration planning meeting, the daily status meeting and the retrospective. These things are process overhead. As overhead goes, they're not too bad! Agile methods usually treat them as a special kind of work: they are not work that shows up in the work item backlog nor in the task backlog for an iteration.
In our lives we have to deal with many repetitive tasks: cleaning the fish tank, mowing the lawn, renewing our vehicles license plates, brushing our teeth. Many of these things are "just there": you know you have to do them, you do them and you don't bother tracking how much time they take, nor specifically scheduling them.
In Agile Work, with one of the disciplines being to "Eliminate Waste", there is some tension between our normal approach to repetitive tasks and the high-visibility approach of agile.
We could put all our repetitive tasks on the backlog. For example, if we have a weekly status meeting to report on progress to management, this could be put on the backlog. The problem is, that the meeting doesn't provide any value to the organization and the backlog is really meant for valuable items.
We could have a separate mechanism for tracking repetitive tasks. This might be a calendar, it might be a per-iteration checklist.
We could find ways to automate or eliminate the repetitive tasks. This works very well in an IT environment or in an environment where machines could do the work. But it can't work for repetitive communication tasks where the details are constantly changing.
We could leave them essentially invisible...
I'm curious though: have any of you been on projects where you have had to explicitly deal with this? What did you do? Did you distinguish between value-added and non-value-added repetitive tasks and if so, how?
Posted by Mishkin Berteig at 05:32 PM | |
March 07, 2006
Visualizing Agile Value
One of the most important benefits of Agile Work is the early and continuous delivery of value to stakeholders. When I am coaching or presenting on Agile Work, almost inevitably I draw a very simple diagram on a convenient whiteboard or flipchart that demonstrates this benefit and contrasts it to a big-bang, waterfall approach to work.
The horizontal axis is time and the vertical axis is dollars/euros/whatever. The blue line represents the value that the agile team is delivering to stakeholders at any moment in time. (To be precise, it is the instantaneous net-present-value delivered... and therefore the area under the curve represents the total value delivered.) The red line is a spike of value delivered at the end of a waterfall project. The grey horizontal line is the constant cost (opportunity cost should be factored in) of a cross-functional agile team.
We can see clearly that an Agile team delivers value continuously. However, the shape of the curve also indicates that most of the value is delivered early on. This is the result of having a backlog of work items that are prioritized primarily by value. The initial up-slope of the curve represents the agile team getting accustomed to the work (and each other) and speeding up as they do so.
The waterfall delivery of work has the big disadvantage that if for some reason the project doesn't get completed, you are left with nothing of value!
And here's another Bonus Quiz Question:
The point where the blue curve of value delivery crosses the grey line of the cost of the team is a very important point... what does it represent?
Posted by Mishkin Berteig at 01:41 PM | |
March 03, 2006
Choice Quotes from Systemantics - Funny, But Scary Too
Some Theory:
The Fundamental Theorem: NEW SYSTEMS MEAN NEW PROBLEMS p. 14
The Big-Bang Theorem of Systems Cosmology: SYSTEMS TEND TO EXPAND TO FILL THE KNOWN UNIVERSE p. 18
There is a world of difference, psychologically speaking, between the passive observation that Things Don't Work Out Very Well and the active, penetrating insight that COMPLEX SYSTEMS EXHIBIT UNEXPECTED BEHAVIOR p. 22
Hmm... that sounds like some organizations I've worked in.
SYSTEMS TEND TO MALFUNCTION CONSPICUOUSLY JUST AFTER THEIR GREATEST TRIUMPH p. 35
A TEMPORARY PATCH WILL VERY LIKELY BE PERMANENT p. 36
WHEN A FAIL-SAFE SYSTEM FAILS, IT FAILS BY FAILING TO FAIL SAFE. p. 80
An Example:
COLOSSAL ERRORS TEND TO ESCAPE NOTICE... Thus, the loss of 50,000 American lives per year in auto accidents is seen, not as a mortal flaw in our Transportation System, but merely as a fact of life.
p. 91
Related to Agile:
But how does it come about, step by step, that some complex Systems actually function? This question, to which we as students of General Systemantics attach the highest importance, has not yet yielded to intensive modern methods of investigation and analysis. As of this writing, only a limited and partial breakthrough can be reported, as follows: A COMPLEX SYSTEM THAT WORKS IS INVARIABLY FOUND TO HAVE EVOLVED FROM A SIMPLE SYSTEM THAT WORKEDThe parallel proposition also appears to be true:
A COMPLEX SYSTEM DESIGNED FROM SCRATCH NEVER WORKS AND CANNOT BE MADE TO WORK. YOU HAVE TO START OVER, BEGINNING WITH A WORKING SIMPLE SYSTEM.
p. 65
THE MESSAGE SENT IS NOT NECESSARILY THE MESSAGE RECEIVED p. 102
IF SOMETHING ISN'T WORKING, DON'T KEEP DOING IT. dO SOMETHING ELSE INSTEAD. p. 125
ESCALATING THE WRONG SOLUTION DOES NOT IMPROVE THE OUTCOME p. 169
Posted by Mishkin Berteig at 06:40 AM | |
March 02, 2006
Five Signs of Trouble in an Iteration
During the course of an iteration, an agile team is able to track it's own progress through the use of burndown charts. The team and the process facilitator can use the burndown chart to watch for signs of trouble. As a coach, I find the following five burndown shapes are common indicators of trouble.
But let's first show the idealized "normal" burndown. This burndown shape shows that the team is on-track to get to done exactly at the end of the iteration. The work remaining has had a constant slope down through the course of the iteration.
Now the warning signs:
1. Too Much Work
In this burndown, the team sees that it has likely selected too much work for the iteration. The process facilitator and the product owner need to work with the team to decide how to change the scope so that the team can get done. One might be tempted to add people to the team to get the work done faster, but this is rarely successful.
2. Not Getting Done
Frequently, when a team is just starting out with agile work, it commits to slightly too much work. It is hard to detect this at the beginning of an iteration. Instead, it is only near the end of the iteration that it becomes apparent that the team isn't quite going to make it to done. The process facilitator must work with the team to determine the root causes of this and change things so it doesn't happen again.
3. Early Learning
When a team is starting the iteration, it can discover new things about the work it has committed to accomplishing. This can include dependencies, new tasks, extra components that need to be built, etc. This discovery process is normal, but needs to be monitored closely. If the burndown doesn't start going down again after about 15% of the iteration is over, then there is likely trouble brewing.
4. Unresolved Obstacles
Sometimes the team will run into an obstacle that will completely stop their progress. Although the process facilitator is responsible for dealing with obstacles, it may be impossible for an obstacle to be fixed quickly. If the team finds that all the work it committed to for the iteration is dependent on someone who is sick or on vacation, that can lead to an unresolvable dead halt. This may be an opportunity to cancel the iteration.
One interesting example of this was observed by a coach I work with frequently, Deborah Hartmann. She was away from her team for a few days and when she came back, she observed this "flatline" burndown. After poking around a little bit to try and find the obstacle, someone finally described what had happened. At the time of the flatline, a Vice President in the organization had come into the team's area, looked around, and loudly declared something to the effect of, "I don't know why you guys are doing this project. It's totally worthless!" Suffice it to say that the team was seriously demoralized. It wasn't a technical obstacle, it wasn't a procedural or bureaucratic obstacle, it wasn't even a cultural obstacle. It was just a serious blow to morale. Of course, to fix this, the actual sponsor of the project had to be brought in to assure the team that it was actually an important project and that there were people in the organization who needed the work that the team was doing.
5. Scope Creep
This last case is rarer for an agile team if the team and the product owner have been educated well about the rules. Nevertheless, it can happen. The product owner, or some other stakeholder, pushes the team to add scope to the iteration. The process facilitator is normally responsible for preventing this from happening. If despite this it does happen, the burndown chart makes the consequences of this scope creep.
Special Quiz Section!!!
What are the possible explanations for the following burndown shape? I have heard/experienced at least six different possible reasons. Leave your answers in the comments.
Update: at Agile Chronicles, there is a short article about this topic which mentions one more burndown chart pattern that is a bad sign: the "Late-Breaking Decline".
Posted by Mishkin Berteig at 01:34 PM | |