December 05, 2007
Retrospective Exercise
This sounds cool: The Three Word Starter Retrospective Safety Exercise.
Posted by Mishkin Berteig at 05:06 AM | |
November 29, 2007
Team Size and Productivity
Here is a great article on InfoQ about team size and productivity. The basic idea is that a small team, supported by excellent tools and techniques will always do better than a large team. One aspect of this that isn't mentioned in the article, but which figures prominently in "The Mythical Man-Month" is the idea of communication overhead. It is impossible to house a large team in a team room and therefore communication cycle times, effectiveness and frequency also become a substantial factor.
Posted by Mishkin Berteig at 12:26 AM | |
November 16, 2007
Scrum for Meetings
This is a nice little encapsulation of the Scrum process and the daily Scrum meeting: http://www.effectivemeetings.com/teams/teamwork/scrum.asp. It is described in completely non-technical language and the example used is that of a marketing team. Basically, what is described is the Agile Skeleton plus the daily status meeting without any of the other project management aspects of Scrum.
Posted by Mishkin Berteig at 07:09 AM | |
November 13, 2007
Trust - Presentation by Diana Larsen
This is a great presentation on the importance of trust: http://www.agile2007.org/agile2007/downloads/presentations/Larsen_613_613.pdf. I love this sort of thing since it is, to me, so important to building effective teams. I often prefer to talk about truthfulness since that is the attribute or capacity that people need to develop, but the result of truthfulness is trust, so in many ways they are one and the same.
Posted by Mishkin Berteig at 11:33 PM | |
November 10, 2007
Agile Project Management Blog - Sanjiv Augustine
Sanjiv Augustine, agile coach and consultant at LitheSpeed, has a great blog: LitheBlog. Focus on agile project management topics. Good writing and good reading!
Posted by Mishkin Berteig at 10:07 AM | |
November 09, 2007
Agile Contracts
One of the Certified Scrum Trainers, Chris Sterling from SolutionsIQ, recently posted a good set of links on Agile Contracts. Hopefully these links will help you understand how to "sell", set up and execute on agile contracts. Here are the links:
Chris wrote:
Mary and Tom Poppendieck have great presentations and a workshop on this topic. Here is a URL to a Powerpoint presentation from them:http://www.poppendieck.com/pdfs/AgileContracts.pdf
Also, here is some data from a workshop:
http://www.poppendieck.com/agilecontracts.htm
And Alistair Cockburn has a great page on Agile Contracts here:
http://alistair.cockburn.us/index.php/Agile_contracts
Martin Fowler has a page on “Scope Limbering” here:
http://martinfowler.com/bliki/ScopeLimbering.html
Hope these help.
Thanks Chris! Here are a couple more links:
Leading Answers - Agile Contracts - blog entry with some good references.
Contracting Agile Projects - by the Cutter Consortium
I'm not an expert on agile contracts myself. I would be interested in hearing from people if they have any stories about actually using (or failing to use) contracts in an agile environment.
Posted by Mishkin Berteig at 07:17 AM | |
October 29, 2007
Agile Groups on FaceBook
FaceBook is an extremely popular social networking site. It is also becoming an effective community collaboration site. The agile community is gradually starting to see the value of this environment. Here are four groups related to agile practices:
Agile and Lean Development Community (589 members)
Agile Project Management (218 members)
Extreme Programming (16 members)
Scrum (7 members)
Posted by Mishkin Berteig at 01:26 PM | |
October 14, 2007
Agile Learning and Education: The Agile Professor
Well, it's officially launched: The Agile Professor - Creating an Agile Learning Environment for Classrooms and Schools. This blog, authored primarily by my father, Garry Berteig, is an exploration of the use of agile methods to organize learning environments such as schools, classrooms, seminars, workshops, etc. The material in this blog will include Garry's experiences over the past two and a half years of experimenting with agile methods in an educational context as well as a record of his continuing exploration of this topic. I might chime in from time to time too :-)
Posted by Mishkin Berteig at 10:26 PM | |
October 12, 2007
Agile Classroom Management
I'm fascinated by the idea of applying agile methods outside of software... be it to business management, family and household, or, as I and my father have been exploring over the last two and a half years... agile classroom management. Here's how I do it in my Agile Project Management / ScrumMaster Certification courses:
My father, Garry Berteig, had been using agile methods in his classroom for over two years before I tried it myself. I had gone into one of his courses at Keyano College in Fort McMurray to give a presentation to his second-year media students on agile and Scrum. They used it for a video project (see "A Student Documentary Film Project" and "Scrum Saves the Day for Media Student". Out of that experience, and others, he developed the idea of the Learning Circle as the basic cycle in an agile learning environment.
In the meantime, I became a Certified Scrum Trainer. Back when I did it, this just meant co-teaching a Scrum class with Ken Schwaber. He had a standard slide deck which he presented as he masterfully guided a class through two days of Scrum training. I (as expected) took that deck and made it my own by reformatting, rewording, changing a few of the exercises, and changing the emphasis in a couple of spots. And then I used that deck with minor corrections and updates and some expansion over the course of the next 16 months.
In the meantime, I was also doing a fair amount of training for teams and organizations that didn't care particularly for Scrum, but just wanted to know more about this "agile" thing. Sometimes it would be a one-day course, sometimes as much as five days (that was exhausting!!!). I developed a substantial body of modules including exercises, case studies, and special topics. Eventually, I found that I was having a hard time fitting my fixed agenda materials into the time I had allocated. For example, I was commonly doing a three-day course and would find that by the end of the first day I was a little behind on my agenda and by the middle of the third day I would certainly be running out of time and miss possibly even two or three modules in the agenda.
Finally, last Sprint, I got a big client who asked for training for a large number of their staff. This gave me the opportunity to: a) work with the same materials and agenda at least three times, and b) involve an assistant in all three deliveries. The first time through, I had the typical problem where the third day was a terrible rush. The second time through, it happened again, but I had de-scoped and re-arranged some of the material so it didn't seem as bad. After that second time, my assistant, an excellent coach, David Chilcott, suggested that I try to apply a more flexible... agile... approach to handling the materials. We did a quick revision of the materials to support this idea and then the third class was run as an "agile training environment". What did this mean?
The main insight was that the time allocated to the class was timeboxed. This meant finding a way to prioritize the work of the class so that the majority of the participants would get the best value possible for their time in the class. We did this in two ways:
1) As questions came up, we found that some of them needed to be deferred because they would be answered in a later module or because there was background material that needed to be covered first. So, for every question that needed to be deferred, we wrote it up on a 3x5 note card and put it up on the wall. Now, in order to keep track of this, we also had all the course modules written up on 3x5 note cards and up on the wall too. Most of the question cards would immediately be put up with the associated module card.
2) We drastically cut back the core required modules for the three days and made everything else optional. We then decided on a simple in-class mechanism to choose from those optional modules. At the end of the first day, we had time for one optional module so the class voted and we chose the module based on that vote. Likewise at the end of the second day. By the third day, we had a substantial portion of the day un-allocated. As soon as we finished with the required materials, we got the class to choose the next module to cover. As soon as that module was covered, the class chose again from all those still remaining.
It was a bit of a mess and our mechanisms didn't work perfectly, but it got the job done. At the start of our second day, the cards we were using to track modules and questions looked like this:
After we finished the course, we did an in-depth reflection and decided on some changes to be made. One of the most important was actually very simple: make the module cards much larger so that it was possible to put many question cards right on the module card. Here is what this looked like in a recent class:
The left is the module card at the start of the course with questions that were generated by the course attendees when asked what they wanted to learn from the course. The right is the same module at the end of the course. You can see that one additional question card was added between the start of the course and the time when the module was actually covered. You can also see that I use big check marks to show to the class that the module is complete.
Another change to the method of doing this agile classroom management came in the further refinement of the module content and sizing to be more appropriate for doing the modules in unpredictable sequence. This included things like checking definitions, improving some of the introductory material (to make sure all the concepts were introduced, not just some of them), finding references to other modules and removing them, and in some cases moving material from one module to another. There are still improvements to be made in this area.
Thirdly, we now are better at explaining to the class how this will all work at the start. We are modeling an agile process in the way we run the course. This means that the attendees will have an opportunity to influence what material is covered and in what depth. It also means that if the class takes a lot of time with questions early on with the basic material, it leaves less time at the end for optional modules. The people in the class can now visibly see these tradeoffs.
Here are two photos from a recent class. The first was taken at the end of the first day (note that I forgot to use the check marks on these cards). The second was taken at the end of the third day. You can clearly see how the modules of the third day were chosen entirely by the participants from the available optional modules.
This mechanism of managing a classroom using an agile approach has had some very interesting results:
1) Every class is substantially different. Before, the differences were always in the details: timing, specific questions, etc. Now, the actual material covered is uncertain. I always make adjustments to the course materials after every course. Now, not only are those differences in play, but also the actual modules covered might be different. The fascinating thing is that now, by the time we get to the last module, most of the people in the class are giving off a palpable sense of satisfaction: their urgent questions have been answered. Sometimes, this is so strong that I do the graduation "ceremonies" right before covering the last module so that people not interested in that last module can leave a little early.
2) I get far fewer comments in my feedback forms that indicate a desire that the course was longer. Before I started using this agile learning environment, I would get a substantial number of comments to the effect that it was really too bad there was not another day. Now I rarely get those comments.
3) The attendees in the class see how an agile approach actually works in a real life situation. They see that allowing the requirements to change over time is actually a good thing. Every single time I do this, there is a pattern that shows up on the third day that relates to the way the class prioritizes the next module. I count up the votes and choose the next module to cover. All the other modules have their scores written on them as well. After a module is covered, instead of using those old scores, the class takes another vote. Every single class, the priority changes between votes. This clearly demonstrates the power of allowing stakeholders to change their minds after seeing real results.
4) Participants in the course are engaged at a deeper level. There are lots of "tricks" for keeping people engaged: discussions, exercises, simulations, questions, presentation eye candy, etc. All of those things have their place and are important. However, by having participants steer the course itself, the level of engagement suddenly becomes much more substantial. The participants are responsible for the results of the class in a way that is quite unusual in most educational environments. This responsibility is granted to them and they take it seriously. I rarely see anyone refuse to participate in this process, and I never see anyone attempt to subvert it.
If you are interested in learning this mechanism of classroom management, I strongly recommend:
1) Learn up on agile. The openagile.org web site is starting to define an agile method that is abstracted away from the software legacy that agile methods currently are shackled with. This site is still in its infancy so treat it gently :-)
2) Come try one of my courses! (Yes, that's a blatant shameless plug!) You will get to experience and learn the agile method in a focused setting. The courses are IT/software focused in some respects, but since they are non-technical courses, and really about agile project management and human interactions, almost anyone can attend (I've had dancers, administrative assistants, educators, artists, community workers, executives, and actors all attend).
3) Get in touch with me to find out more of the details that didn't make it into this blog entry. The best way to do this is (really) through my business web site: berteigconsulting.com where you can find both email and phone contact information.
Well, I finally got around to writing this up. This is part of a series of related articles "tagged" as USEFUL started by Scott who writes at Tyner Blain. His article, which started the game of tag, is called Software Product Success Stories. Scott... I'm sorry this article isn't about software!!!
I would like to now tag a few people who write useful blogs:
Mike Vizdos who writes the Implementing Scrum blog. This blog is best known for the fabulous cartoons of the Chicken and the Pig, but also has a lot of great and practical insight on the challenges of, you guessed it, implementing Scrum!
Tobias Mayer who writes at Agile Thinking. He doesn't write often, but his articles are always fantastic! I hope that Tobias will take the time to write something in this "useful" stream and pass along the tag.
Mark Levison writes Notes From a Tool User and discusses many things, not just agile. His writing is fun and he's in the trenches doing real serious work getting his company to use agile. He's got good insight.
Posted by Mishkin Berteig at 03:46 AM | |
September 27, 2007
Other Resources on the Benefits of Agile
Having just finished a substantial series of articles on the Benefits of Agile, I thought it might be good to let you all know about some other ideas about these benefits. I don't agree with everyone who has written on this topic, but of course, you can judge for yourself!
Benefits of Agile as portrayed by VersionOne
Benefits of Agile as portrayed by Exoftware
Agile: Turning on a Dime - blog post by Damon Pool
Business Benefits of Agile Development - blog post
Agile and Transformational Leadership - blog post which mentions four benefits briefly
The Value of Agile - long presentation about many levels of agile benefits
Posted by Mishkin Berteig at 04:17 AM | |
September 21, 2007
Team Room Photos
Bill Wake has a great collection of photos of team rooms for agile teams.
Posted by Mishkin Berteig at 05:32 AM | |
September 14, 2007
Aides for Complexity - Understanding the Applicability of Agile Methods
In the ScrumMaster training, I include a diagram that has a simple idea: to map the areas of complexity in a problem based on two dimensions: Agreement and Certainty. This diagram is an adaptation of the diagram by Ralph Stacey found in this article called Aides for Complexity by Brenda Zimmerman. This diagram or model can be used to help us understand where and how agile methods can be applied.
In the simplest way possible, if we have both Agreement and Certainty on a problem, then an agile approach is probably applicable, but not necessary. As we move away from that bottom left quadrant of the model, the usefulness of an agile approach increases since agile methods promote learning, careful search, feedback mechanisms, multi-disciplinary work, etc. The top right quadrant, "Chaos" is, like the bottom left, a case of possibly useful, but not a guarantee of any success. So agile methods seem most suited for a broad sweep of the diagram starting from the upper left and going down to the bottom right. Like so:
Posted by Mishkin Berteig at 01:11 PM | |
September 12, 2007
Teams FAQ - Good Reference for Agile Process Facilitators
Christopher Avery, who has written a book about teams called "Teamwork is an Individual Skill", has a good reference page on his web site about teams. From his FAQ, here is his definition of "team":
A team is a group of people whose personal outcomes are obviously linked to a collective outcome -- such as a successful project -- and who work together to maximize collective and individual outcomes. "Team" also refers to the quality of group relationships that allows ordinary individuals to achieve extraordinary results together -- such as a project that surpasses its goals.
Posted by Mishkin Berteig at 05:39 AM | |
August 30, 2007
Agile Retrospectives and the Plan of Action
Bas Vodde has published a good article about making goal oriented action plans for agile projects. It is a nice piece of the puzzle on how to do effective retrospectives. It also nicely ties into the "Learning Circle" Reflection/Learning/Planning/Action steps.
Posted by Mishkin Berteig at 04:59 PM | |
August 18, 2007
Agile Management Tools
Ah, tools...
For agile training and consulting, I always recommend starting with the standard physical tools of note cards on a wall plus a whiteboard and digital camera. However, I am still interested in what tools people have used when they have found that note cards are not sufficient. Here is a list of the tools that I am aware of, as well as a link to a survey...
This list is in alphabetical order:
Custom In-House Tool
Defect/Enhancement Tracker (e.g. Jira)
Spreadsheet
Wiki (e.g. Fitnesse)
The survey is extremely short (four questions) and will be closed on Sept. 15th:
Click Here to take the Agile Management Tools survey
I will publish the results here.
If you know of other tools (open source, products, etc.) please let me know in the comments!
Here are more tools for managing agile projects/requirements/planning that have been mentioned by folks in the comments:
Thanks to everyone for including the urls in the comments!!!
Posted by Mishkin Berteig at 02:36 AM | |
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 | |
May 20, 2007
Talking Chair Technique
This is cool... my friend and co-worker Deborah Hartmann pointed me to this Talking Chair technique for organizing discussions in an Open Space environment.
Posted by Mishkin Berteig at 11:52 PM | |
April 25, 2007
The Ladder of Inference Model
Last night I had a great conversation with a friend and co-worker, David Chilcott. He told me about the Ladder of Inference. This model is a way of taking the Agile Axiom that Reality is Perceived and building a model around that axiom. Here is another good link about the Ladder of Inference that provides some insight as to how to use it as a tool in communication.
Posted by Mishkin Berteig at 12:14 PM | |
April 22, 2007
InfoQ Article in Chinese
Quite some time ago, I wrote an article for InfoQ called "What is Agility and Why Should You Care?" That article has been translated into Chinese:
"What is Agility and Why Should You Care? (Chinese)"
Posted by Mishkin Berteig at 10:45 PM | |
April 20, 2007
Lawrence Miller
Back in the early 90s, my father let me watch a series of training videos by Lawrence Miller. At the time, I was in my late teens. I was very excited by the discussion regarding management, helping customers etc. I see now that he is also dealing with organizations, lean and topics of interest to me now! I haven't read any of his books, but I'm pretty sure that they would all be very interesting.
Posted by Mishkin Berteig at 12:01 AM | |
March 27, 2007
Resistance and Perception
From George Dinwiddie (interesting blog, BTW) on the ScrumDevelopment list comes this great article: Resistance as a Resource by Dale H. Emery.
From the article:
You gather your courage, call people together, and make your proposal. From your right, Charlie says, "But we tried that before, and it didn't work." To your left, Pam says, "But we've never done that before." Right in front of you, Lee says, "But that's no different form what we're doing now." From the back of the room, you hear a rising chorus of, "But we don't have time!"You don't really have to imagine this scene, do you? You've lived it. Perhaps you're living it right now. You're getting resistance. Now what do you do?
Posted by Mishkin Berteig at 03:56 AM | |
March 25, 2007
Factual Errors - And an Interesting Scrum Criticism
An interesting article called Credibility Crisis is worth while reading. I would like to point out two factual errors. Despite the errors, the author's concerns are well-taken. Here are the errors:
1) The average price per CSM is much less than US$1500. Your "conservative estimate" is not conservative at all. For quite some time, the average was less than $1000 in fact. As a scrum trainer, I know that the people that I have certified have averaged about US$750. I suspect this is true for most of the trainers, and it accounts for volume discounts when doing training in a corporate setting, doing pro-bono training, doing training in countries with lower costs and training that is done by CSTs that are employees of large companies such as Microsoft and British Telecom where the "industry" sees no revenue.
2) "Well planned marketing" Ha!!! That's a good one! There has been exactly one advertisement issued by the ScrumAlliance (in Dr. Dobbs Journal), and all other advertising and promotion is done hodge-podge by the individual CSTs or the companies they work for. The only coordination point is the web site where all the CSTs are required to list their public courses. Ken Schwaber and Mike Cohn, as the most well-read authors in the Scrum community get a large bulk of the _interest_ in the training (I'm not sure what their actual numbers are for # of CSMs).
Those two errors undermine the author's argument in the article, but don't completely invalidate it.
Posted by Mishkin Berteig at 05:52 PM | |
March 22, 2007
Agile Job Web Site
It's new! It's exciting! It's the new Agile Job Finder web site! Search for agile jobs, register and post your jobs! Fun for everyone!
Posted by Mishkin Berteig at 11:00 PM | |
March 10, 2007
Pay and Performance
Jeffrey Pfeffer Testifies to Congress About Evidence-Based Practices. Here's a good couple excerpts (thanks Esther!):
"The idea that financial incentives are the way to solve organizational
performance and service problems is one of the most dangerous "half-truths"
of management. The evidence for widespread dissatisfaction with such pay
plans is pervasive. Both employee and company survey data suggest that the
likelihood of success is low and the odds of problems and dissatisfaction
are high.""Although the list of high commitment or high performance work practices
differs slightly among authors and studies, most such lists include: a)
sustained investment in training and development, including job rotation,
both formal and on-the-job training, and a tendency to promote from within
as a consequence of the successful internal development of skill and people;
b) an egalitarian culture in which formal status distinctions are
downplayed, salary differences across levels are less than in the general
economy, and in which people feel as if their contributions are important
and valued; c) delegation of decision making responsibility so that skilled
and developed people can actually use their gifts and skills to make real
decisions; d) high pay to reduce turnover and attract the best people,
coupled with rewards that share organizational success with its members; and
e) employment security and a policy of mutual commitment, so that the
workforce does not fear for the outcomes of events over which it has no
control and instead, feels reciprocally committed to the employer."
Posted by Mishkin Berteig at 12:04 PM | |
March 06, 2007
Agile Blog Started
A new blog has been started called "Agile & Business" by agile coach Joe Little. I have worked with Joe and I believe that he has excellent insight into human nature and the application of agile methods. The first few articles he has written are an excellent starting point including a look at metaphors we use in Scrum (chickens, pigs and dogs), and a look at the idea of business value.
Posted by Mishkin Berteig at 10:25 PM | |
February 22, 2007
Strategic Plan
Okay, this is only marginally related to agile, but I thought it was interesting nevertheless: How to Write a Detailed Strategic Plan. The main connection to Agile Work, is that you need to have a clear performance goal in mind towards which you are working. This may be a great way to clarify your thoughts about such a goal.
Posted by Mishkin Berteig at 11:43 AM | |
February 21, 2007
When is Scrum not Scrum?
Tobias Mayer has written a fascinating and valuable article about what it means to be doing Scrum. There are some very practical ideas (e.g. shortening Sprint or iteration length) and some more philosophical ones (e.g. the ScrumMaster role is not always necessary!) It's a great read, and I agree with everything there, except for one point...
Tobias mentions that one must insist on agile engineering practices when doing Scrum. There are two problems with this.
First, not all development environments have the tools to support the agile engineering practices. For example, one team I coached was using AbInitio; there is no ABUnit test-driven development framework. As another example, a team was doing a software upgrade project where again, there was no easy way to write automated tests (there was a hard way), nor was there any way to do continuous integration short of totally re-architecting the system. Nevertheless, doing a version of Scrum helped immensely.
Second, these engineering practices are even harder to do when the work in question is not related to software. For example, I use agile methods to run my business. I don't pair program, I don't do test-driven marketing (at least not in a way that is clearly comparable to test-driven development). These things just don't apply.
Now granted, Scrum is a software development methodology at its heart. The concept of the Product Owner, the Demo at the end of the Sprint, and a number of other things tie the language of Scrum to software product development. Any time it is taken out of that context, there is a stretch.
Also, please don't mistake this disagreement with a feeling that quality is something that can be relaxed. I have very strong feelings about technical debt and quality.
Posted by Mishkin Berteig at 09:21 PM | |
February 15, 2007
Transplanting the Toyota Way
Thanks to Mark on the scrumdevelopment Yahoo! group for pointing out this great little article: The Toyota Way is Translated for a New Generation of Foreign Managers. The main thrust of the article is the difficulty that Toyota has had in getting managers outside of Japan to accept some of the core principles and practices of the Toyota Way. One interesting example:
Worse, some executives like Mr. Konishi complain of managers at Toyota factories who have not adhered to some of the company’s most basic creeds, like allowing workers to stop factory lines when they spot defects. Empowering factory workers has long been central to Toyota’s quality control.
Posted by Mishkin Berteig at 10:40 PM | |
February 12, 2007
Agile Retrospectives Google Tech Talk
This is good: agile retrospectives.
Posted by Mishkin Berteig at 06:21 PM | |
January 24, 2007
Leadership for the Agile Organization
I found an interesting blog post on cio.com called Leadership for the Agile Organization. This is a neat little piece that covers some of the essential aspects of leadership for empowering teams... but I believe that there are some critical bits missing, and if leaders _only_ did what was in the article, they would have a chaotic mess on their hands. I've added a comment to the article so you can read more about my thoughts there :-)
Posted by Mishkin Berteig at 12:55 PM | |
January 23, 2007
The Agile Zealot's Handbook
This is great! I often call myself an Agile Zealot to my clients. (Usually, they smile... and if they don't I tend to have a short relationship with them!) So here it is, the Agile Zealot's Handbook.
And, since I've got a dead horse lying around waiting to be beaten up some more, I've re-written it (the Agile Zealot's Handbook, not the dead horse) to be non-software oriented. Presenting... the new and improved... non-software oriented... readable by anyone... Agile Zealot's Creed:
VALUE
IF you don't repeatedly deliver results
that produce actual value
for a real customer
into your real world environment
frequently enough to respond to change...
TECHNIQUE
IF you're not paying constant attention to technical excellence
with simple, effective tools, processes and reuse
driven by uncompromising dedication to quality
and the discipline to test everything...
LEARN
IF you're not deliberately going
through stages of planning, acting
reflecting and learning
as frequently as you are delivering results
over and over and over...
TEAM
IF your team is not empowered to self-organise,
does not sit together and engage in face-to-face communication,
does not include your customer
and all the necessary skills to make its own decisions and take immediate action...
THEN YOU HAVE COMPROMISED YOUR AGILITY
(and good luck to you... you'll need it!)
Posted by Mishkin Berteig at 08:41 PM | |
Foundations of Agile
What are the foundational documents (online or otherwise) that constitute the basics of what it means to be agile? There is one obvious one: the Agile Manifesto. If you know of others, please let me know in the comments!
Posted by Mishkin Berteig at 03:41 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 | |
January 15, 2007
Minor Update to Recommended Materials
I've added the Evolving Excellence blog to the Lean section of my recommended agile materials list. Again, if anyone has any suggestions for the list, please let me know in the comments here.
Posted by Mishkin Berteig at 06:07 PM | |
January 12, 2007
Comparison of Project Manager and ScrumMaster
This is an interesting, short comparison of the role of the Project Manager in a traditional project setting and the ScrumMaster as a facilitator. The comparison is very light on details and so it does not present a clear picture of the motivations and advantages for choosing one scenario or the other. Rather, it compares only the surface features of the two systems.
Posted by Mishkin Berteig at 11:18 PM | |
January 05, 2007
Scrum Experience Report
This is a great "how we did it" experience report about Scrum in a software environment (pdf).
Posted by Mishkin Berteig at 09:40 PM | |
January 04, 2007
Coaching and Agile Work
Someone recently said to me that I should offer individual coaching assistance to people based on Agile Work. This would be completely non-technical life/profession style coaching. It's an interesting idea. I don't think I'm quite ready for it, but here are a few links to coaching, life improvement, and related things.
We'll start with the Wikipedia entry on Coaching. This article provides some good definitions and links to a number of articles about specific types of coaching.
Esther Derby is a person I have met a couple of times through the agile community. She has a wonderful approach to training and facilitation. This article about coaching is a simple introduction to the tools of a coach.
This is a brand new blog about lifestyles. There are only two entries so far, but both are interesting. I enjoy the style of writing which is quite personable. The author seems to be positioning the blog as a lifestyle coaching resource.
And the International Coach Federation which seems to be one of the most well-known bodies that promotes coaching as a profession.
Posted by Mishkin Berteig at 09:44 PM | |
January 02, 2007
Top Ten Most Popular Entries from 2006
If you are new to Agile Advice, these are not just some of the most popular articles, they are also some of the best! Take a look around; you will find ideas to inspire you, challenge your thinking and maybe that one little thing that will make the difference in applying agile methods in your situation.
1. How Two Hours Can Waste Two Weeks - 25,617 unique views
This little hypothetical story by Dmitri Zimine was very popular on Reddit, and Joel on Software ranted a bit about it.
2. The Case for Context Switching - 2,936 unique views
My rebuttal to Joel's rant. Goes well with Dmitri's article. Emphasizes the idea of building trust in an organization.
3. The Qualities of an Ideal Test - 1,579 unique views
Six qualities that will help make your tests as valuable as can be. Similar to the ACID properties of databases or the INVEST properties of user stories.
4. The Pros and Cons of Short Iterations - 1,555 unique views
A few words that will help you decide how long to make your iteration length. This is an important decision, and most teams and organizations don't know the factors involved.
5. Five Signs of Trouble in an Iteration - 1,489 unique views
A good howto on using burndown charts to discover problems in an iteration.
6. Seventeen Tips for Iteration Planning - 1,427 unique views
A good list of hints and tips that can make the difference between struggling with iteration planning and having it go smoothly and effectively. This is a key part of the Agile Work process, so getting good at it is a high priority for any team new to Agile Work.
7. Change is Natural - "Embrace Change" - 1,397 unique views
A short riff on the universality of change. Also introduces the idea of the "horizon of predictability".
8. The Art of Obstacle Removal - 1,287 unique views
This is a good reference article on types of obstacles and methods for removing them... a critical practice for Process Facilitators.
9. The Seven Core Practices of Agile Work - 1,285 unique views
Agile Work is really quite simple. This is a concise list of the practices that make up this effective methodology.
10. Interview with Alistair Cockburn - Agile and House Renovations - 902 unique views
Applying agile methods to home and garden renovations! Learn a bit about how this luminary of the agile world has taken agile practices out of the software world and into the hardware world.
Posted by Mishkin Berteig at 06:32 PM | |
My First Iteration Planning
I've done my iteration planning for my first iteration called "Beginnings". The length of my iterations is one week (including weekends). Here is the list of backlog items that I have committed to (some detail removed):
Catch up on Scrum course follow-up work
Advertize future courses
Finish eBook 2nd Draft
- email request for feedback return
- go through feedback
- finish references
- finish diagrams
Invoice
Finalize India Trip
Interview
Meet up with
Continue development work for
I have broken all of these into tasks, but only put here the ones for finishing my eBook since the rest get into lots of private detail.
I'm currently using TiddlyWiki to track my Work Queue, my tasks and my recurring/scheduled duties. I create a new wikiword for each iteration and copy items from the Work Queue into that section. I also have a menu that has links to my daily, weekly and monthly tasks.
I'm not doing any estimation on either Work Queue items or tasks. This may become a problem, but for now I'm going to try doing the work without the estimation overhead.
I also spoke with my wife, Melanie who is my business partner about all this. She agrees that using Agile Work is a good step to take and looks forward to all the benefits of my being more organized :-)
Posted by Mishkin Berteig at 12:05 PM | |
December 22, 2006
Link: Agile Methods as a Replacement for Fossil Fuels
Agile Methods as a Replacement for Fossil Fuels - great post about old vs. new ways of managing knowledge workers.
Posted by Mishkin Berteig at 03:27 PM | |
Technical Debt
Last night I was thinking more about the analogy of technical debt. In this analogy, design and quality flaws in a team's work become a "debt" that must eventually be paid back. This analogy is fantastic because it can be taken just a little bit further to understand just how bad defects are...
Debt is sometimes useful. Financial debt can be used for risk reduction, investment, and emergencies. But it can also cause problems. Too much debt becomes hard to manage. If debt maintenance costs more than revenue (minus other expenses), then you're going down!
Technical debt is a little different than financial debt.
Suppose I went into a boardroom full of high-power executives for some large company. (Never mind how I got there.) And I pitched this fabulous idea: I'll give them a bunch of money for them to use for operations, expansion, whatever. All they have to agree to is that I choose the interest rate when I ask for repayment... trust me!
I would be thrown out of that room so fast!
That is what we do when we encourage teams to take on technical debt.
There is no way to know the interest rate on a defect. Part of the cost of a defect is obvious: how much time and materials will it take to repair the immediate problem. (Although even that is often hard to measure.) But there are also lots of non-obvious and probably non-measurable costs. How much effort will it take to get to the root cause of the defect so that it doesn't occur a second time? How much will it affect our "goodwill" and thus reduce further and repeat sales? How much will the existence of one defect hide the existence of other defects (with their own costs)? How much will the defect demoralize the team and increase staff turnover or reduce productivity? How much of an opportunity will the defect create for competitors? How much will the defect increase maintenance and support costs?
In other words, every time someone asks a team to let quality slide, they are asking the team (and the organization) to take on debt with an unknown interest rate. Which is lunacy.
Read more about this:
Voluntary Technical Debt - James Shore talks about a situation where a conscious decision to take on technical debt led to positive results.
Technical Debt: The Threshold of Acceptable Pain - Steve Bate talks about skill and sensitivity to technical debt. Here's a great quote from this article:
What if someone has a very high threshold of pain? I’d expect to see lots of crud (technical debt) in their code.... The high threshold developer doesn’t mind spending weeks on new features that would otherwise require days or hours with clean code. And they don’t mind staying at work all night fixing bugs before a major release or spending countless hours babysitting the production system after it’s been released. It doesn’t seem to bother them to spend significant time away from family and friends or to have limited time or other interests and hobbies. ...they sometimes experience pleasure at being the “hero” who saved the company from the bugs they created.
An Incremental Technique to Pay Off Testing Technical Debt - Johanna Rothman talks about technical debt and describes a simple risk-oriented approach to reducing it.
Posted by Mishkin Berteig at 08:23 AM | |
December 18, 2006
Goal Setting
Andrey V Khavryuchenko has written an interesting article on goal setting called Well Formed Outcome. Andrey describes the six criteria for setting an achievable goal. Interestingly, these are similar in some respects to the conditions necessary for testability.
Posted by Mishkin Berteig at 11:04 AM | |
November 29, 2006
Two Good links
A good description of using mini-projects within much larger projects to produce initial valuable results and learn from those results. There is a good case study of a 16 year World Bank project. Why Good Projects Fail Anyway. From the article:
The key is to inject into the overall plan a series of miniprojects—what we call rapid-results initiatives—each staffed with a team responsible for a version of the hoped-for overall result in miniature and each designed to deliver its result quickly.
An excellent article about the use of very short iterations to build a website. The Freedom of Fast Iterations: How Netflix Designs a Winning Web Site.
Don't forget: Agile Advice is offering a 10% discount on agile training courses in Toronto, Edmonton, Calgary, Ottawa, Vancouver and Halifax until Dec. 31st!
Posted by Mishkin Berteig at 12:00 PM | |
November 24, 2006
How to Avoid Context Switching
Given the huge interest in the article by Dmitri Zimine about context switching, and despite a couple of good articles about how to determine iteration length, there has been no empirical method described, only reasoning processes. This article describes a simple method to quickly determine iteration length by experimental means.
Step One
Start with an iteration length that feels right. Use the two articles below to try decide a reasonable length. In software development, this should be no longer that four weeks. In larger volunteer communities it might be as long as three months. In a work environment where you have to deliver daily, your iteration length might be two hours.
Step Two
Build your Work Queue, and plan your first iteration. Mark the tasks that come out of your iteration planning meeting so that you know that they are tasks that were planned. As you go through this first iteration, track all the interruptions you get by writing up a task for each interruption. Each interruption task should be marked so that you know it was an interruption. If you are using note cards on a visible task board, I like to have "normal" tasks on white cards and interruption tasks on fluorescent orange cards to help them stand out!
Step Three
At the end of your iteration, determine which interruption tasks could have been deferred. In other words, determine which were truly urgent and needed to be handled in the already short time of your iteration, and which could have been put on the Work Queue, prioritized, and therefore deferred to a later iteration. This will require collaborating with your Queue Master and possibly other stakeholders.
Step Four
Count how many non-deferrable interruption tasks your team had in the iteration. For this experimental method, you can assume that this is going to be your normal number of interruptions. Divide the length of your iteration by the number of non-deferrable interruptions. For example, if you had a ten day iteration, and two non-deferrable interruptions, you would have a result of five days. Also consider what was the maximum reasonable response time for these non-deferrable interruptions. The lower of these two values becomes your experimentally determined iteration length. But you are not quite done!
Step Five
Do it all again to verify your iteration length. Note that because of your shortened iteration length, you hopefully will have far fewer non-deferrable interruptions. After your second (shortened) iteration, you can adjust the iteration length shorter if necessary... but don't adjust longer (for now).
I've worked with enough teams to know that for a substantial portion of them, this method would result in very very short iterations. In the software world, a team is often asked to work on a project and support their previous project. This support work tends to mean dealing with various bugs in deployed software. This is one reason why I have become such a strong advocate that quality is not negotiable.
I worked with one team that did something similar to this method (although not as rigorously) and we decided that we needed to try an iteration length of two days. This was painful for the team, but they badly wanted to build trust with their stakeholders. Their interruptions were causing them to constantly fail on their commitments. By switching to these two day iterations, they were able to defer the bulk of their interruptions and meet the commitment they made as a team in the iteration planning meeting.
Articles about iteration length:
Mike Cohn's article: "Selecting the Right Iteration Length for Your Software Development Process"
Mishkin Berteig's article: "The Pros and Cons of Short Iterations"
Now that you have gotten to the end of the article, I can admit something to you: this article is badly named. It should be named "How to determine how often to context switch so that you can meet your commitments and build trust with your stakeholders."
What this article doesn't help with is the pain of context switching. The teams that I have see that use short iteration lengths all find ways of making context switching less painful. Automation, good tool choices, workspace arrangements, etc. all play a part in this. But there is no secret ingredient to make context switching painless. Sorry!
Posted by Mishkin Berteig at 07:55 AM | |
November 16, 2006
Trust vs. Camaraderie
Ryan Cooper has written an excellent article called Trust vs. Camaraderie where he points out that many "teams" have established a feeling of Camaraderie, but not established trust... and that this is a problem.
Posted by Mishkin Berteig at 10:08 AM | |
November 15, 2006
Quality as a Corporate Asset
Ken Schwaber has a great talk about quality which supports and confirms my earlier article called Quality is Not Negotiable.
Posted by Mishkin Berteig at 04:05 PM | |
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 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 11, 2006
Stronger Teams Blog
The blog Stronger Teams by Blaine Collins has some incredible stuff on it. I've read quite a few of the entries and they all show the importance and relevance of teams and teamwork to Agile Work methods. Considering some of my recent comments, thinking and coaching experiences, I love the current top article: Treat team members as ends and not means. This correlates strongly to what I consider a distinguishing feature of agile methods: meta-learning done by the team, and it also works well with the Agile Axioms.
Posted by Mishkin Berteig at 06:20 PM | |
October 27, 2006
Some Good Links
Mark Levison, a regular contributor on the ScrumDevelopment Yahoo! group and now a student of mine (at the Certified ScrumMaster class), sent me this bunch of links to his blog which in turn link to other great resources. Check them out:
Best Introductions to Scrum (Mark writes:
"I especially like Ken’s video. In an hour he explains the core of scrum. This video is very handy when you’re trying to introduce scrum to new team members etc.")
Posted by Mishkin Berteig at 02:23 AM | |
October 22, 2006
Cool Site: Implementing Scrum
An agile coach that I have worked with in the past, Mike Vizdos, has teamed up with an artist to create a web site about agile with a weekly comic str