November 09, 2007
Agile Contracts
One of the Certified Scrum Trainers, Chris Sterling from SolutionsIQ, recently posted a good set of links on Agile Contracts. Hopefully these links will help you understand how to "sell", set up and execute on agile contracts. Here are the links:
Chris wrote:
Mary and Tom Poppendieck have great presentations and a workshop on this topic. Here is a URL to a Powerpoint presentation from them:http://www.poppendieck.com/pdfs/AgileContracts.pdf
Also, here is some data from a workshop:
http://www.poppendieck.com/agilecontracts.htm
And Alistair Cockburn has a great page on Agile Contracts here:
http://alistair.cockburn.us/index.php/Agile_contracts
Martin Fowler has a page on “Scope Limbering” here:
http://martinfowler.com/bliki/ScopeLimbering.html
Hope these help.
Thanks Chris! Here are a couple more links:
Leading Answers - Agile Contracts - blog entry with some good references.
Contracting Agile Projects - by the Cutter Consortium
I'm not an expert on agile contracts myself. I would be interested in hearing from people if they have any stories about actually using (or failing to use) contracts in an agile environment.
Posted by Mishkin Berteig at 07:17 AM | |
November 01, 2007
Learning Collaboration
How do we teach people to work in a collaborative manner? How do we help individuals, in our incredibly individualist and competitive society, to learn the skills needed for agile teamwork?
Start with the Kids
Our school system, here in the West, is strongly oriented to individual grading, work, and even competition. We throw our kids into age-limited classrooms where they are inevitably compared to one another and learn to make the comparisons themselves. There are private schools which don't do this: no grading, mixed-age classrooms, but they are the exception by far.
It seems reasonable to me that if we could help our kids learn collaborative skills, they would at least have a foundation to build upon and minds that were more open to the possibilities.
In my mind, the best way to do this consists of two aspects: collective efforts and human capacity development.
Collective Efforts
Kids are amazing at learning. If they have experiences, they naturally learn to cope with those experiences. It follows then, that even if children start out with little or no skill in collective, collaborative work, then simply by putting them into situations where that type of work is required, they will learn at least some of the necessary skills.
I had two experiences in my childhood that helped me learn those skills. In my faith community, as a Baha'i, we had children's classes (kinda like Sunday school) where we played many collaborative games and learned about the Baha'i concept of consultation. I didn't particularly like the games, but nevertheless, they made an impression on my young mind. I even remember at one point when I was a little older learning to help out with these games. The things I learned about group decision making through consultation made a big impact on me and have become more and more important as I progressed through school and professional life.
The second experience was in my public school where I was streamed into a program for academically talented children. I think the idea was that if you had an IQ of 120 or over you were eligible for the program. I remember doing an IQ test in grade four. Anyway, the program was excellent in many ways. In grades seven and eight we started to learn Edward deBono's CoRT thinking skills program. I'm not sure if it was intentional or not, but many of the exercises were small group exercises where two or three or four of us had to work together. Again, I learned a great deal about the value of working with people with different skills and ideas, and how to do this in a systematic way. Many of the exercises and techniques that I use as a coach and trainer are based on or inspired by these exercises I did as a child.
Human Capacity Development
I recently wrote here about truthfulness. Aside from the obvious implications for agile methods that I have written about, there is another level to this concept.
Truthfulness is the foundation of all human virtues - Baha'u'llah.
There is no doubt in my mind that some of the basic virtues or moral ideas that we are supposed to learn in childhood are critical to effective collaboration. For example, the "Golden Rule": "And if thine eyes be turned towards justice, choose thou for thy neighbour that which thou choosest for thyself." Epistle to the Son of the Wolf, p30.
The trouble is, you can't do the Golden Rule effectively without being truthful. How so? Well, if you can't be truthful about what you really want for yourself, deep, deep down, then chances are you aren't going to do to others what they truly want. Knowing your own self at the deepest level is a pre-condition to following the Golden Rule effectively. And knowing your own self deeply requires a level of truthfulness that most of us are not accustomed to.
The same could be said about almost any other virtue or capacity required for collaboration: courage, humility, assertiveness, compassion, etc.
Of course, developing these capacities is something that doesn't happen overnight. The starting point is to look at what we can be truthful about, and building on that. As we practice these capacities in our relationships with other people, they will strengthen and we will set out on a path of improvement. It is helpful to have other people working with us; to support us, encourage us, and to help us honestly face up to our failures and learn from them. It also helps to have guidance that can be trusted. Searching for these sources of guidance is an important part of developing professionally as well as personally, whether it is a mentor, an author or some other figure.
These capacities are essential to our ability to work well together. The root cause of most of our failures to work together can be traced back to a lack of or failure to exercise these human capacities. For example, a lack of courage can lead to a failure to experiment. A lack of humility can lead to a failure to ask for help.
Posted by Mishkin Berteig at 07:26 AM | |
January 23, 2007
The Agile Zealot's Handbook
This is great! I often call myself an Agile Zealot to my clients. (Usually, they smile... and if they don't I tend to have a short relationship with them!) So here it is, the Agile Zealot's Handbook.
And, since I've got a dead horse lying around waiting to be beaten up some more, I've re-written it (the Agile Zealot's Handbook, not the dead horse) to be non-software oriented. Presenting... the new and improved... non-software oriented... readable by anyone... Agile Zealot's Creed:
VALUE
IF you don't repeatedly deliver results
that produce actual value
for a real customer
into your real world environment
frequently enough to respond to change...
TECHNIQUE
IF you're not paying constant attention to technical excellence
with simple, effective tools, processes and reuse
driven by uncompromising dedication to quality
and the discipline to test everything...
LEARN
IF you're not deliberately going
through stages of planning, acting
reflecting and learning
as frequently as you are delivering results
over and over and over...
TEAM
IF your team is not empowered to self-organise,
does not sit together and engage in face-to-face communication,
does not include your customer
and all the necessary skills to make its own decisions and take immediate action...
THEN YOU HAVE COMPROMISED YOUR AGILITY
(and good luck to you... you'll need it!)
Posted by Mishkin Berteig at 08:41 PM | |
January 16, 2007
The Wisdom of Teams - Generalizing Specialists
I've almost finished reading The Wisdom of Teams: Creating the High-Performance Organization
The [Connectors Team] made several decisions that solidified its common team approach and sense of mutual accountability. First, it set some rules. Everyone on the team had to identify two others who could serve as backups during vacation and sick days. To eradicate the attitude of "it's not my job" from the team, it was agreed that whenever anyone needed help, the person asked had to respond even if the activity was not in his or her area of expertise. And the team also agreed on a peer appraisal system that gave everyone the opportunity to evaluate everyone else and, through [their team leader], feed it back to the person being evaluated. Clear-cut rules of behavior like these are an important element of all successful teams.
Second, the team eliminated the two managerial positions that had retarded empowerment. This effectively modified the membership of the team because only one of the two managers whose jobs were eliminated chose to stay. The other believed he could not take a perceived demotion and left. By January 1991, however, the Connectors Team was a dramatically more effective group of people than it had been at its formation a year earlier.
Energy and enthusiasm reached higher levels as the team started pushing itself harder and in more innovative ways. One of the engineers, for example, decided to become completely qualified as a purchaser as well. Instead of being threatened, the purchasers on the team worked hard to teach her the basics of the job. The peer review approach worked so well that the team agreed on the additional - and, for many teams, difficult - step of directly providing each other feedback instead of relyinng on the team leader for this task.
There are several great points in the above story:
Backups: many agile methods do not explicity talk about this, but there is a need to make sure that the Truck Factor increases. A low truck factor can be a real problem and I strongly recommend that the Queue Master (Product Owner, Customer) in particular needs to have backup. As well, this hints at the idea that eventually the roles of Process Facilitator and Queue Master should eventually go away to be taken on by the team as a whole.
Skills: the example of the engineer learning to be a purchaser is a great example of a brave soul really taking to heart the idea of working for the good of the team by becoming a generalizing specialist. In my own coaching work, I have seen purely business-oriented Queue Masters become technical contributors to the team through a process of both deliberate and "accidental" learning. Every human being has an incredible capacity for learning. In a high-performance team, everyone takes that ability very seriously - to the point of it becoming a responsibility.
Rules: one of the simplest, yet most profound, ways that a group of people can start on the process to becoming a high-performance team is by working together to agree on some ground rules about team behavior. One team I worked with, among other rules, decided that no "stinky food" was allowed in the team room. The passage above notes the non-trivial rules. Both "trivial" and non-trivial rules are important to the team for two reasons:
1. Develop a set of expectations that individuals can hold each other to in order to avoid or deal with conflict.
2. Become aware of the team's power to set their own working conditions, independently of management or other "leadership".
Management: regrettably for most managers, in a high-performance team the value of formal, traditional management is much reduced. However, there is now an opportunity for two different types of work: the generalizing specialist work on the team, and the servant leader work of supporting the team. The servant leader is someone who is exceptionally good at problem solving, organizational change, and working through influence rather than authority.
This book is incredible. Every time I read a few pages I think "Oh! I've got to write about that on Agile Advice!" Unfortunately if I did that, I'd be in serious copyright violation. So all I can do is encourage you to read the book.
If you have already read the book, I would love to hear your impressions, particularly if there were things about it that you really didn't like. What didn't you like and why? What are the holes in it's argument?
Posted by Mishkin Berteig at 04:05 PM | |
January 02, 2007
Top Ten Most Popular Entries from 2006
If you are new to Agile Advice, these are not just some of the most popular articles, they are also some of the best! Take a look around; you will find ideas to inspire you, challenge your thinking and maybe that one little thing that will make the difference in applying agile methods in your situation.
1. How Two Hours Can Waste Two Weeks - 25,617 unique views
This little hypothetical story by Dmitri Zimine was very popular on Reddit, and Joel on Software ranted a bit about it.
2. The Case for Context Switching - 2,936 unique views
My rebuttal to Joel's rant. Goes well with Dmitri's article. Emphasizes the idea of building trust in an organization.
3. The Qualities of an Ideal Test - 1,579 unique views
Six qualities that will help make your tests as valuable as can be. Similar to the ACID properties of databases or the INVEST properties of user stories.
4. The Pros and Cons of Short Iterations - 1,555 unique views
A few words that will help you decide how long to make your iteration length. This is an important decision, and most teams and organizations don't know the factors involved.
5. Five Signs of Trouble in an Iteration - 1,489 unique views
A good howto on using burndown charts to discover problems in an iteration.
6. Seventeen Tips for Iteration Planning - 1,427 unique views
A good list of hints and tips that can make the difference between struggling with iteration planning and having it go smoothly and effectively. This is a key part of the Agile Work process, so getting good at it is a high priority for any team new to Agile Work.
7. Change is Natural - "Embrace Change" - 1,397 unique views
A short riff on the universality of change. Also introduces the idea of the "horizon of predictability".
8. The Art of Obstacle Removal - 1,287 unique views
This is a good reference article on types of obstacles and methods for removing them... a critical practice for Process Facilitators.
9. The Seven Core Practices of Agile Work - 1,285 unique views
Agile Work is really quite simple. This is a concise list of the practices that make up this effective methodology.
10. Interview with Alistair Cockburn - Agile and House Renovations - 902 unique views
Applying agile methods to home and garden renovations! Learn a bit about how this luminary of the agile world has taken agile practices out of the software world and into the hardware world.
Posted by Mishkin Berteig at 06:32 PM | |
August 29, 2006
Seventeen Tips for Iteration Planning
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.
1. Work items are, among their other qualities, valuable to the customer or stakeholders. Think of these work items as being built out of many smaller pieces. You can imagine a toy model made out of Lego bricks. Each brick, by itself, is of no value. It is only when they are put together that they become useful. The tasks you create for each work item are often small enough that they do not have any value on their own.
2. The word "task" implies activity... but the tasks you create for your work items do not need to be activity based. Tasks can be effective if they are written as components or pieces of the work item you are building. Here is an article about creating good tasks.
3. Sometimes if the work item is not well understood, you might find that a "research" or "experiment" task is a good starting place. Try to be as specific as possible. When writing the task description, spell out what exactly is the goal of your research, and possibly list what options you are going to research.
4. When first starting out with Agile Work, many teams find it difficult to do a good job of iteration planning in the fixed amount of time allocated to it. Consider shortening your iteration length so you can practice this skill more frequently. (Remember to make the planning meeting shorter too!)
5. Make sure that everyone has index cards and a pen to write with! Team members shouldn't have to wait for a "scribe" to write down a task. In many ways this is a brainstorming session. The Process Facilitator can collect all the cards after the meeting is finished if they need to be recorded more formally.
6. Do a first pass by creating "big" tasks... then break them up into smaller tasks if you have time. Since this meeting is timeboxed, it is better to get all the work broken down into big chunks than to break down only a small part of the work into very fine chunks.
7. If the same task keeps showing up for all your work items, it probably shouldn't be a task... instead it should probably be a process step or constraint or condition of satisfaction for the work you are doing. For example, if you always have to write a document that follows a template to record what you have done for each work item, then writing that document can be shown as part of your task board.
8. It's okay for tasks to be _very_ small.
9. Share your tasks! If you write a task down without telling the rest of your team, they can't use your idea to generate more tasks, nor can they improve on your idea.
10. Generating tasks in the iteration planning meeting is a problem solving and creative process. This is where you do a lot of your analysis and design work. This is where you struggle through options and choose _how_ to build/do your work.
11. Consider creativity technique such as light-weight brainstorming for generating lots of ideas quickly. Any technique you use should be streamlined for quick results.
12. Don't worry about administrative stuff while you are generating tasks. For example, if you normally put task cards up on a wall, wait until after the meeting is over to do this. Likewise, if you normally enter them into an electronic tools, wait until the meeting is over to do this.
13. Make sure you have scrap paper or a good whiteboard convenient for notes and drawings so that you can quickly model your solution for the work item. (Check out Agile Modelling for a discussion of this in the software realm.)
14. Remember that it's okay if you end the meeting with an imperfect list of tasks. You will make corrections throughout the iteration. It is more important to maintain the discipline of the timeboxed meeting length, than to get the tasks right up front.
15. The whole team must participate: everyone's experience, skill, expertise and insight are needed to do the best job of generating tasks. Just because it won't be a perfect list doesn't mean you can do a shoddy job of it!
16. You need quick access to information about the work items you are planning. You also need quick access to other relevent information. A computer with a web browser open to Google is a great tool to have at hand.
17. If you don't have anyone on your team who has lots of diverse experience and expertise, then consider inviting someone like this as a guest to help you out. It is much more difficult to do the necessary problem solving if you new to the medium in which you are doing the solving. Such a guest would need some time before the meeting to be prepared.
Posted by Mishkin Berteig at 10:44 PM | |
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 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 | |
May 31, 2006
The Human Touch
If you are given a problem to solve, how much does the presentation of that problem matter to your ability to solve it? Imagine that it's a simple problem... imagine that it is presented in two different ways, both of them simple. It turns out that presentation differences can still make a huge difference. In fact, there is a way to present problems that makes them substantially easiers to solve: make them people problems.
In The Tipping Point: How Little Things Can Make a Big Difference
Consider the following brain teaser. Suppose I give you four cards labeled with the letters A and D and the numberals 3 and 6. The rule of the game is that a card with a vowel on it always has an even number on the other side. Which of the cards would you have to turn over to prove this rule to be true?
Go ahead and take a few moments to figure that out before continuing on to the answer, and keep track of how long you work on it...
The answer is two: the A card and the three card. The overwhelming majority of people given this test, though, don't get it right. They tend to answer just the A card, or the A and the six. It's a hard question. But now let me pose another question. Suppose four people are drinking in a bar. One is drinking Coke. One is sixteen. One is drinking beer and one is twenty-five. Given the rule that no one under twenty -one is allowed to drink beer, which of those people's IDs do we have to check to make sure the law is being observed?
How long does it take you to figure that out?
Now the answer is easy. In fact, I'm sure that almost everyone will get it right: the beer drinker and the sixteen-year-old. But, as the psychologist Leda Cosmides (who dreamt up this example) points out, it is exactly the same puzzle as the A, D, 3, and 6 puzzle. The difference is that it is framed in a way that makes it about people, instead of about numbers, and as human beings we are a lot more sophisticated about each other than we are about the abstract world.
Now unless you had heard about this before, I suspect you were pretty suprised. I know I was! I always considered myself to be a very good abstract thinker/problem solver. In fact, I considered myself to be well above average in that regard for a number of reasons: I was always very good at math without every memorizing a single formula (I always made them up as I went along as long as I remembered the _idea_ of the formula), I was an excellent programmer in a number of different computer languages including assembler, Miranda, Java, Prolog, Pascal, and Objective-C, and finally, I'm always solving problems by moving the problem to a new level of abstraction - solving the meta-problem first.
So what does all this have to do with agile work methods? Quite a few things actually:
1. Obviously, if you can frame a problem as a people problem, it will be easier to solve... and most problems start out this way!
We tend to try to abstract problems, make them more generic or general purpose in the hopes that they can be communicated more precisely and can be solved in a way that will accomodate contingencies we haven't thought of yet. But all the effort we put into abstracting the statement of the problem ends up costing us doubly: in the initial abstraction and in the difficulty of solution that results. So if you have a team that is solving a people problem, make sure to keep it a people problem when you give it to the team!
2. If you have a problem that is given to you in an abstract form, try to convert it to a people problem before trying to solve it.
In all likelihood, the moment you do the conversion, you will quickly see the solution. It may even feel like the process of de-abstraction is a problem-solving process. You may have to make really odd connections to make the problem a people problem but it will likely be worthwhile.
3. Dealing with people rather than abstractions on a day-to-day basis will always result in a more effective interaction.
Sending printed documents, writing emails, manipulating symbols are all interesting ways to communicate, but fundamentally, you are communicating with other people. If you can make that communication as direct as possible - phone, video conference, in-person - then there will be far less effort involved in understanding the communication, and far more effort can be allocated to high-bandwidth communication. This obviously has special relevence for teams: get people in the same room as much of the time as possible.
In the software world, there is one technique that I give teams and that is the use of Personas to assist in solving a software problem. The place I first encountered Personas is in the excellent book The Inmates Are Running the Asylum
The bare essense of the Persona is to create a fictional person who represents a user or actor or stakeholder or customer of whatever it is you are building. This fictional person should have a name and all conversation about the thing being built should be couched in the personal language of these Persona's names. A Persona should also have a short history, a photo and some description of their needs, goals or desires. All of this helps to frame everything about a software project as a people problem... and thus makes it much easier to discuss and solve.
Posted by Mishkin Berteig at 11:12 PM | |
May 18, 2005
Making Friends Sure Beats Making Enemies
I heard a story about a situation where someone was refused career advancement because she had made an enemy a long time ago.
It made me think. Why do we make enemies? Is it because we don't really know how to make friends? In Agile Work, where communication, collaboration, teamwork and truthfulness are so important, making enemies is the worst thing a person can do. (It might not be such a big problem in mechanistic environments.)
The golden rule is a good starting place for learning how to make friends. Esther derby has a great course on teamwork that could help. An of course there's the old classic: How to Win Friends & Influence People which really is very good (if a little dated). If anyone knows some other good books or resources about learning to make friends, please reply in the comments!
Posted by Mishkin Berteig at 03:26 PM | |
May 15, 2005
Truck Factor
Truck Factor (definition): "The number of people on your team who have to be hit with a truck before the project is in serious trouble"
Clearly "hit by a truck" is an extreme thought however you could easily substitute "take vacation at the same time" to get the same idea. If any part of your project has a truck factor of one then you are in a particularly fragile situation. If that one person leaves or is unable to work on the project, you will suffer the consequences.
Over time, anyone can be replaced. Truck factor is an indication of how expensive it will be to replace specific people.
In an ideal situation, everyone on the team will know all parts of the system so that the loss of any one person would have minimal impact. In reality, many projects rely on one or more "heros" who are the only one who understand certain critical parts of the system. When these heros leave (and you should assume they will), you must be prepared to recover.
If you have a hero on your team, the best thing you can do is reassign that person to a different part of the system. This will allow the replacement to ramp up while the hero is still available for support. If you wait until the hero has left then the ramp-up will be significantly more expensive.
An added benefit to reassigning the hero is that this person will now have the opportunity to work on something different. Since the hero's tend to be the most technically competent members of the team, this will usually mean that the new area will improve once the hero has worked on it for a while.
Truck factor is a quick metric that will highlight potential problems in your project. Having hero's on your team can be very beneficial but only if you don't become dependant on them. Truck factor is one metric that will highlight your dependencies.
Cross posted from Mike Bowler's Weblog
Posted by Michael Bowler at 06:42 PM | |
May 10, 2005
Steps in Making a Decision
In her workshop "Advanced Scrum: Collaboration Skills for Scrum Teams", Esther Derby includes a brief discussion on the five parts of a decision.
1. Define the Problem
2. Establish Focus and Boundaries
3. Identify Options
4. Choose Among Options
5. Implement
At each step, it is instructive to examine who is "responsible" or involved. In an agile team where team empowerment and self-organization are considered critical success factors, the answer to "who?" fore each step should usually be "the team".
There are however, some situations where decisions are outside the realm of a team's empowerment. As well, some decisions are so trivial that it is wasteful to have the whole team involved. In these trivial decisions, usually another person can take responsibility for all the steps of a decision as a service to the team.
Over time, a team and the organization in which a team operates can evolve a set of standards that describe who acts in each step of a decision under what circumstances.
Many thinking tools described by Edward de Bono in his various books (such as Six Thinking Hats, Lateral Thinking : Creativity Step by Step (Perennial Library), Textbook of Wisdom etc.) can be used at various steps in the decision making process.
Posted by Mishkin Berteig at 11:48 PM | |
Empower the Team
Empowerment is the ability of a team to make decisions about how to do their work and execute on those decisions without outside interference. If a team is empowered, then it will be more capable of responding to change, and it will be able to focus on manifesting the members' creative potential. Empowerment comes from a combination of several factors:
1. members of the team have a deep sense of self-worth that includes nobility, and contribution to the progress of humanity
2. tacit or explicit authority and responsibility for results as a team and as individuals
3. a team environment which is honest, trusting and allows for mistakes
4. the absence of personal attacks against individuals on the team and in particular a total lack of gossip and backbiting
There are several ways that team members will demonstrate their empowerment. People will derive joy from their work. Team members will be dedicated to the work and the team. Individuals on the team will frequently take individual initiative to accomplish tasks, share insights, and develop improvements. Spontaneous leadership will become common. Individuals will step out of comfort zones or areas of specialization in order to assist the team.
Empowering a team is a process that can sometimes take a great deal of time and effort. In order to start on this process, the team members should carefully listen to each other and ask many questions. More mature individuals should lead and teach by example. And all the team members can start to question and challenge the rules and procedures of an environment that are preventing effective work. If the team is in an organizational environment where team members have management to report to, then management must be aware of this opportunity for empowerment and support it.
An empowered team can gradually understand and internalize the agile work principles (People are Creators, Change is Constant, Perception mediates Reality). By internalizing these principles, a team can move beyond specific agile work practices and become a high performing team setting their own work practices.
Jeff Sutherland has a very brief blurb about the progress of teams as they evolve in their use of Scrum.
Future entries here will discuss the methods of creating empowered teams.
Posted by Mishkin Berteig at 11:04 PM | |
Information Radiators
An information radiator is a large display of critical team information that is continuously updated and located in a spot where the team can see it constantly. The term "information radiator" was introduced extensively with a solid theoretical framework in Agile Software Development by Alistair Cockburn.
Information radiators are typically used to display the state of work packages, the condition of tests or the progress of the team. Team members are usually free to update the information radiator. Some information radiators may have rules about how they are updated.
Whiteboards, flip charts, poster boards or large electronic displays can all be used as the base media for an information radiator. For teams new to adopting agile work practices the best medium is usually a poster board on the wall with index cards and push pins. The index cards have a small amount of information on each of them and the push pins allow them to be moved around.
Information radiators help amplify feedback, empower teams and focus a team on work results. Too many information radiators become confusing to understand and cumbersome to maintain. If an information radiator is not being updated it should be reconsidered and either changed or discarded.
Here is an information radiator used to quickly display the status of multiple projects to an agile Project Management Office:
As the team used an information radiator, it can adapt the display of information to become more appropriate to the way the team is operating and the information they are really concerned about. For example, on the above IR for a PMO, the group may decide that they wish to put red dots on projects that are in trouble in some way.
Some very interesting examples of the effective visual display of information can be found in The Visual Display of Quantitative Information.
Posted by Mishkin Berteig at 06:25 PM | |
May 09, 2005
Reasons for Conflict or Disagreement
As part of the Advanced Scrum Training, Esther Derby presents a section on conflict. One very insightful part of the presentation is a description of four reasons for the existance of conflict or disagreement. They are as follows (adapted from "Advanced Scrum: Collaboration Skills for Scrum Teams" (c)2004-2005 Esther Derby):
1. Lack of Clarity - the communication between parties is missing information or the information is not being communicated in a consistant manner.
2. Position Focus - the parties involved have already each decided on their own solution and are failing to discuss the problem those solutions are addressing.
3. Different Values - the parties are unable to agree because they are holding different sets of values but not articulating those values as part of the discussion.
4. Past History/Personalities - the parties have a previous unresolved conflict that is negatively affecting their ability to work together.
All of these types of conflict are based on either conscious or unconscious failure to be truthful... and therefore the different parties have incompatible perceptions of reality. The Agile Work axiom "Reality is Perceived" then gives us a hint as to how to resolve all of these types of conflict. Find a way to share perception among the parties in conflict so that they have a compatible view of reality.
Posted by Mishkin Berteig at 10:52 PM | | | TrackBack
May 03, 2005
Index Cards as an Agile Work Tool
Index cards are an excellent tool to use to optimize communication. There are two primary types of use for index cards.
1. Dynamic Collaboration
Many types of meetings can be made more collaborative and therefore more effective by the use of index cards. Cards are written on to record ideas. By writing on cards, all the participants in the meeting can see the ideas.
As an example, suppose that a team is examining two competing ideas of some complexity. The team uses two colors of 5x7 index cards and a pile of Sharpie(R) markers. The different card colors represent the competing ideas. Members of the team take cards and write down their comments as they think of them. The team member then reads their card aloud and passes it to a facilitator. The facilitator takes the cards and puts them up on the wall under various categories. The team uses a thinking tool such as PMI (Pluses, Minuses, Interesting) from CoRT to organize the cards.
Contrast this method with someone taking notes. Using the cards allows all the team members to see all the information at the same time. It also allows team members to come up to the wall and either add notes to a card or move cards around.
2. Dynamic Tracking
Teams are more focused when they are constantly aware of the status of their work. Index cards can be used to improve the team's awareness of status information by forming them into an "information radiator".
For example, a team might be working from a list of tasks. Each task can be written on an index card. The task cards can then be put on a wall and organized into groupings based on their completion state. A typical set of states might include "Not Started", "In Progress", "Waiting for Test", "Tested" and "Approved". As team members work on tasks, they move them from group to group. In this way, the team can easily see how much work they have done, and have yet to start. As work progresses, the team gets immediate positive feedback as the number of cards in the "Approved" state grows.
This method can be compared to an online project plan status updated by a project manager. The index card information radiator is participatory and always visible. It requires no effort to check status, and provides tangible motivation and focus for team members.
Posted by Mishkin Berteig at 05:00 PM | |