July 19, 2007
Agile is Not Communism
Last week I taught an introductory course on Agile Work. Normally this is pretty easy stuff. However, I was teaching this course in Bucharest, Romania (cool), and I have come across a substantial, strong and vigorous objection to agile (also cool, but challenging too). Several people in my class are asserting that agile is just like communism and since communism failed, agile is not likely to succeed either. I'm looking for help on this!
I have Googled "agile communism" and come up with some interesting reading:
Does Scrum/XP Violate the Agile Manifesto?
The Agile Method and Other Fairy Tales: QED
I have also done some quick research on communism to check that I understand the comparison and objection. Here is a wiktionary definition of communism:
1. A term used to refer to a number of political philosophies or ideologies which share the belief in the virtue of holding the production resources collectively. 2. A society organized in line with the communist theories, the ultimate aim of which is the abolition of the state and the creation of a classless, stateless society whose members produce according to their abilities and take what they need.
So let's start with that definition.
Holding Production Resources Collectively
Also called: common ownership of the means of production
I suppose there are a few ways to look at this. In an agile environment which encourages (for example) collective code ownership, it might seem like holding the production resources collectively. However, the code is actually the result of production, rather than the Means of Production. This distinction is not trivial. The means of production for a team in an agile environment still include both the tools and the raw materials upon which those tools exercise. In software development (and in most creative work nowadays), the tools are computers and software and other electronic gadgets such as video cameras, telecomm systems, etc. The raw materials are typically intellectual constructs such as images, sounds, ideas, processes (and of course their legal counterparts such as trademarks, copyrights, and patents). Agile methods do not require the team of workers to own these means, nor do agile methods forbid workers from owning these means. In fact, There is one important way in which agile methods are decidedly not communist: every individual owns their own creativity, experience, and knowledge and is only asked to share willingly (and usually in exchange for pay such as salary, stock options or outright corporate ownership). I believe this passage clarifies things nicely:
Marxists define economic systems in terms of how the means of production are used, and which social class controls them. Thus, in capitalism, the means of production are controlled by the bourgeoisie, (the "capitalists" - the owners of capital), while in socialism they are controlled by the people's elected representatives and in communism they are controlled collectively by the people themselves. [Means of Production]
Agile methods, if anything, tend towards capitalism in this regard. (Although a whole other question could be asked about just how much control the owners of a corporation really have given delegated authority through the board of directors to the chief executive staff _and_ the abrogated authority through mutual funds, pension funds, holding companies, and trusts _and_ the limitations on that control through the blunt instrument of voting shares _and_ the influences on that control through the control of information by financial analysts and the media...)
Ultimate Aim of The Creation of a Classless, Stateless Society
Well, this certainly isn't the aim of agile methods that I am aware of. The aims of agile methods as I understand them includes:
- Building stuff that stakeholders like
- Creating an environment for team members to exercise their creativity
- Doing all this in a way that responds well to pervasive frequent change
Again, I can understand why there might be some confusion here. Agile methods promote these three aims by doing something that looks just a little like a classless organizational structure. Typically, agile (and lean) environments start to have a higher manager to staff ratio (fewer managers), encourage self-organizing, cross-functional teams, and emphasize team goal setting, commitment and accountability. This might seem classless (and stateless/managementless) until one examines what is not said: Agile does not claim that every team member is exactly equal, it does not require that every team member do exactly the same thing, it does not require that every team member give up _all_ their individual preferences (although certainly it would be hard for someone who didn't like talking to other people to be part of an agile team... so I guess some individual preferences won't work in an agile team), it does not encourage every team member to do exactly the same amount of work regardless of if you are measuring effort or output.
Now admittedly, when I am presenting examples of self-organizing teams, I do sometimes use examples that come close to classless stateless teams... but that's just to show that this is a possibility and allowable in an agile environment, not that it is the only way.
Those practices in agile methods that do seem like classlessness and statelessness are not aims... they are means. A self-organizing, self-managing team, is means to an end. It is not an aim in itself. Why does this matter? For the simple reason that it is always bad to confuse means and ends. The end cannot justify the means (classlessness and statelessness imposed by revolution)... and nor can the means justify the ends (classlessness and statelessness that results in apathy, boredom and low productivity). So the fact that self-organization is a means is a way for us to decide if it is worthwhile. The evidence for self-organizing teams in a business context is strong (lots of links and articles and books on this blog as well as others). Most team members enjoy being self-directed in a way that is collaborative with other professionals. So both the ends are good - productivity - and the means are good - happy people.
Members Produce According to Their Abilities and Take What They Need
To me, "produce according to their abilities" sounds a lot like a tautology. Certainly, team members can produce no more than their abilities! From an agile perspective, this isn't even what we are interested in... we are interested in the multiplicative effect of teams of people working together effectively so that the result of the work is greater than the sum of the individual abilities. There is now substantial evidence that this is not just possible, but a likely outcome of group work (see Research on Group Effectiveness vs Individuals among many others). My favorite phrase for this is "Unity in Diversity" which describes a group of people who have united around a common goal, but with each individual having talents, experiences, knowledge, patterns of behavior, and insights that are all different from each other.
The second part of the phrase "take what they need" is another piece of this pie that has absolutely no relationship to agile methods. Again, there is evidence that this is specifically not supported. Lean methods encourage compensation that is based on a number of things including: contribution to results in one's sphere of influence (rather than the more limited sphere of responsibility) and the number of skills you have mastered and use to contribute to the work.
Disconnecting reward from results is an obvious problem. While people do have altruistic feelings, we also are clearly motivated by praise
Some Similarities
One of the attendees of the course, a woman by the name of Christina, provided me with some notes based on her understanding of Agile and Communism and she listed these similarities:
- They both rely on participation, rather than executing orders.
- One aim is less frustration.
- They use some similar phrases such as multidisciplinary / cross-functional.
- They both ask people to evaluate each other.
And What about Reality?
Well, I haven't lived in a communist environment so I admit that my ability to talk intelligently about this is not what I would like it to be. I am interested in people out there who might be able to help me with this.
Here are some questions for people who have actually experienced communism:
- What are the actual, in-practice similarities between agile and communism?
- What are the in-practice differences between agile and communism?
- Why did communism fail and how might this affect the success of agile methods?
- How can we safeguard agile from falling into the same problems?
Can anyone out there help please?
Posted by Mishkin Berteig at 06:13 PM | |
June 04, 2007
The Culture of Time
Thanks to Deborah Hartmann who pointed out these links:
Perception of Time
Timeless Time
Personally, I'm strongly on the side of "polychronic"... and I'm being strongly encouraged to move to a more "monochronic" approach to time management. All my life I have struggled with calendars, PDAs etc. We'll see how it goes!
Posted by Mishkin Berteig at 10:00 PM | |
January 17, 2007
The Inner Ring
Here's a slightly off-topic, but nevertheless excellent read: "The Inner Ring" by C S Lewis. This is a talk given by C S Lewis to what seems to be a group of university students. In it, he describes the notion of the inner ring and the desire to be "in". It is amazing how much our culture in North America and our corporate culture is driven by this desire. I'll leave it to you to decide if this is good or bad.
Posted by Mishkin Berteig at 04:23 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 | |
December 18, 2006
Lean, Agile and Capitalism - Just a Thought
It occurred to me to ask: If the "invisible hand" in the free markets of capitalism is making for efficient markets, efficient work... then why is there some much room for improvement when we start using non-competitive, collaborative techniques such as lean and agile?
And if these collaborative techniques work on a small scale to improve efficiency, does this mean that we could do this across organizations as a "replacement" for capitalism somehow?
In agile methods, we "assume positive intent" on the part of individuals. What if we could do this across organizations? I'm not living in a dream world yet, but I think I have an inkling of what it might look like: Toyota and its collaborative, leaned-out supply chain.
Posted by Mishkin Berteig at 06:39 PM | |
December 07, 2006
Peformance Goals - The Wisdom of Teams
As I continue my enthralled read through "The Wisdom of Teams: Creating the High-Performance Organization
The Performance Goal
This concept and practice is an essential condition for a team to become a high performance team. The Performance Goal is a specific, measurable, challenging goal that is given to and/or adopted by the team. It is a statement or description of a goal that answers "why?" and "what?" questions, but specifically avoids answering "how?". It is not a description of activities, it is a statement of desired results. The team is left with the full authority to answer "how?" and implement it.
This concept is essential for setting the initial boundaries of self-organization. By defining "what" and "why", the team is left free to be creative about the solution. The Performance Goal is also essential to building team accountability (as opposed to individual or externalized accountability). Every action, plan, mistake and success are oriented around the Performance Goal.
From the book:
The hunger for performance is far more important to team success than team-building exercises, special incentives, or team leaders with ideal profiles. In fact, teams often form around such challenges without any help or support from management. Conversely, potential teams without such challenges usually fail to become teams.
I would also like to point out a great blog entry I found that shows some of the other side of dealing with teams and present some cautionary words about the potential pitfalls of working in teams.
In an Agile Work environment, the starting point for a performance goal is simply the delivery of valuable work at the end of their very first iteration. This is often a substantial challenge to a team and an organization. For some teams that have worked for a long time in a "waterfall" or phase-based project environment, it can be almost unthinkable that valuable results could be delivered in one tenth or one twentieth of the "normal" amount of time.
However, simply delivering value at the end of each iteration is probably not going to sustain the development of a high performance team for very long. Rather, the overall objective or goal of the project has to be important and compelling. Much work these days is _not_ important and compelling. In fact, many people become cynical about work because they are stuck doing a high proportion of work that is bureaucratic or due to chaotic circumstances.
As a reminder, the books "Good to Great
I frequently work with organizations where a team has been formed up, told to use agile methods, and then also told how to do their work. Really great examples of this are things like: "we want you to self-organize, but you have to build this huge system using J2EE." The the problem with this is simply that it may in fact be ten times less expensive to build the system with Ruby. However, someone has decided (possibly for defensible reasons) that J2EE is the technology platform that must be used. In this circumstance, someone external to the team has stepped over the boundary of "why" and "what" and also included some "how" in the team's goals. The team is not even allowed to consider the possibility that something might work just as well and be much less expensive. Not only that, but the stakeholders haven't even really stated "why" the system is being built and so the team can't evaluate technology choices. There is no standard around which to self-organize. I admit that I am using a simplistic example here, but the pattern is something that I have seen over and over again.
Posted by Mishkin Berteig at 11:44 PM | |
November 15, 2006
The Case for Context Switching
Recently, Dimitri Zimine wrote an excellent little story about context switching. Joel Spolsky writes in "From the 'You Call this Agile' Department":
Dmitri is only looking at one side of the cost/benefit equation. He's laid out a very convincing argument why Sarah should not interrupt her carefully planned two week iteration, but he hasn't even mentioned arguments for the other side: the important sale that will be lost.
Okay... I'll bite.
Let's look at that argument from the perspective of the sales person first since that is where Joel's concern starts:
The Sales Guy Perspective
"I need the 'ezhibal' feature now! Big bucks coming soon if we can get it now."
Let's suppose that this urgent email has come in somewhere near the start of our two week iteration. The normal response to this in Scrum is to push back a little. The ScrumMaster says something to the effect of: "Look if you wait 7 days we can put this on the top of the list for our next iteration."
First reaction, and it's a normal one, is for Sales Guy to freak out. I've actually heard people saying things like "You're going to lose your job over this! I'm getting the VP involved and he's not going to like it" and then they stalk off to find the big dog to come and bark at us. Anyway, let's pretend that the Sales Guy is willing to be reasonable and not instantly escalate the "problem". So what he actually says is: "Look, this is super important, it'll probably only take a few minutes for us to talk about it and then we can figure out how long it will take to fix. Let's just do a quick phone call and yadda, yadda, yadda, blah dee blah..."
Enough of the Sales Guy perspective.
Nowadays, if I'm in this situation, I do a value assessement. I tell the team to keep working on their plan, nothing's changed yet, and I sit down with Sales Guy and the person who's sponsoring the current work and we start a discussion about the options of which there are really only two that work in Scrum:
- Stay the Course
- Cancel the Iteration
First, let's talk about how we decide which option to take. Then we'll talk about why.
Deciding on the option is easy. You look at the value of the work currently being done and compare it to the value of the work that Sales Guy needs. You take into account probabilities. If Sales Guy doesn't have a signed contract, then it's hard to day if there's going to be any real revenue from the 'ezhibal' feature. Still, you might be able to do an assessment of the probabilities based on your level of trust and history with the client, etc. You also need to take into account the time value of money. Does delaying the current work have consequences for another client or stakeholder? What is the cost of those consequences.
This is a relatively simple cost/benefit analysis and comparison. If you're not comfortable with money and numbers and spreadsheets, you better get comfortable!
Okay, so we have a way of comparing the two bits of work. Now let's look at the two "allowed" responses and a third "bad" response.
Stay the Course
Turns out that the potential benefit of the stuff Sales Guy wants is not quite as high as the potential benefit of the stuff that Suzie Stakeholder prioritized for the current iteration. Well, that's easy. Put the request from Sales Guy in our prioritized list of work and get to it when there is an appropriate level of benefit relative to the other work.
Cancel the Iteration
The stuff Sales Guy wants is super-valuable. So let's get the whole team to stop what they are doing and everyone supports this very valuble work. Stopping the whole team is appropriate because obvioulsy, the stuff they're working on isn't as valuable. Oh, and because we treat a team as a unit in Scrum. And because the team needs to commit to work, not individuals. This isn't so obvious... more later.
Peel Sarah off to do the 'ezhibal' Feature
This is what normally happens, and in a "normal" non-agile environment, it's probably okay. In a non-agile environment, Sarah hasn't made any commitments (she's been forced to agree to dates and scope, etc., but she hasn't made a commitment that she is empowered to live up to). So if she goes off and does this one little thing, it probably will be just business as usual. In an agile environment, the team has made a commitment and doing this work this way invalidates the team's commitment.
Why do we do it this way? The main reason is around trust and commitment. Yup, it's that soft icky stuff that we're so incredibly bad at that customers think that bugs are normal, that management shoves the kitchen sink into projects in the frustrated hope that they'll get something out of the IT team at the end of the project. Sound familiar to anyone?
Anyway. An iteration is a commitment. It is a firm and solid commitment. The team as a group of smart and honorable people is making a definite commitment to the rest of the organization to get a certain amount of work done in a fixed amount of time. In return, management is agreeing to give the team every support in reaching this commitment. When a team is new at this, they might get it wrong. But having done this with dozens of teams now, I know that after a few tries, the team gets the hang of it and commits to appropriate amounts of work, and management provides appropriate levels of support.
This commitment is essential for developing trust. And anything that comes in the way of the team meeting its commitment is considered "BAD". An obstacle to do away with.
This is interesting, because Joel's second example is about defects. And I strongly agree that defects are "BAD" and need to be dealt with at a very high level of priority. The reason is simple: they prevent a team from meeting its commitment.
One team I was coaching was constantly bombarded by these types of it'll-just-take-a-few-minutes-need-it-asap requests. They had many stakeholders and very very limited resources to service these requests. They had several small projects that were taking literally years to do because they couldn't get enough concentrated time on any one thing. This was considered normal and good in their environment.
The trouble is, no one had really looked at the overall consequences. Everyone was doing local optimization. For us geeks, we all know that local optimization is something to be avoided if possible. We climb a peak only to discover that we have to climb back down a ways to get up to the higher peak we now see is next to this one. We climb up that one only to discover yet another higher peak even further along thus requiring us to climb down and up again... When really what we should have done is stepped back a ways, looked at the lay of the land and said, "hey, that peak over there is the highest of them all, let's go climb that one."
Scrum helps us avoid local optimization by forcing all feature requests for a team to be prioritized in a list of work, and by allowing the team to complete small pieces of work so it actually gets _something_ done that you can learn from.
Joel said:
Agile is not supposed to be about swapping out one set of bureaucratic, rigid procedures for another equally rigid set of procedures that still doesn't take customer's needs into account.
True enough! But it also demonstrates a serious lack of understanding about what is being done in Dmitri's example! First of all, without being agile at all, it is possible to switch from 18 month projects to two week projects. Both can be bureaucratic as you please (well, actually, there's only so much bureaucracy you can cram into two weeks and still get something done). The shorter projects will allow you to be much more responsive to customer needs... by definition!
So what happens when you add in all the other things that agile really is about? Transparency. Truthfulness. Creativity. Learning. Meta-Learning. Prioritization. Self-Organizating Teams. Eliminating Waste.
Well, first of what you get is something that's damn hard to do right. It goes against almost everything we've been taught to do: the extreme of heroics of the extreme of careful planning and process.
Secondly, what you get is something that needs safety zones and meta-rules. Like mutual, freely-given, team-to-stakeholders commitment. Like assuming positive intent.
And thirdly, what you get is an environment where not only is the business getting what it needs more than it used to, but also, the team likes working with the business, and the business likes working with the team.
I admit that the point Joel is making isn't too different. Yes: look at the costs and the benefits. But agile isn't quite about instantaneous responsiveness. That's a red herring and I'm suprised that Joel threw it's stinky carcass into the discussion. Agile is also about balancing that responsiveness with the overall view of value for the team and the organization. The tool for doing that is the prioritized list of work, not the email message from Sales Guy to Sarah.
Posted by Mishkin Berteig at 04:13 AM | |
November 14, 2006
Process Facilitator "Smells"
I have now trained over one hundred people in my Agile Project Managmenet / ScrumMaster Certification course. I'm starting to see and hear some of the results of this training. There are a couple specific "smells" that I have become aware of.
Fortunately, I've been able to provide coaching to some of the organizations that have sent people to my course. There are quite a number of good things that happen, but there are a couple of things that seem to be "natural" misunderstandings.
- Spectating
I put a lot of emphasis on the idea of a self-organizing team in my course. There are a number of exercises, an hour-long section, and many other points during the course when it comes up. With all of this emphasis, it seems that a few people have come away from the course with an extremely hands-off approach to the Process Facilitator role (ScrumMaster/Agile Project Manager). I think this is a natural and probably good reaction to the heavy-handed command & control approach that these people come from. However, there are a few things that should be considered minimum levels of engagement (listed below). - Problem Solving
There is also a great deal of emphasis put in the course on removing obstacles. I have seen several cases where it becomes the habit of the Process Facilitator to start solving every problem. This can happen in day-to-day work, and also in the retrospectives. Again, this seems to be a natural consequence of the desire to get in there and be of value. However, if the Process Facilitator writes down all the "things that need impovement" from the retrospective and then says "Okay! I'll take care of these things." then you know that the Process Facilitator has gone too far.
Appropriate Process Facilitator Engagement
Here are a few ideas on an appropriate level of engagement. Finding the right balance of enagement is not easy and there is no exact formula to follow. Partly it depends on your personality and skills as a Process Facilitator, partly it depends on the capabilities of the team, and partly it depends on the constraints of your work environment. Nevertheless, there are some types of engagement that you can persue with confidence. Here are a few concrete guidelines:
- Team Membership
If you aren't saying "we" when referring to the team, you aren't engaged enough. The Process Facilitator is a member of the team. - Colocation
Most of your time should be spent sitting with the team. If the team isn't colocated, then you should be spending most of your time physically visiting each team member. - Obligations
The Process Facilitator is a catalyst. You must track all the obstacles and "needs improvement" things that the team raises, and then make sure that they get fixed... without going in and fixing everything yourself. Ultimately, your job is to work yourself out of a job. - Assertiveness
The organization that the team is working in will be creating some of the obstacles that the team is facing. Being assertive is critical to helping the organization face and then overcome some of these obstacles.
Posted by Mishkin Berteig at 01:49 PM | |
November 12, 2006
More on Scaling Agile
One problem with having multiple teams working on the same project will be the tendency to compare the teams' performance. Why is this a problem?
Why Not Compare Team Performance?
One of the main reasons is that the teams need to be collaborating not competing. There can be a small amount of friendly competition that might come naturally, but as soon as management starts paying attention to differences in team performance, the competition starts to get serious.
In the case of multiple teams working on the same project, the goal should be to maximize overall performance, not individual team performance. Too much competition can lead to unintentional or deliberate sabotage: failed communication, incomplete communication and downright dishonesty.
Motivating Teams without Comparing Them!
As Mary Poppendieck has written, measure up [pdf]. In a single-team situation this means that individuals are measured and rewarded based on team performance (their sphere of influence). In a multi-team environment, that means that the group of teams should be measured as a group and compensated as a group. This will encourage all teams to work towards the success of the overall project. I personally believe there is some room for individual-based compensation, but the way it is handled needs to be done so that it does not encourage sub-optimal behavior.
As well, each team can keep track of their velocity. Some coaches recommend using "ideal hours" or some other units to determine velocity (velocity = estimated work remaining completed / iteration). The trouble with doing this with multiple teams is that there will be a very real tendency to want to compare each team's velocity. Since velocity is a useful measure for team capacity, it is important to still have a way to measure it. One simple way to do this to prevent comparison is to use different units for each team. Team One might be measuring velocity in Estimated Ping Pong Balls Completed / Iteration... Team Two in Estimated Bananas Completed / Iteration... Team Three in Estimated Bogo-MIPS Completed / Iteration... etc. etc.
Motivating Collaboration
First off, management must make visible commitments to eliminating barriers to collaboration. For example, it is a great sign of commitment to re-organize office spaces so that all the teams are sitting near to each other. Every time the Process Facilitator identifies an obstacle that relates to collaboration (tools, process, physical environment, etc.) management should get right on it and fix it.
An ongoing investment in team-building training, workshops and exercises is also helpful. This type of investment helps people gain the skills necessary to work effectively with other people. Again, individuals need to see and believe that management cares about and values teams.
Finally, one of my pet peeves: when a project is over, keep the team together! Do not break them up and redistribute your "resources" to other efforts. The value of those people working together is substantial. The value of those people working together as a high-performance team is incredible! In a multi-team situation, it is reasonable to take teams from the overall group and re-distribute their efforts... but just don't break up the individual teams.
Miscellaneous Notes on Scaling Agile:
Twelve is still the maximum recommended size for a single agile team. Seven is really the sweet spot. A team larger than twelve people just takes too long to get into the Performing stage of team development. If you feel like your project needs more than twelve people actively involved, then you probably want to split into two or more teams... and then you have "scaled" agile.
If you have three teams of five people (or some similar configuration of people just over the 12 person limit), then they will work as a very close-knit group and a lot of the time will act as if they were a single team. They will probably plan iterations and do demos and retrospectives together.
Twelve teams working on the same project at once is about the maximum number before communication overhead is slowing everyone down too much. This is largely a factor of trust: with 150 or fewer people involved in an effort, it is possible for everyone to know everyone. More than that many people and it is no longer possible. Trust is just not an option anymore and bureaucratic controls take over.
If for some reason you need to do something in a small amount of time and you think it's going to take more than twelve teams of twelve people...? Break the effort into smaller chunks. Divide and conquer. Division can be across functional areas, structural areas or time.
Although I have heard of agile methods being used with groups larger than this, I haven't heard any success stories :-)
Check out my earlier introductory article on Scaling Agile in a large project situation.
Dean Leffingwell has an article about practices needed for scaled-up efforts at the Agile Journal. I glanced through it, but I admit that after I disagreed with his very first point (Intentional Architecture), I started to pay less attention.
He claims that refactoring of large systems is not possible (or at least infeasible). The odd thing is, most large projects that I have been involved with are being done exactly because an old system is not refactorable. A large telecom system, a large insurance system, a large data warehouse and a large GIS system are all being done with scaled up agile methods exactly because the old systems that are currently in place have become ossified to the point where they must be replaced.
These old systems were originally built with phase-based development approaches. At some point, people stopped refactoring because they were not given the space to do so. This drop in code quality turned into technical debt. The technical debt accumulated to the point where it was unbearable (maintenance costs, cost of change, etc.).
The problem with intentional architecture is that it goes back to the old assumption that you can do a good design for a system without the constant feedback from review, deployment and use done on a very short cycle time. Over and over, we are faced with the painful consequences of this attitude, and that is one of the key reasons we started to work with agile methods in the first place.
Martin Fowler makes a good case that scaling agile is the last thing you should do. I don't disagree! Scale your agile teams at your own risk!
It's nice for me to be able to say that I've worked on some agile projects over $10,000,000 in size, but the fact is that the cost could have been reduced substantially if the team size was lowered and the deadline extended. It is (relatively) simple to do a cost/benefit analysis of cross-team-coordination-overhead vs. the time value of early delivery of more functionality... although I've never seen anyone do it! If you know of an example of an organization doing this in a realistic way, I'd love to hear about it!
Are there other ways of supporting cross-team collaboration that you have seen?
Posted by Mishkin Berteig at 09:13 AM | |
November 07, 2006
Scaling Agile Projects
More and more, organizations are applying agile methods to large projects or efforts that require more than a single team. There are three dimensions or concerns of coordination. It is critical that all three be addressed, but there are many ways of addressing them. Here I will simply list these three types of coordination and make some simple suggestions of how to implement them.
I have now had the opportunity to work with several clients where they are applying agile methods to projects with budgets that are greater than $10,000,000. All of them are using multiple teams to work on the same overall project/program. Out of this experience (along with some good reading along the way), I have come to understand that the following three types of coordination are the essential ones:
Value
In order to maintain the "early and frequent" delivery of value that agile methods propose, it is important that the work of the effort be coordinated to maximize early delivery of value. From this perspective, there are often many cooks in the kitchen. I have seen a "Product Owner Team", a "Customer Team", and a number of variations of this type. In order to do the coordination work effectively, it is still necessary to make sure of two things:
- Maintain a single Work Queue that prioritizes the work and from which all the teams select items.
- Have a single person in the "buck stops here" role who can make final binding decisions about work priority and content.
These two items have some implications for the organization.
First, the teams must be organized to be generalist: each team should be able to handle any item on the Work Queue. Not every team is going to be equal in abilities and this can be accomodated in a number of ways. My favorite so far comes from an excellent agile coach Dave West
The second implication is that the customer or product team (Queue Master) must have the availability to support multiple teams in a timely fashion. Ideally, there are individuals on each team who can make judgement calls about features, functionality, constraints etc. on the work and provide quick answers to questions. This is not always easy since the people doing this often have a special area of expertise and it is difficult for them to work outside this area. Just as team members are asked to become generalizing specialists, so must the people who are responsible for determining value in a project.
Process
An agile process endeavors to provide a minimally structured way to do three things: deliver value early, then learn about what is high in value and deliver that more, and finally, learn how to deliver value more effectively.
That third activity, learning how to deliver value more effectively, is facilitated by the Process Facilitator. The Process Facilitator keeps a visible list of obstacles and works collaboratively with the Team and the Stakeholders to resolve obstacles on the list.
In a multi-team environment, there may be a single Process Facilitator working with each team. Like with the Work Queue, it is often necessary to have a single Record of Obstacles for the entire project.
Technique
People develop skill and knowledge in the use of their tools. Most types of work have a special vocabularly that only makes sense to other people also doing that work. For example, the field of computer programming has programming languages, integrated development environments, build tools, testing tools, algorithms, and a host of other techniques. The field of film-making has cameras, film, directorial techniques, lighting, story structure, it's own esoteric vocabulary, and other techniques. Likewise for construction, law, medicine, drama, education, etc. etc. etc.
In a large Agile Work project, teams need a way to coordinate their technique to produce integrated, consistent and compatible results. As well, individuals on the teams may discover or create new ways of doing things that would be valuable for the other teams to know about and use.
The most effective way of coordinating technique across teams is for strong members of each team to gather regularly to review the way work is being done. This "technical support group" can look at tools, reuse, automation, patterns, vocabularly and any other "how to" aspects of the work. It is critical that these people are actively involved in work being done on a delivery team so that efforts of the technical support group do not become academic or "ivory tower".
In certain environments, it may be useful to have this techincal support group become a team with a clear allocation of time apart from the regular delivery teams. In this case, this technical support team would have its own Work Queue that consisted of requests, ideas, concerns, and opportunities presented by the regular delivery teams.
I have seen all three aspects of coordination implemented in large multi-team projects. Some of the common challenges include:
- Generalist Teams.
It is difficult enough to create cross-functional teams where people are willing to become generalizing specialists. While it is important to create generalist teams, most organizations should expect to set up non-ideal specialist teams (sometimes by line-of-business) and support their development into generalist teams. - Technical Coordination.
Often organizations have a design or technical review group composed of the "experts". These people are often isolated from the actual work being performed by the teams. It is difficult, yet critical, that these people actually be involved in day-to-day work on the teams.
Posted by Mishkin Berteig at 09:15 AM | |
September 11, 2006
Agile Team Launch - a Howto Guide for Managers
Starting off on the right foot is just as important as it ever was. However, with Agile Work, this takes on a significantly different meaning than it does in other methods as the emphasis of what is "right" is also significantly different. This is a short guide on how to successfully launch a team using Agile Work.
0. Do what you need to in your organization to get a project and its budget approved. This usually involves some sort of business case, project charter and approval process. This may sound obvious, but the organizational support that this provides is essential.
1. Management must have a basic understanding of the method and in particular the roles: Queue Master, Process Facilitator and Team. This can be accomplished in a number of ways: reading, attending a workshop, or bringing a coach in to do a brief presentation. By "management" is meant at least the person sponsoring the launch of an agile team.
2. Individual people must be identified to fill the Queue Master and Process Facilitator roles. At first, these people should be assigned to these roles full-time and relieved of their previous duties. Ideally, the people filling these roles are volunteers from a pre-selected group of appropriate candidates.
3. The Queue Master and Process Facilitator must both get some initial training. For this, the following books are recommended for both roles: Agile Estimating and Planning (Robert C. Martin Series)
4. Form up the team. Getting this right is not easy: the team needs to remain relatively small (5 people is about right), but at the same time include people with all the skills necessary to deliver the whole project. You need people who are good at the various technical skills needed, the people skills needed, the problem-solving and analysis skills needed, and the administrative skills. All these people need to be part of the team right from the start. Again, for emphasis: do not start the project before all these people and their skills are dedicated to the team and they have been relieved of their previous duties. Forming the team includes logistical concerns such as where the team will sit, making sure they have the right equipment for their work, etc.
5. If you are trying agile for the first time, don't consider using a distributed team or off-shore resources. Nor telecommuters. This type of stuff is better left for once your organization has more experience with agile methods.
6. Provide initial training to your team. Include the Queue Master and Process Facilitator in this training (they are considered part of the team). Also include any significant stakeholders in the results of the project. Give them, at a minimum, a one-day introduction to agile.
7. The Queue Master creates an initial Work Queue. The rest of the team should participate in this process. The creation of this Work Queue must be timeboxed. I advise that it should only be given 1 or 2 percent of the overall project time. Decide before you start on how long will be given to this. The end result of this is a Work Queue that has some number of work items defined, understood by the team, valued, costed, and prioritized. The Work Queue does not have to be "finished". It is more important to hold to the timebox than to get the Work Queue "right". Remember that the Work Queue will continue to be refined as the team progresses in its work. Do not under any circumstances create the initial Work Queue in the absence of the team!
8. Run a brief project workshop. In this workshop, the team answers basic questions about the nature of the project run with agile methods such as:
- what is the length of our iterations?
- what are the team's core hours (when do all the team members commit to working together as opposed to working on administrivia)?
- what other teams/groups do we need to work with?
- are we missing any critical skills (now that we have seen the initial Work Queue)?
- what are the priorities of the project (quality, scope, time, budget, experimentation, etc.)?
9. OPTIONAL ITEMS:
- Consider doing a workshop on corporate culture and agile methods to help the team understand some of the challenges it will face and where it can find support
- Consider doing some initial team building exercises. Particularly if people on the team haven't worked together previously, this can help the team to get over some initial hurdles.
- Consider getting junior members of the team some additional training on the techniques, technologies or tools used in the team's work. This can be arranged so that it is done simultaneously with some of the team's early iterations.
- Consider engaging a coach or mentor for your Process Facilitator. This coach can be someone inside the organization who has extensive experience with agile methods or an external consultant who comes for a limited time to help your Process Facilitator.
None of these optional items should unduly delay the start of the first iteration.
10. Start your first iteration. There should be little or no delay or waiting between the creation of the team and the start of the first iteration. At this point the Process Facilitator is responsible for the process, the Queue Master is responsible for the value delivered, and the Team is responsible for delivering results.
Posted by Mishkin Berteig at 11:36 AM | |
September 05, 2006
The Seven Core Practices of Agile Work
Agile Work consists of seven core practices. These practices form a solid starting point for any person, team or community that wishes to follow the Middle Way to Excellence.
Self-Organizing Team
Any group of people that wish to be an Agile Team need to take the initiative to determine for themselves how they are going to work (process) and how they are going to do the work (product). The term "team" really applies quite broadly to any size group of people that are working together towards a common goal.
Teams go through stages of development as they perform their work. The most important result of team development is the team itself, and not the specific skills and abilities that the individuals learn.
If the team is part of a broader organization, that organization must give the team the authority, space and safety to learn to be self-organizing. The organization's leadership is responsible for determining the "why?", some constraints on "how?", and then letting the team respond to the need as best as it can.
Also Known As: Whole Team (Extreme Programming), Cross-Functional Team (business management).
Deliver Frequently
Agile Work uses short fixed periods of time to frame the process of delivering something of value. Each of these iterations or timeboxes is structured so that the team or group actually finishes a piece of work and delivers it to stakeholders. Then, the team builds on what has previously been delivered to do it again in the same short amount of time.
The sooner that valuable results can be delivered, the more value can be obtained from those results. This extra value is derived from opportunities such as earlier sales, competitive advantage, early feedback, and risk reduction.
There is an explicit tradeoff: the shorter the time to delivery, the smaller the piece of value will be. But, like investing in one's retirement account, the earlier you start, even with small amounts of money, the better off you are in the long run.
Also Known As: Sprint (Scrum), Iteration (Extreme Programming), Timeboxing (generic), Time Value of Money (accounting).
Plan to Learn
Every type of work is governed by a Horizon of Predictability. Any plan that extends beyond this horizon of predictability is bound to fail. Agile work uses an explicit learning cycle tied in with the planning of work to accomodate this inevitable change.
First, a goal is required. This goal can be long-term. Teams using Agile Work then create a queue of work items to be done in order to reach this goal. Each iteration, some of these items are selected, finished and then the queue is adjusted. The changes in the work queue are based on external factors, and learning that the team does as it goes.
One of the most effective methods for the team to learn about how it is doing its work is the retrospective. After each delivery of results, the team holds a retrospective to examine how it can improve.
Also Known As: Inspect and Adapt (Scrum), Kaizen (Lean), Adaptive Planning (generic).
Communicate Powerfully
A team needs to have effective means of communicating, both amongst team members and also to stakeholders. To Communicate Powerfully, a team needs to prefer in-person communication over distributed communication. Synchronous over asynchronous communication. High-bandwidth over low-bandwidth communication. Multi-mode communication over single-mode communication.
The results of failing to communicate powerfully include wasted time for waiting, misunderstandings leading to defects or re-work, slower development of trust, slower team-building, and ultimately a failure to align perceptions of reality.
The single most effective means to communicate powerfully, is to put all the team in a room together where they can do their work, every day for the majority of the work time.
Some types of work do not lend themselves to this approach (e.g. creating a documentary video), but every effort should be made to improve communication.
Also Known As: Visibility (Scrum), Whole Team and Team Room (Extreme Programming), War Room (business management).
Test Everything
Defects are one of the most critical types of waste to eliminate from a work process. By testing everything, by driving all the work of a team by creating test cases to check the work, a team can reach extremely high quality levels. This ability to prevent defects is so important that only an executive level decision should be considered sufficient to allow defects into a work process. Quality is not negotiable.
In Agile Work, removing a defect is the only type of work that takes priority over any new features/functionality/production. If the end result desired is to maximize value, then removing defects is an important means to that end.
A team has an ethical duty to discover new ways to effectively test their work. This can be through the use of tools, various feedback mechanisms, automation, and good old problem-solving abilities.
Also Known As: Canary in the Coal Mine (Scrum), Test-Driven Development (Extreme Programming), Defects per Opportunities (Six-Sigma).
Measure Value
Since Reality is Perceived, it is important for an agile team and organization to have a clear method of describing and perceiving what is important for the organization. Measuring value is a critical method for describing and perceiving what is important.
A single metric can be used to drive all the measurement and goal-setting and rewards in an organization. All other measurements are secondary and must be treated as such: limited in use and temporary.
There are many things which are easier to measure than value. It is often easy to measure cost, or hours worked, or defects found, or estimate vs. actual... etc. However, all of these other measurements either implicitly or explicitly drive sub-optimal behavior.
Also Known As: Measuring Results (Scrum), ROI (business management), Economic Driver (Good to Great), Running Tested Features (Extreme Programming).
Clear the Path
Everyone in an organization using Agile Work takes responsibility for clearing the path, removing the obstacles that prevent work from being done effectively. Clearing the Path doesn't just mean expedient, quick fixes to problems, but rather taking the time to look at an obstacle and do the best possible to remove it permanently so that it never blocks the path again.
In the Agile Work method, the Process Facilitator is the person who is responsible for tracking obstacles and ensuring that the path is cleared. To do this, the Process Facilitator maintains a Record of Obstacles.
Clearing the Path is sometimes painful work that exposes things we would rather not deal with. As a result, it is critical that people build their capacity for truthfulness and work to develop trust amongst each other. Building a capacity for truthfulness is not something that can be done by using an explicit process.
Also Known As: Removing Obstacles (Scrum), Stopping the Line (Lean).
Remember also, that these practices must always be viewed and implemented in the context of the Agile Axioms. These axioms provide a check to ensure that the practices are not being applied blindly, but rather applied appropriately to the given situation.
Posted by Mishkin Berteig at 09:09 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 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 | |
April 21, 2006
Agile Adoption Stages for Teams
We know that teams go through identifiable stages of development: forming, storming, norming and performing (1). What exactly does this look like for an Agile team?
Forming
Here the team is typically innundated with three sources of new information: the Agile process and practices, the nature of the project and the other people in the team. This can be overwhelming and people will react in diverse ways: calm wait-and-see, rebelliousness, passive-aggressive, excitement, etc. If the team has an effective coach or mentor shepherding them through this, then feelings will tend towards excitement. The reality of learning so much at the same time will make the first few weeks of the team's time together quite exhausting. People will be actively fighting old habits, and people around the team will be asking lots of questions. Retrospectives will usually show that the team is impressed with their own teamwork and communication and will also show some disappointment with specific agile work practices.
Storming
After only one or two iterations, the team will transition into the Storming stage of development. Because Agile methods "front-load" the learning and the crisis, this forming stage comes fast, but it is also relatively mild. (Front-loading the learning means that all the problems that an organization has that hold it back from delivering quality work quickly are made visible in the first couple of iterations.) People are not used to a project being in crisis right at the start. It is critical for a coach or mentor or manager to be aware of this effect and expecting it. Again, for emphasis: an Agile project is in crisis immediately!... and this is perfectly normal and healthy. If the organization and the team are able to find means of dealing with this early crisis, then the project will continue and build larger and larger successes. On the other hand, if the organization or the team try to ignore or hide the problems, then very quickly work will revert to the old way: bureaucracy or chaos.
Norming
After about four to eight iterations, the team will reach a fairly comfortable place: the basic agile processes and practices are understood, the organization and the team have removed some basic obstacles to getting work done (and consciously left some obstacles in place in all likelihood), and everyone on the team has a basic level of comfort with their role. The challenge at this stage is to avoid falling into the trap of complacency. Although comfortable, this level of performance is probably not all that much better than the old way. There will be real advantages: regular delivery of work, good communication between stakeholders and the team. But there will be many obstacles still to be removed, and the team has a long way to go in its development. If the team becomes complacent, then it is critical that a catalyst be introduced to incite the team to further development. Often, this can be as simple as a systematic and intensive program of capability building. As team members learn and practice new skills: process skills, technical skills, people skills, strategic skills, business skills... and as they become more and more aware of each other's capabilities, they will also become more and more aware of areas for improvement. Incentives need to be provided to help team members focus dilligently on self-improvement and team improvement. The iteration retrospectives become critical to help with this process... the tricky bit is that this is the stage when people start to think the retrospectives are no longer necessary!
Performing
The transition into the Performing stage for an agile team is gradual and happens over a fairly extended period of time. The definition of "getting to done" will gradually expand to allow the team to go from zero to full delivery of the end results every single iteration. There will be a temptation to split up the team and use these experienced team members to seed new agile teams - resist this temptation! Breaking up the team at this point destroys the value of time and effort invested in the team. It is much more effective to start a new team from scratch. The essence of a performing agile team is not the transferrable knowledge about agile processes and practices. Rather, the most important result of the team-building process combined with the agile process is the team itself.
Posted by Mishkin Berteig at 11:57 PM | |
April 20, 2006
An Introduction to General Systems Thinking
I recently completed reading An Introduction to General Systems Thinking
The Subject
This book is about science, philosophy, behavior, organizations, organisms, problems, solutions, faith, reason, and everything in between. Specifically, it is about a general approach to dealing with systems given the limitations of our human abilities.
The Ideas
One of the strongest ideas in the whole book is that there is a class of systems for which we have only very poor tools to understand them. These systems, which he calls "organized complexity" are contrasted to "organized simplicity (machines)" and "unorganized complexity (aggregates)". Machines can be dealt with purely analytically and in a deterministic manner. Aggregates can be dealt with statistically. Systems that are in the organized complexity category are too complex for a purely analytical approach but too simple for a reasonable statistical analysis. The book is focused on methods for dealing with this class of systems.
The Writing
Mr. Weinberg's writing is, first and foremost, engaging. He writes in an informal voice that is a wonderful complement to the subject matter. Even with the informal tone, he is nevertheless able to communicate some tricky ideas with a great deal of precision and clarity. His use of examples, diagrams, stories and quotes throughout the book is excellent. Although I did not do the exercises he includes, upon reading them, I was satisfied to see that they are all interesting. Since I intend to re-read the book in six months or so, I will also publicly commit to doing a good chunck of the exercises too. Maybe you'll see some of my efforts here since many of them are apropos to Agile Work.
How Does This Apply to Agile Work?
Much of the emphasis in agile methods is on the intractability of building a perfect plan for a set of work (particularly in software projects). The group of human beings that are building something is in itself a system of "organized complexity". As a result, it is impossible to treat that group of people as a system that can be made to work in a deterministic manner. We simply can't account for all the variables. At the same time, we would like to have a lot more certainty about the behavior of the group than we could just using statistical methods. (Check out Systematic HR for some related articles.) Agile methods help us find this middle way that gives us a very good shot at reaching our goals, but acknowledges our inability to determine precisely how we'll get there. A good understanding of Systems Thinking helps us comprehend the necessity and applicability of agile methods.
The Table of Contents
The chapter and section titles of this book tell a great deal about the scope of the work. I have reproduced the table of contents here for your reference.
Chapter 1 The Problem
- The complexity of the World
- Mechanism and Mechanics
- The Square Law of Computation
- The Simplificiation of Science and the Science of Simplification
- Statistical Mechanics and the Law of Large Numbers
- The Law of Medium Numbers
Chapter 2 The Approach
- Organism, Analogy, and Vitalism
- The Scientist and His Categories
- The Main Article of General Systems Faith
- The Nature of General Systems Laws
- Varieties of Systems Thinking
Chapter 3 System and Illusion
- A System Is a Way of Looking at the World
- Absolute and Relative Thinking
- A System is a Set
- Observers and Observations
- The Principle of Indifference
Chapter 4 Interpreting Observations
- States
- The Eye-Brain Law
- The Generalized Thermodynamic Law
- Functional Notation and Reductionist Thought
- Incompleteness and Overcompleteness
- The Generalized Law of Complementarity
Chapter 5 Breaking Down Observations
- The Metaphors of Science
- Boundaries and Things
- Qualities and the Principle of Invariance
- Partitions
- The Strong Connection Law
Chapter 6 Describing Behavior
- Simulation - The White Box
- State Spaces
- Time as a Standard of Behavior
- Behavior in Open Systems
- The Principle of Indeterminability
Chapter 7 Some Systems Questions
- The Systems Triumvirate
- Stability
- Survival
- Identity
- Regulation and Adaptation
- The Used Car Law
Also, check it out, Mr. Weinberg has started a blog on writing fiction. He also helps run the AYE Conference (amplifying your effectiveness).
Posted by Mishkin Berteig at 05:18 PM | |
April 12, 2006
Follow the Principles and Adjust the Practices
In "Built to Last : Successful Habits of Visionary Companies
Follow the Principles
What exactly are the principles? The foundation starts with Trust and Truthfulness. "Truthfulness is the foundation of all human virtues." Everything we do with agile should be about truthfulness (visibility, transparency) and building trust.
With this as a strong foundation, we can look at the Agile Axioms:
We are Creators
Reality is Perceived
Change is Natural
All of the other principles and practices associated with Agile Work flow from these basic assumptions about the world. We can't prove that the above three axioms are "true". But they either resonate with us or they don't. If they do, then it will be easy to use these axioms as a checkpoint for all the activities we engage in using Agile Work, wherever we apply it.
We are creators... therefore we derive our sense of value from our ability to create. If our creations are accepted by others, our team, our stakeholders or our community, all the better. But fundamentally, this is inherent to us as human beings. However, sometimes this natural drive is suppressed or repressed. In order to activate it, we need to work in empowered teams.
Have you ever experienced inspiration or "flow" or joy when working with someone else? Perhaps you were solving a problem. Perhaps you were playing a musical instrument - jamming - and got into a fertile groove. Perhaps you were teaching your children and created the light of understanding in them. Perhaps you built a beautiful set of bookshelves for your home. Or maybe you told a joke that created a brief moment of genuine levity in a group of friends. We are all constantly creating!
This basic principle then means that Agile Work methods and practices should not be imposed. Taught to us, perhaps... given to us as a template, perhaps... but once we understand the practices and are familiar with them, we should immediately be given the freedom to use the learning cycle to be creative with the process and practices of Agile Work itself. If we do not participate in creation, we become dis-empowered and that eventually leads to resentment or apathy.
Reality is perceived... therefore we need to work hard to build a common perception of reality if we are to work together effectively. We need to amplify our learning. We can't assume that our own understanding of a situation is going to be shared by others. At the very least we need to check: "do you see this?"
Let's recognize that in some way or another we are all blind:
Again, the learning cycle comes into play. The guidance, detachment, love, courage and search we go through all help us to build a common understanding of reality. This allows us to see new ways to apply the Agile Work principles and practices that make sense not only to our context, but also to everyone else participating in the work.
Change is natural... therefore instead of fighting change, we need to anticipate it, adjust to it, embrace it, and be gracious or even enthusiastic. Not only does change happen to us, but we also instigate change. If things get to boring, whatever the circumstance, we find ways to change things. We rebel at stasis and ennui.
Each practice and procedure done in the context of Agile Work must be explicity and implicitly accomodating of change. If a procedure can't tolerate change it will either lead to a dissonance or conflict... or if we are embracing change, then we will modify or discard the procedure. Our creative nature loves to create, but if we become too attached, too "in love" with our creations, we will support them past their point of relevance.
Our latest greatest idea will be good for a while. But eventually change will make it irrelevent.
So we see that all three Agile Axioms are also interrelated.
Our creations will be washed away through change and if we are lucky or wise we will perceive the change in reality - be truthful to ourselves and others - and allow a new creation to take the place of the old one.
When we perceive a certain truth, and try to share that with others, we will be asking those others to change their own perceptions. This change can be difficult and may even require the destruction of a mental model created with love and care over a lifetime. Sensitivity to this loss and encouragement to build a new creation will help build a shared perception... as long as we too are open to new perceptions!
Adjust the Practices
And of course, all this foundation of creation, perception and change must be connected to the practical day-to-day reality of our lives. Our family lives, our work lives, our social lives, our volunteer lives, our intellectual lives, our emotional lives, our spiritual lives... our whole lives.
The Agile Work practices are simple to state:
Manage Ourselves
Deliver Frequently
Adapt our Plans
Communicate Powerfully
Test Everything
Measure Value
Remove Obstacles
These practices provide a starting point. A basic set of activities that will assist you, your team or your organization to advance quickly towards whatever goal you have set for yourselves. The way these practices succeed is by making sure that the Agile Axioms are always remembered and their implications accepted. These practices will set up a virtuous circle by building trust and allowing truthfulness. More trust and truthfulness will allow a fuller and more nuanced expression of the practices...
But if these practices become canonized, if they become a rote process imposed and followed blindly, then it means that we have lost sight of the Axioms. We have forgotten to check our practices against the context of creation, perception and change.
The reason we follow these practices is because we believe that we are all creators, that we can learn from our diverse perception of reality and that change is a force of growth. We don't believe these Axioms because we blindly perform these practices.
This is all available as a nicely formatted pdf: Agile Axioms - a Brief Exposition.
Posted by Mishkin Berteig at 01:45 AM | |
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 20, 2006
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 14, 2006
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 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. Fo