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 strip. This site, Implementing Scrum, has a few comics already there. Each comic examines an aspect of Scrum and Mike provides some interesting commentary related to the comic. Take a look, bookmark it, and check back regularly!
Posted by Mishkin Berteig at 06:50 PM | |
October 18, 2006
Burndown and Velocity Spreadsheet
Jay Conne has posted an Excel spreadsheet tool to use for teams doing agile. The spreadsheet includes a lot of flexibility to account for a single team working with different types of work (e.g. maintenance work). Check it out! This is the link to the burndown and velocity tracking spreadsheet.
Posted by Mishkin Berteig at 01:19 PM | |
September 29, 2006
The story-driven standup
We all know the three questions of the daily SCRUM standup. In every standup we go around the room one way or the other and give a status on our tasks. This is what I've come to call the status-driven standup. In my article I've proposed a different style of standup I've come to call the story-driven standup.
You can find the article here: The Story-Driven Standup
Posted by Guest at 08:55 PM | |
September 22, 2006
A Good Agile Blog
I have found a good blog about agile software development. Although software-focused, there are several articles I have read that deal with teamwork, personal dynamics, management and other topics that are generally applicable.
Posted by Mishkin Berteig at 11:56 AM | |
September 21, 2006
Agile Advice Recommended Materials (Updated)
Agile Advice Recommended Materials page of links has been updated with six items. This page is slowly growing into a substantial reference. Please feel free to suggest things to add: web sites, blog articles, pdf's, books, etc. Any thoughts on turning this page into a wiki? Is there an existing wiki to which I can move these?
Posted by Mishkin Berteig at 07:15 AM | |
September 20, 2006
Intro to Scrum - and Excellent Data from Yahoo!
Yahoo! has been using the Scrum methodology for quite some time now and two of the key people there have written up an excellent description of Scrum [pdf] along with a set of survey results from the 600 people using the method at Yahoo!. The best highlight from the results is that 85% of team members said that they would continue using Scrum if the decision was left up to them!
Posted by Mishkin Berteig at 03:58 PM | |
September 19, 2006
Agile Challenges - A Good List of the Common Problems with Agile Methods
Aaron Korver writes a list of ten ways that agile can have problems. Here's the list in brief with my comments:
1) Increased Visibility can cause organization crisis. Use an understanding of corporate culture to help prepare for this crisis.
2) Loss of titles. Agile tends to flatten organizational hierarchies.
3) People have to work together. And most people in large organizations work in groups, not teams. Small organizations might not have this problem.
4) Projects fail fast. They also can succeed fast... either way this can cause budgetting problems and all the corporate politics that goes along with this.
5) Sustainable pace. Some people like heroics, and most organizations respect and reward heroics - this is very very hard to change.
6) Feeling of micro-management. But teams are actually supposed to be self-organizing.
7) Less up front design. Getting started is one of the most difficult things for many organizations.
8) Flawed implementation of agile. Setting up the environment and the support a team needs is not trivial.
9) Physical reorganization costs. Although usually these costs are recovered in productivity increases.
10) Loss of privacy. It takes time for people to get used to working together.
This is a good list and I have seen all of these things be challenges to teams and organizations adopting agile methods. I've linked each one of the above to one of my previous Agile Advice articles.
Posted by Mishkin Berteig at 04:21 PM | |
September 18, 2006
Agile Documentation Tool: Tiddly Wiki
This is super cool: TiddlyWiki - a wiki that you can run locally. Just download the empty TiddlyWiki.html file onto your hard drive or a USB key or an SD card, etc. Put it into a subversion repository and you have a way of treating documentation just like code: nicely versioned, flexible, easily editable by anyone, and just generally really really cool!
Posted by Mishkin Berteig at 08:44 AM | |
September 15, 2006
Agile Survey: Lots-o-good
An agile consulting group in the US has run a survey on the results of adopting agile methods. Some highlights:
Scrum was the most-used methodology at 40% of respondants.
Time to market was a big benefits with 60% of respondants indicating an improvement of 25% or more.
And a lack of people with agile experience was the single largest factor cited in preventing or slowing the further adoption of agile in the organizations.
Thanks VersionOne!!!
Posted by Mishkin Berteig at 11:45 AM | |
September 14, 2006
Agile Work for Publishing
Michael Fitzgerald got the idea to apply agile methods to publishing. The article I have linked to is a good description of what he is thinking.
He could take the idea a lot further. For example, he staggers the work of the writer and the editor. This is "mini-waterfall". Sure, it's better than one big bang of editing at the end, but it's still not doing the work simultaneously. Or writing one chapter per iteration. That only works if you can publish each chapter on its own. Each iteration should end with a potentially shippable result. It would be better to write a prose-style outline of the whole book, with maybe a little bit more detail in some key part.
Those observations aside, it is nice to see someone thinking about applying agile outside of software.
Posted by Mishkin Berteig at 10:17 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 | |
Agile Software Development Forums
This is still new, but it looks to be shaping up to be a good place to go to talk about agile software development.
Posted by Mishkin Berteig at 12:35 AM | |
September 06, 2006
The Product Owner Role
I've been researching the requirements and variations on the Product Owner Role for a client that I am assisting. Here is a small collection of links and notes.
Updated (Originally posted Nov. 18, 2005).
Being an Effective Onsite Customer or Product Owner - great description of the ideal Product Owner.
Agile Product Owner Boot Camp - nice little bit in here about collaboration.
Certified Scrum Product Owner Course - don't know how good this is, but might be useful.
Here is my suggestion for a definition of the Product Owner role:
The Product Owner holds the final authority for determining the value, priority and details of all work done by an Agile team. The Product Owner wields this authority by virtue of a deep knowledge of the goal and end results desired as well as a respected position among all the stakeholders.
The Product Owner role is also known as the Queue Master, the Customer. People who have done the Business Analyst and Product Manager roles are often good candidates to fill this role.
Posted by Mishkin Berteig at 11:02 AM | |
September 02, 2006
Scrum and SVO-p
SVO-p is an English syntax well suited for use in Agile processes such as Scrum. SVO-p stands for Subject-Verb-Object, Present Tense. Communicating in SVO-p requires defining who is acting, what they are doing, and to whom. It requires placing the thought in the now. The special features of the SVO-p syntax make it particularly well suited for use in Agile communications.
For more information, please read the blog entry: Scrum and SVO-p (Dan Mezick, APLN Hartford Chapter)
Posted by Guest at 12:21 AM | |
August 30, 2006
Excellent Article about Learning
Circles of knowledge and boundaries of ignorance.
Posted by Mishkin Berteig at 07:34 AM | |
August 29, 2006
Seventeen Tips for Iteration Planning
Agile Work requires a team to take work items from a prioritized list, break those items into small tasks and then execute those tasks inside of the timebox of an iteration. When first trying agile, many teams have trouble with the task breakdown done in the iteration planning meeting. Here are some hints and tips for making this critical part of the agile process more effective.
1. Work items are, among their other qualities, valuable to the customer or stakeholders. Think of these work items as being built out of many smaller pieces. You can imagine a toy model made out of Lego bricks. Each brick, by itself, is of no value. It is only when they are put together that they become useful. The tasks you create for each work item are often small enough that they do not have any value on their own.
2. The word "task" implies activity... but the tasks you create for your work items do not need to be activity based. Tasks can be effective if they are written as components or pieces of the work item you are building. Here is an article about creating good tasks.
3. Sometimes if the work item is not well understood, you might find that a "research" or "experiment" task is a good starting place. Try to be as specific as possible. When writing the task description, spell out what exactly is the goal of your research, and possibly list what options you are going to research.
4. When first starting out with Agile Work, many teams find it difficult to do a good job of iteration planning in the fixed amount of time allocated to it. Consider shortening your iteration length so you can practice this skill more frequently. (Remember to make the planning meeting shorter too!)
5. Make sure that everyone has index cards and a pen to write with! Team members shouldn't have to wait for a "scribe" to write down a task. In many ways this is a brainstorming session. The Process Facilitator can collect all the cards after the meeting is finished if they need to be recorded more formally.
6. Do a first pass by creating "big" tasks... then break them up into smaller tasks if you have time. Since this meeting is timeboxed, it is better to get all the work broken down into big chunks than to break down only a small part of the work into very fine chunks.
7. If the same task keeps showing up for all your work items, it probably shouldn't be a task... instead it should probably be a process step or constraint or condition of satisfaction for the work you are doing. For example, if you always have to write a document that follows a template to record what you have done for each work item, then writing that document can be shown as part of your task board.
8. It's okay for tasks to be _very_ small.
9. Share your tasks! If you write a task down without telling the rest of your team, they can't use your idea to generate more tasks, nor can they improve on your idea.
10. Generating tasks in the iteration planning meeting is a problem solving and creative process. This is where you do a lot of your analysis and design work. This is where you struggle through options and choose _how_ to build/do your work.
11. Consider creativity technique such as light-weight brainstorming for generating lots of ideas quickly. Any technique you use should be streamlined for quick results.
12. Don't worry about administrative stuff while you are generating tasks. For example, if you normally put task cards up on a wall, wait until after the meeting is over to do this. Likewise, if you normally enter them into an electronic tools, wait until the meeting is over to do this.
13. Make sure you have scrap paper or a good whiteboard convenient for notes and drawings so that you can quickly model your solution for the work item. (Check out Agile Modelling for a discussion of this in the software realm.)
14. Remember that it's okay if you end the meeting with an imperfect list of tasks. You will make corrections throughout the iteration. It is more important to maintain the discipline of the timeboxed meeting length, than to get the tasks right up front.
15. The whole team must participate: everyone's experience, skill, expertise and insight are needed to do the best job of generating tasks. Just because it won't be a perfect list doesn't mean you can do a shoddy job of it!
16. You need quick access to information about the work items you are planning. You also need quick access to other relevent information. A computer with a web browser open to Google is a great tool to have at hand.
17. If you don't have anyone on your team who has lots of diverse experience and expertise, then consider inviting someone like this as a guest to help you out. It is much more difficult to do the necessary problem solving if you new to the medium in which you are doing the solving. Such a guest would need some time before the meeting to be prepared.
Posted by Mishkin Berteig at 10:44 PM | |
August 25, 2006
Appropriate Process
Another interesting link for the morning: Appropriate Process. This is a small group of UK-based consultants who describe a clear and reasonable idea: use only as much process as is appropriate. They have a manifesto and set of values that are compatible / based upon the Agile Software Manifesto and the Extreme Programming Values.
Posted by Mishkin Berteig at 08:49 AM | |
Hmm... Holacracy
Well, this is interesting: Holacracy. It is a web site describing some aspects of an organizational system that sounds like a slightly modified Scrum of Scrums, with some electoral ideas thrown in, and a philosophy remarkably like the Agile Axioms. There are some very interesting ideas there.
Posted by Mishkin Berteig at 08:30 AM | |
August 23, 2006
Five Pitfalls of Agile Adoption
Siddharta Govindaraj has written a brief and useful reference article on the Five Pitfalls of Agile Adoption. One of his recommendations for avoiding these pitfalls is to address organizational culture. I strongly recommend the book The Corporate Culture Survival Guide
Posted by Mishkin Berteig at 05:33 PM | |
August 22, 2006
Does Process Matter? ... No! Yes! Maybe!
Interesting theoretical article called Does Process Matter? It's an interesting article in that it provides some thinking about levels of process: individual, team, project and enterprise. In the conclusion, the author claims:
Now that I have described a way to think about team size and process levels, I can assert that the Agile community at the [Agile 2006] conference is mainly looking at the team-level process, even though many of the thought leaders claim otherwise. As I noted at the beginning, smaller organizations growing into enterprise organizations must change their processes, with the realization that Agile methods may not suffice at the enterprise or project levels.
I heartily disagree!
While it is true that some people are focused on the individual and team levels of process, the agile community, myself included, are actively working on agile approaches at the project and enterprise level.
The author's claim is ridiculous! The only hint of truth in it is that agile methods are more mature in their application at the individual and team levels. But there is still plenty going on at the project and enterprise level.
Two years ago, minus three weeks, I started working at a large financial company interested in the enterprise application of agile methods. Over the course of the next eight months, I was actively involved in the application of agile methods at the project level, the portfolio management level, and the corporate strategy level. True enough, I wasn't a key player... nevertheless, I was involved enough to know that the application of agile at these levels is at least two years old.
Not only that, but agile methods, particularly when combined with explicitly lean approaches, are fantastically appropriate at these levels. All the values of the Agile Manifesto, stripped of their software specificity (since we're dealing with management) are applicable and sound.
People matter more than process and tools! A really good example of this is the bureaucratic nightmare that can come if a company tries to standardize on a particular process/tool across the board. This is like telling people that they all have to drive the same car to work!
Collaboration is more important than contract negotiation! Contract negotiation is a pure waste... anything that can be done to reduce the effort spent on this is valuable. But it boils down to trust, and the only way trust can develop is through commitment, face-to-face interaction, and truthfulness. This is a value. You can processize truthfulness!
Working software over comprehensive documentation... in otherwords, delivering value instead of waste. Toyota is everyone's favorite example, but there are others: NuCore Steel comes to mind. If your customers are paying for software, don't deliver other stuff. If your customers are paying for widgets, don't deliver reports. If your customers are paying for services, do them quickly and with extremely high quality standards.
Responding to change over following a plan! Imposing any process blindly is lunacy. Agile methods, particularly Scrum and Lean, are actually meta-processes that improve both Product and Process itself. They aren't defined methodologies, and they explicitly foresake long-term planning: Scrum with iterative delivery, Lean with pull systems. And they work for individuals, teams, projects and enterprises!
So, what do I say to this article? Nice try, buddy. Try again!
Posted by Mishkin Berteig at 09:10 PM | |
The Team Room
In researching some material for a course I am delivering, I came across this great reference web page about setting up a team room. The article includes links to a good number of industry and academic studies. Update: also, check out my previous article about optimizing a team room.
Posted by Mishkin Berteig at 10:54 AM | |
August 20, 2006
Gall's Law
Brief, but interesting article on Wikipedia about a systems law that strongly supports the incremental delivery that agile methods promote.
Posted by Mishkin Berteig at 12:39 PM | |
August 18, 2006
Agile Coach = Agile Secret Police... sort of
Paul Tyma has written an interesting and provocative article titled "Agile Coach = Agile Secret Police". As a coach myself, I actually agree with most of his article...
Agile is simple. There is no doubt about it. Agile methods tend to be easily explainable, most of the practices make sense to people, and you don't have to study for years (maybe just days) to get a good solid understanding of an agile method like Agile Work, Scrum or XP.
So why bother with coaching? Many teams and organizations do not need it. With motivated people who have done their reading, and with a reasonably supportive organization, a team can fairly easily try an agile method and get good at it.
The need for a coach comes when there is doubt about those conditions: motivation, or a supportive organization.
This is just like coaching in other aspects of life such as the personal trainer we employ to help us learn the discipline needed to get in shape, or the sports coach employed to help see the big picture and keeps people motivated (in what one athelete called a fundamentally silly and pointless profession).
So as a coach, what do I do? Basic and "advanced" training to help a team or an organization learn about agile. I practice what I preach to help people learn by example. I watch what people are doing and talk with them about why they are doing it to help people stay motivated, and change their un-agile habits. I protect a team in its early stages from challenges that come from other parts of the organization they are working in.
This is all the more necessary in the early stages of the adoption of agile methods. The most difficult part of doing agile is that all the crisis in a project is pushed to the front of the project. By attempting to deliver real, valuable results in the first iteration of a project, all the problems that would normally show up at the end of the project, show up at the start. This makes people uncomfortable and sometimes downright upset. A coach can help people get through this, just by continuing to say "this is normal, this is healthy, work through it and it will pass."
So as a coach, am I like the agile secret police? Well, I don't put people in prison for not spouting the agile line... so you be the judge.
Posted by Mishkin Berteig at 09:48 AM | |
August 15, 2006
Lean in Hospitals
Thanks to Deborah Hartmann who pointed me to this article about the use of the Toyoto Production System (Lean) at hospitals in the United States. They have some interesting "waste" figures that to me actually seem _low_. The article notes a 40% process cycle efficiency, but if I would have been asked to guess, I would expect a number more like 10-15% for the hospital system. Thoughts on why there might be this discrepancy? Am I just way to pessimistic?!
Posted by Mishkin Berteig at 02:07 PM | |
July 10, 2006
Test-Driven Management
An oldie, but a goodie, this short paper about Test-Driven Management is an excellent introduction to the topic. It is phrased in terms of the Extreme Programming practices, but it is generalizable to most types of agile work.
Posted by Mishkin Berteig at 11:26 PM | |
July 04, 2006
Lean Blog
Check out Panta Rei - Everything Flows, Everything Changes. This blog, by author Jon Miller, has extensive archives well worth poking through.
Posted by Mishkin Berteig at 07:09 AM | |
June 08, 2006
Twelve Games to Play With Your Customers
My associate Deb Hartmann who writes at VitalBrew let me know about a set of twelve "innovation games" to play with your customers. I have never used them, but in reading through them, they appear to be compatible to an agile approach to working with customers.
Posted by Mishkin Berteig at 02:32 PM | |
June 07, 2006
Updated 2 Older Articles: Agile Work Roles and Waste vs. Value-Added
The Agile Work Roles article has been updated with more detail about all three roles and some additional commentary and links. This is a useful article to share with people who have already been introduced to agile methods, particularly if you are having trouble with a command-and-control management style (by management or team members).
The Waste vs. Value-Added article has an extended quote from the book Lean Six Sigma : Combining Six Sigma Quality with Lean Production Speed
Update 20060608: added the second link!
Posted by Mishkin Berteig at 09:01 PM | |
June 02, 2006
Cueing Agility - Creating a Supportive Environment for Agile Teams
In Blink : The Power of Thinking Without Thinking
In one experiement, researcher John Bargh designed a scenario to test how sensitive we are to written cues that are structured in a way that we are not consciously aware of being cued. Bargh created two lists, each composed of five words per list item. Of the five words, four were chosen to form a sentance, and the fifth word was selected so that it would not fit with the other four. Then the five words were jumbled.
For example:
rang phone peace the loudly
The people who came as subjects of the experiement were given one of the two lists and told to go through their list as quickly as possible and un-jumble the sentances.
Unbeknownst to the participants in the experiment, each group of five words also contained a word that was selected to suggest a feeling or attitude. In the first list, each group of five words contained one word that would suggest impatience, rudeness and aggressiveness. The second list contained words to suggest patience, politeness and calm.
All the subjects of the experiment were also given additional instructions to come to a particular office once they had completed their lists. At the office they were to receive final instructions. At the office, each participant encountered the experiment administrator deep in conversation with another person. Neither the administrator nor the other person acknowledged the just-arrived subject. Now the real purpose of the experiment was tested: how long would the subjects wait before interrupting the ongoing conversation?
The results were astonishing: those people who were cued with the list containing words suggesting impatience, rudeness and aggressiveness
eventually interrupted - on average after about five minutes. But of the people primed to be polite, the overwhelming majority - 82 percent - never interrupted at all. If the experiment hadn't ended after ten minutes, who knows how long they would have stood in the hallway, a polite and patient smile on their faces? (p 55)
Gladwell gives several more similar examples in his book. I strongly recommend reading this book to see just how powerful this cueing or priming effect can be.
For organizations, teams and even individuals, this effect can be harnessed. The most obvious ways include using posters, screen savers, banners etc. to constantly impress people with positive messages about teamwork, effectiveness, creativity and other values and qualities that might be deemed valuable. This should obviously go hand-in-hand with a conscientious removal of all negative messages.
For agile teams, there are some particular values that should be emphasized: truthfulness, courage, creativity, teamwork, trust, cooperation, hard work, learning, adaptability.
The message can also be communicated in more subtle ways - and this is actually likely to be more effective! Incentives, the power of exemplary behavior, and the physical environment itself all can contribute strongly. In Built to Last : Successful Habits of Visionary Companies
(p 122)
- Fervently held ideology...
- Indoctrination
- Tightness of fit [for employees]
- Elitism
Interestingly, agile methods do tend to require "buy-in". In order to fully feel comfortable in an agile environment, people need to understand and fully accept a small number of very important beliefs:
(These are the generic, non-software version of the Agile Software Manifesto.)
See also: Optimizing a Team Room
Posted by Mishkin Berteig at 11:26 AM | |
May 31, 2006
The Human Touch
If you are given a problem to solve, how much does the presentation of that problem matter to your ability to solve it? Imagine that it's a simple problem... imagine that it is presented in two different ways, both of them simple. It turns out that presentation differences can still make a huge difference. In fact, there is a way to present problems that makes them substantially easiers to solve: make them people problems.
In The Tipping Point: How Little Things Can Make a Big Difference
Consider the following brain teaser. Suppose I give you four cards labeled with the letters A and D and the numberals 3 and 6. The rule of the game is that a card with a vowel on it always has an even number on the other side. Which of the cards would you have to turn over to prove this rule to be true?
Go ahead and take a few moments to figure that out before continuing on to the answer, and keep track of how long you work on it...
The answer is two: the A card and the three card. The overwhelming majority of people given this test, though, don't get it right. They tend to answer just the A card, or the A and the six. It's a hard question. But now let me pose another question. Suppose four people are drinking in a bar. One is drinking Coke. One is sixteen. One is drinking beer and one is twenty-five. Given the rule that no one under twenty -one is allowed to drink beer, which of those people's IDs do we have to check to make sure the law is being observed?
How long does it take you to figure that out?
Now the answer is easy. In fact, I'm sure that almost everyone will get it right: the beer drinker and the sixteen-year-old. But, as the psychologist Leda Cosmides (who dreamt up this example) points out, it is exactly the same puzzle as the A, D, 3, and 6 puzzle. The difference is that it is framed in a way that makes it about people, instead of about numbers, and as human beings we are a lot more sophisticated about each other than we are about the abstract world.
Now unless you had heard about this before, I suspect you were pretty suprised. I know I was! I always considered myself to be a very good abstract thinker/problem solver. In fact, I considered myself to be well above average in that regard for a number of reasons: I was always very good at math without every memorizing a single formula (I always made them up as I went along as long as I remembered the _idea_ of the formula), I was an excellent programmer in a number of different computer languages including assembler, Miranda, Java, Prolog, Pascal, and Objective-C, and finally, I'm always solving problems by moving the problem to a new level of abstraction - solving the meta-problem first.
So what does all this have to do with agile work methods? Quite a few things actually:
1. Obviously, if you can frame a problem as a people problem, it will be easier to solve... and most problems start out this way!
We tend to try to abstract problems, make them more generic or general purpose in the hopes that they can be communicated more precisely and can be solved in a way that will accomodate contingencies we haven't thought of yet. But all the effort we put into abstracting the statement of the problem ends up costing us doubly: in the initial abstraction and in the difficulty of solution that results. So if you have a team that is solving a people problem, make sure to keep it a people problem when you give it to the team!
2. If you have a problem that is given to you in an abstract form, try to convert it to a people problem before trying to solve it.
In all likelihood, the moment you do the conversion, you will quickly see the solution. It may even feel like the process of de-abstraction is a problem-solving process. You may have to make really odd connections to make the problem a people problem but it will likely be worthwhile.
3. Dealing with people rather than abstractions on a day-to-day basis will always result in a more effective interaction.
Sending printed documents, writing emails, manipulating symbols are all interesting ways to communicate, but fundamentally, you are communicating with other people. If you can make that communication as direct as possible - phone, video conference, in-person - then there will be far less effort involved in understanding the communication, and far more effort can be allocated to high-bandwidth communication. This obviously has special relevence for teams: get people in the same room as much of the time as possible.
In the software world, there is one technique that I give teams and that is the use of Personas to assist in solving a software problem. The place I first encountered Personas is in the excellent book The Inmates Are Running the Asylum
The bare essense of the Persona is to create a fictional person who represents a user or actor or stakeholder or customer of whatever it is you are building. This fictional person should have a name and all conversation about the thing being built should be couched in the personal language of these Persona's names. A Persona should also have a short history, a photo and some description of their needs, goals or desires. All of this helps to frame everything about a software project as a people problem... and thus makes it much easier to discuss and solve.
Posted by Mishkin Berteig at 11:12 PM | |
May 30, 2006
Integrated Scrums - Paper by Jeff Sutherland
Jeff Sutherland has announced a paper describing the use of the Scrum methodology in a large distributed project. One of the very interesting unique features of this project is that members of each Scrum team were distributed geographically across several locations., rather than having everyone on a single team all co-located at a location. The paper also talks about lean practices and software engineering practices used on the project.
Posted by Mishkin Berteig at 02:28 PM | |
May 18, 2006
Thoughtful Blog
Once in a while I run across a blog that I really like. This one, BrainScrum, doesn't have frequent postings, but I _really_ like what's there!
Posted by Mishkin Berteig at 01:00 PM | |
May 05, 2006
Waterfall vs. Agile
In the Agile Dragon, Scott Sehlhorst, a software guy with a mechanical engineering background, has written a very interesting take on the agile approach vs. an approach called "Interaction Design". While I love many of the ideas and even the results that come from good interaction design (check out The Inmates Are Running the Asylum
He posits that agile's greatest strengths come as a result of being able to accomodate change. He also makes a pseudo-mathematical analysis of the cost of change in an agile method. Finally, he asserts that good requirements as derived and set forth by the interaction design method eliminate a fair amount of the need for change.
Agile's Greatest Strength
Agile method's greatest strength is actually about early delivery of working results. As I said in response to his post:
The end of the first iteration (usually somewhere between one and four weeks) results in a little bit of software that actually works. This has the staggering advantage that the customer/sponsor can take that little bit of usable software… and use it! Even if the client waits for a few iterations before the software has enough functionality, and only then uses it, the advantage is still huge. In any process where all the requirements are gathered up front, regardless of how or what is done with them afterwards, there is a large delay in getting the first bit of usable working software in the client’s hands.This delay _costs_. It costs both money and opportunity. Regardless of how stable or unstable the requirements are, agile methods deliver a return on investment much much sooner than any other approach to building software. As you pointed out:
“Customers know what they want - higher profits, greater market share, etc.”
For both of these desires, the best way to get them is by the reduced cycle time that using an agile method provides.
Cost of Change in Agile
Agile methods acknowledge that a customer/client knows a lot of what they want already... and that they even know what is most important! Therefore, the further along in a project one goes, (barring the kind of unforeseen change to which agile responds well) the more stable the resulting product will be.
This emphasis on the early deliver of highest value requirements gives the customer/client even more options: the project can be cancelled early if the cost of building features is higher than the value delivered by those features. This is impossible in a waterfall approach.
Good Requirements and Interaction Design
I would love to see some more careful analysis of this. I don't know enough about interaction design to say if this is true or not, but I do know that this is a big claim that is contrary to much of the statistical evidence. I'm willing to accept that it is possible, but I'd love to understand better the theoretical underpinnings. Scott?
Posted by Mishkin Berteig at 08:30 AM | |
May 03, 2006
A Brief History of Agile
I was recently asked: "where does Agile come from?" It's easy to answer this on the surface: from software development. But digging a little deeper, there's a lot more going on. This paper by Craig Larman and Victor Basili details a brief history of Iterative and Incremental Development [pdf] (focused a great deal on US military software history). The Agile Alliance is one of the better sources for articles, papers and other resources relating to the history of agile software development.
Posted by Mishkin Berteig at 09:50 PM | |
April 24, 2006
Link: Eight Barriers to Effective Listening
On the Retrospectives Yahoo Group, Michael Webb posted a link to his article Eight Barriers to Effective Listening. This article provides practical advice on how to improve communication. Since one of the basic practices of Agile Work is to maximize communication, this article is essential reading!
Barriers to Effective Listening
Just in case you don't go follow the link from my introduction, here is a bit more info to help convince you:
As a process facilitator, one's responsibility is to remove obstacles. This is a list of obstacles to communication and includes for each barrier a strategy to overcome the barrier. Therefore, anyone who is a process facilitator (agile coach, scrummaster, etc.) should look this over and incorporate it into their skill set.
Here is the list of the eight barriers to effective listening:
- Knowing the Answer
- Trying to be Helpful
- Treating Discussion as Competition
- Trying to Influence or Impress
- Reacting to Red Flag Words
- Believing in Language
- Mixing up the Forest and the Trees
- Over-Splitting or Over-Lumping
Mr. Webb ends his article with a very nice self-referential comment:
We can make a difference in the world by learning to listen better and by telling others about better listening. But only if they listen.
Update 20070911:
Interestingly, I believe there are two more barriers to effective listening:
1. Distraction! I know that I have a hard time listening if I am tired, if I am worried about something, if I have sensory overload from another source, or (to my embarrassment) even if I just have my email open while talking on the phone.
2. Poor communication tools! It is much easier to listen effectively if I am face-to-face with the other person. Any type of technology that is used to communicate between two people becomes a barrier to effective listening: email, telephone, chat, etc.
Here is an interesting online quiz/presentation about the barriers to effective listening. In this presentation, there are seven barriers to effective listening listed:
- Content of the message
- Appeal of the speaker
- External distractions
- Emotions
- Clarity of language
- Selective perception
- Inappropriate feedback
Posted by Mishkin Berteig at 10:50 AM | |
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 07, 2006
Great List of Quotes for Browsing
This list of Quotations for Learning and Programming is heavily weighted towards programming tasks, but there is a lot of very generally applicable wisdom. Here's a sample:
A common mistake people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools. (D. Adams)
Posted by Mishkin Berteig at 02:24 PM | |
March 28, 2006
FBI's Virtual Case File Failure
Great, looooong article about a massive software project failure. Over $100 million down the tubes. Could Agile have saved it?
Posted by Mishkin Berteig at 12:43 PM | |
March 20, 2006
Organizational Development Coach
A good friend of mine and a fellow coach, Michael Hamman, has a very nice website with an interesting, challenging and engaging manifesto. Please visit his site: http://www.ecosystemae.com/. Michael focuses on organizational development and how people work in organizations. As a person he is both sensitive and intelligent and can see deeply into both what is good and what ails an organization or a team or simply, a fellow human being.
Posted by Mishkin Berteig at 10:31 PM | |
March 16, 2006
Carnival of the Agilists
Another great selection of blog articles related to agile at the Carnival of the Agilists.
Posted by Mishkin Berteig at 05:57 PM | |
March 14, 2006
Updated: Agile Advice Recommended Materials
Over the course of the past month or so, I have added many new references to the Agile Advice Recommended Materials page. Thanks to people who have suggested links and books! If you want to suggest additional resources that you think are excellent, please let me know in the comments. I'm going to start tracking who suggested what so that I can give due credit!
Posted by Mishkin Berteig at 12:17 PM | |
Agile or Not Agile?
Every once in a while the del.icio.us tag for Agile turns up something really interesting. This evening, I found this article about the ongoing use of the term "Agile". The article is brief and a little weak, but it brings up a concern that is always niggling in the back of my mind. Interestingly enough, a good friend of mine, Christian Gruber, emailed me another web page of similar import...
In this registration page for Rules of Enterprise Agility, we read about something that really has nothing to do with the Agile Manifesto, nor the Agile Axioms.
Both of these examples are signs of two things:
1. The growing popularity of the term "Agile".
2. The growing dilution of the meaning of the term.
How can we fight this? Should we fight this?
I think it is very important to constantly call attention to the fact that Agile is about the minimum process and tools that can possibly work, and only in the context of valuing individuals, interactions and teams more than those tools and processes.
Trust is the Foundation of Agile Work
Technology, tools, process, even good ideas and good organizations do not create trust. People create trust by being trustworthy: honoring their commitments, striving for excellence, truthfulness, courage. One of the fundamental problems afflicting organizations is the lack of trust: between management and employees, between business and IT, between experts of various sorts, between coworkers.
This lack of trust is institutionalized in many ways including bureaucracy and legal frameworks.
The only way to change this state of affairs is to build trust. And the only way to build trust is to embody trustworthiness in yourself so that by example and by your words you can help others to become more trustworthy.
Agile methods put in place mechanisms that assist in building trust. But those mechanisms are merely a means to an end. Let us never forget that.
Posted by Mishkin Berteig at 12:27 AM | |
March 12, 2006
Work Item Backlogs as Queues - Agile vs. Lean
A recent discussion on the Scrum Development list (Start of Discussion) provides a good follow up to my parting words in The Art of Obstacle Removal about agile practices themselves becoming obstacles. I have excerpted a small amount of the discussion and added my own comments here.
In the agile community, most of us have bought into and adopted the Agile mental model. But that mental model has assumptions embedded into that may not be correct under all circumstances. Part of that mental model includes the efficacy of the work item backlog as a tool for tracking, prioritizing and communicating work to be done in the future.
I will be the first to say that Agile is far better than waterfall in almost every situation (the exception being the mythical project with stable requirements, business environment, technology and team).
That said, let's look at backlogs from another perspective: if a backlog was the only thing you delivered to the customer, would they pay for it? If you spent even just a few hours coaching a business representative to build a backlog, but there was no team to implment it, would that person really find value in the backlog itself? Would they be able to deliver ROI just from a backlog? I think the answer is a clear "no".
That set of questions may seem silly, but from a lean perspective, they are among the most important questions. Is an artifact/process value-added or non-value-added?
Since the backlog is clearly not a value added artifact/process (pause for effect)... it is waste!
When one is doing agile effectively, the backlog may in fact be one of the larger sources of waste! If the team has a stable velocity, there will come a point when the backlog becomes the constraint on the overall cycle time going from idea to ROI. If the backlog is large/long, and as Mary Poppendieck said if there is more than ...maybe two or three
sprints of work.... in there, then it may be time to find ways of constraining the size of the backlog. I have two suggestions:
Capacity of Team(s):
Find a way to increase the capacity of the team so that the backlog size reduces and then goes into a steady state. This may mean augmenting the staff.
Gate Backlog Items by ROI
(This is just theory to me at this point.) Make it a condition that all backlog items must have a positive ROI. In other words, the cost of building the backlog item needs to be less than the value delivered, taking into account time value of money. Don't let items onto the backlog unless this positive ROI can be demonstrated.
I believe the lack of this second discipline (assigning ROI to work items) is one of the main reasons that most agile methods such as Scrum allow an unlimited backlog size: there is no realistic way to gate the work that gets onto the backlog!
Until teams get to Agile nirvana (stable velocity, continuous delivery of business value, high-performance cohesive teams), having an unlimited backlog seems like a very reasonable thing: it's not the constraint or the primary source of waste. However, eventually the backlog will become a primary source of waste and it needs to be treated in a disciplined manner.
With a stable and well-functioning team, what other ways might there be to reduce the size of the backlog so that cycle time is substantially reduced?
Posted by Mishkin Berteig at 03:31 PM | |
March 10, 2006
The Art of Obstacle Removal
One of the best ways to go faster is to remove the things that slow you down. This "obstacle removal" is an integral part of many agile methods including Scrum and Lean. Sometimes it is obvious where an obstacle is. There are a few small things that can be done easily to go faster. But to get going really fast, we need to have a deeper understanding of obstacles... and the Art of Obstacle Removal.
What are Obstacles?
An obstacle is any behavior, physical arrangement, procedure or checkpoint that makes getting work done slower without adding any actual contribution to the work. Activities that do add value to our work may be slowed down by obstacles, but are not obstacles in and of themselves.
Obstacles and Waste
Obstacles are the causes of waste in a process. There are many types of waste, and for every type of waste there are many possible sources (obstacles).
Types of Obstacles
Personal
Personal obstacles are related to us as individuals. There are several levels at which these obstacles can show up.
Outside factors in our lives such as illness or family obligations can become obstacles to our work at hand. These obstacles are hard to remove or avoid. Even if we would want to avoid an obstacle such as illness, it is hard to do anything about it in an immediate sense. However, as part of our committment to the group we are working with, we should consider doing things to generally improve our health. Good sleep, healthy and moderate eating, exercise and avoidance of illness-causing things and circumstances are all possible commitments we can make to the group. Likewise, we can make sure our personal affairs are in order so that unexpected events have the least impact possible. This topic is vast and there are many good sources of information.
Physical Environment
Obstacles in the physical environment can consist of barriers to movement or communication, or a lack of adequate physical resources. Sometimes these obstacles are easy to see because their effects are immediate. For example, if a team room lacks a whiteboard for diagrams, keeping notes, etc., then the team may not be able to communicate as effectively.
Other physical obstacles are not so obvious. The effects of physical environment can be subtle and not well-understood. Poor ergonomics take weeks, months or years for their effects to be felt... but it is inevitable. A too-small team room can lead to a feeling of being cooped up and desperation to get out... and eventually to resentment. Again this can take weeks or months.
Here are some guidelines on a good team room.
Knowledge
A lack of knowledge or the inability to access information are obstacles. A team composed of junior people who don't have diverse experience and who don't have a good knowledge of the work they are doing will have trouble working effectively. There may be barriers preventing the team from learning. Common barriers include over-work leading to a lack of time or mental energy for learning. With junior people in particular, there is a lot of pressure to be productive and that can often be at the expense of a solid foundation of learning.
Other times, knowledge-related barriers can be more immediate. If a critical piece of information is delayed or lost this can have a large impact on an Agile team that is working in short cycles. The team may be temporarily halted while they wait for information. Building effective information flow is critical to a team's performance.
Organizational
One of the best sources of information about this is the two books by Jim Collins: "Good to Great" (Review) and "Built to Last" (Review).
Cultural
In organizational culture, one thing I constantly see is a public espoused value of teamwork, but a conflicting behavior of individual performance reviews and ranking. This is cultural. It is also a barrier to the effective functioning of an Agile team. For corporate environments I highly recommend the Corporate Culture Survival Guide by Edgar Schein.
Dis-Unity
Dis-unity is one of the most subtle and common forms of obstacle. Competition, legal and cultural assumption of the goodness of "opposition" and habits of interaction including gossip and backbiting all combine to make united action and thought very difficult.
This is an extremely deep topic. There are many tools and techniques available to assist with team building. If you are interested in this topic, I highly recommend reading "The Prosperity of Humankind".
Removing Obstacles
The ability to identify obstacles and understand why they are causing problems is only the first step in removing obstacles. In Agile Work, the person primarily responsible for identifying and removing obstacles is the Process Facilitator. The Process Facilitator has several approaches available for the removal of obstacles. A process facilitator has similar responsibilities to a change agent.
Direct
Deal with the obstacle directly without involving other people. This can be as simple as getting up and moving an obstacle impairing vision, or as nuanced as running interviews and workshops throughout an organization to gradually change a cultural obstacle.
Command and Control
Identify the obstacle and give precise instructions for its removal to a person who will directly perform the removal. This can sometimes work if removing an obstacle takes a great deal of time, effort or specialized skills that you yourself do not posess. However, the overall approach of "command and control" is not recommended for Agile environments since it is disempowering.
Influence
Identify the obstacle and suggest means to deal with it to a person who has the authority or influence to get others to deal with it. This indirect method of obstacle removal can be slow and frustrating. However it usually has better long-term effects than command and control.
Support
Offer to assist and encourage the removal of obstacles that have been identified by other people. In many respects this is a very effective method. It can assist with team-building and learning by example. People are usually grateful for assistance.
Coaching
Train others on the art of obstacle removal including obstacle identification, types of obstacles and strategies for dealing with obstacles. Observe people's attempts to remove obstacles and give them feedback on their actions.
Creating a Culture of Obstacle Removal
Encourage and measure obstacle removal at all organizational levels until it becomes habitual. In many ways this is the essense of the lean organization.
Strategies for Dealing with Obstacles
Diagrams are a great way of communicating the essense of a concept. Feel free to share the following diagrams with anyone (but of course keep the copyright notice on them).
Remove
Remove the obstacle altogether. This method of dealing with an obstacle is usually the most immediately effective, but is also one of the most difficult methods.
The best way to actually remove an obstacle is to get at the root cause of the obstacle and change that. This type of change results in the longest-lasting and most stable elimination of an obstacle.
Move Aside
Take the obstacle and put it in a place or situation where it is no longer in the path of the team.
In a team's physical environment, this may be as simple as changing the tools that the team is using. For example, if the team is all in a room together, move computer monitors that are blocking team member's views of each other. If there is a useless checkpoint that work results have to go through, get management to eliminate it.
Shield
Build a shield or barrier to hide the obstacle so that it's effects no longer touch your team.
If a team is distracted by noisy neighbors, put up a sound barrier. If a team is unable to see their computers due to late afternoon sunlight, put up window shades. If a manager is bothering the team with meetings or tasks unrelated to the work of the team, then put yourself between the team and the manager (or get someone in upper management to do that).
Shielding is excellent for immediate relief, but remember that the obstacle is still there and may become a problem again if the shield cannot be maintained.
Transform
Change the structure or form of the obstacle so that it no longer affects effectiveness.
In general, this method requires a great deal of creativity and open-mindedness. This is one that works particularly well on people who are obstacles: convert them into friends of the team!
For example if the team needs approval of an expert who is not part of the team, this can cause extra work preparing documentation for this person and long delays while the expert revies the documents. If the expert becomes part of the team, then they are well-informed of the work being done and can give approval with very little overhead.
If done well, this can be a very long-lasting method of dealing with an obstacle. Make sure that the transformation is true and that it takes hold... and beware that the obstacle doesn't revert back to its old nature.
Counteract
Find an activity that negates the effects of the obstacle by boosting effectiveness in another area.
As a coach or Process Facilitator, this is what we spend our time in early in a team's adoption of Agile Work: we get them to work in the same room, use iterations and adaptive planning, we focus them on delivering work valued by the stakeholders as defined by the Product Owner. All these things are enhancing the team's ability to get work done without actually directly dealing with any obstacles.
Watch out for barriers avoided this way to come back and bite you later on.
Removing Obstacles and Learning
Organizational learning, as well as adult learning have a strong relationship to obstacle removal. Organizational learning can be either single-loop or double-loop learning. Adult learning can be either normal or transformative. We can approach obstacle removal from a surface level where we only deal with the immediate symptom, or we can work at a deeper level where we deal with the symptom and its chain of preceding causes. One effective method for examining the deeper causes is the 5-why's exercise.
Obstacles Inherent in Agile
Agile methods do not perfectly eliminate all obstacles. Some obstacles that are inherent in agile methods include overhead due to planning meetings at the start of iterations, the use of a dedicated process facilitator. As well, the use of iterations can become a barrier to certain types of work items: repeating items, investment in infrastructure, one-off tasks that are not directly related to the work at hand.
At some point, our teams will have matured to the point where agile methods are no longer necessary and we can pick and choose what parts of agile we use.
Go Forth and Demolish Obstacles!
As a Process Facilitator, coach, ScrumMaster, manager, change agent or stealth agile advocate, you have the ability and the knowledge to make a big difference in people's lives and in the success of the organizations they work within. Removing obstacles is one of the most important duties you have.
Do you have stories about obstacles you have removed or seen removed that have made a big difference? We would love the hear the anecdotal side of this as well!
Posted by Mishkin Berteig at 01:10 PM | |
March 09, 2006
Facilitation Primer
Another good reference and learning tool: a basic primer on meeting facilitation. It's a PDF linked off the page (I didn't link directly to the PDF). I've read through this and I strongly recommend it if you haven't already seen it! If you are working in Agile methods, this is essential basic material.
Posted by Mishkin Berteig at 03:49 PM | |
Good Blurb on Command and Control
My friend and co-worker Deborah Hartmann has a blog entry that I think is very insightful. The article is called: Hardwired for Command and Control? To me, the most important part of her article is this one sentance:
The shift to Agile values and practices is difficult - for many, it's a significant culture change. And with change comes stress, and with stress... fear and the urge to control.
Posted by Mishkin Berteig at 03:27 PM | |
February 23, 2006
Interation Retrospective Patterns
William Wake has posted a fantastic overview of patterns used in Iteration Retrospectives. I've added this (and a few other things) to the Agile Advice Recommended Materials page.
Posted by Mishkin Berteig at 06:51 PM | |
January 08, 2006
New Carnival of the Agilists
The latest Carnival of the Agilists has two references beck to Agile Advice... and of course lots of other great reading. Have fun!
Posted by Mishkin Berteig at 10:49 AM | |
December 12, 2005
Agile Advice Recommended Materials - Updated
Over the last two weeks there have been about 15 new links added to this list. Lots of great stuff about agile and related topics such as lean, management, learning, etc. Have fun! Please see Agile Advice Recommended Materials
Posted by Mishkin Berteig at 07:30 PM | |
December 02, 2005
New Carnival of the Agilists
Carnival of the Agilists is a great weekly listing of links related to Agile. Have fun!
Posted by Mishkin Berteig at 03:11 PM | |
November 28, 2005
Agile Advice Recommended Materials
This page contains a number of links to recommended web sites, books or tools relating to Agile Work. This page will be updated from time-to-time and as this is done, announcements will be posted on the Agile Advice blog. As such, this page will always be "under construction". If you have links to suggest, I will examine them and put them up in my own time. Please feel free to email suggestions to topics@agileadvice.com.
Update 20070115: 1 new reference!
Introductory Material:
Agile Axioms
Agile Manifesto
Agile Work Cheat Sheets and White Papers - Berteig Consulting Inc. [pdf]
Agile Software Focus:
Extreme Programming
Methods and Tools
A Scrum Primer - Report from Yahoo! [PDF]
Control Chaos - Ken Schwaber and The Scrum Methodology
Agile Software Development by Alistair Cockburn
Agile vs. Lean - Thad Scheer
No Silver Bullet by Frederick Brooks
Agile Planet - agile blog aggregator
Buildix - agile software dev tools on a CD
Agile Forums
Implementing Scrum
Project Management:
Project Management Institute
Agile Project Management Yahoo! Group
Burndown and Burnup Charts
Huge List of Software Project Management resources
Scrum Alliance - Agile Project Management and Training
Project Management Resources - by Michael Greer. I don't agree with everything on this site, but if you are looking for traditional PM stuff this is a good place to go.
Lean and Theory of Constraints:
Lean Software Development - Mary and Tom Poppendieck
Evolving Excellence - by Kevin Meyer, Bill Waddell, Dan Markovitz NEW!
Theory of Constraints - Eliyahu Goldratt
Agile Work for Flow Projects - Mishkin Berteig
The Toyota Production System
Practice Without Principles - TPS Without the Toyota Way - Victor Szalvay
Agile Work Uses Lean Thinking - Whitepaper [pdf] by Mishkin Berteig
Management:
Agile Management Yahoo! Group
Slow Leadership - the opposite of Agile?
Adaptive Management - Jeffrey Phillips
Adult Education:
The Self-Educative, Narrative and Metaphorical Faculties of the Soul - Alexei Berteig (pdf)
Infed
Team Building:
The Wisdom of Teams: Creating the High-Performance Organization
Retrospectives
Retrospective Patterns by William Wake
How to Win Friends & Influence People - Dale Carnegie
Community Development:
Corporate Culture:
Catastrophic Organizational Change - Tobias Mayer
The Corporate Culture Survival Guide - Edgar H. Schein
Good to Great (fastcompany article) - Jim Collins
Agile Services:
Berteig Consulting - Agile Work Coaching, Training and Consulting
CC Pace
Digital Focus
Israfil Consulting Services Corporation
Scrum Alliance
Tobias Mayer
David Chilcott
Joe Little
Michael Vizdos
Agile in Other Domains:
Extreme Project Management for Architects
Experiences and Stories of Applying Agile in Other Domains:
Agile Documentary Video Project
Agile Publishing
The following sections of material are based on the Agile Work Cheat Sheet.
We are Creators
Reality is Perceived
An Introduction to General Systems Thinking
Change is Natural
About "Resistance" by Dale H. Emery
Trust is the Foundation
Agile or Not Agile?
Trust and Small Groups
Empower the Team
Launching an Agile Team - A Manager's Howto Guide
Amplify Learning
Abe Lincoln’s Productivity Secret - a nice little bit about being properly prepared (although caution should be taken not to over-prepare!)
Eliminate Waste
Self-Organizing Team
Variations on the Daily Standup - Rachel Davies
Scrum from Hell - William Wake
Team Formation Stages - Forming Storming Norming Performing
Iterative Delivery
Are Iterations Hazardous to Your Project? - Alistair Cockburn
Adaptive Planning
Maximize Communication
Edward Tufte's web site with lots of great info about the visual display of information
Human Tools for effective communication
Eight Barriers to Effective Listening
Facilitation Skills [pdf]
Test-Driven Work
The Qualities of an Ideal Test
Appropriate Metrics
Appropriate Agile Measurement White Paper (pdf)
Removing Obstacles
Intros and Summaries
The Seven Core Practices of Agile Work
Posted by Mishkin Berteig at 02:02 PM
|
|
Alistair Cockburn has written a very important article called "Are Iterations Hazardous to Your Project?". Alistair has some of the most clear thinking I have encountered in the agile community. His book "Agile Software Development
Posted by Mishkin Berteig at 10:08 AM
|
|
John Brothers is hosting the Carnival of the Agilists. There are some very interesting news items and views - please check it out and spread the word.
Posted by Mishkin Berteig at 12:10 PM
|
|
This time Pete Behrens is hosting the Carnival of the Agilists. There are some very interesting news items and views - please check it out and spread the word.
Posted by Mishkin Berteig at 07:28 AM
|
|
A review of Tara J. Fenwick's “Limits of the Learning Organization: A Critical Look” (article found in Learning for life: Canadian readings in adult education This article is a critique of learning organization literature (as presented in the works of Peters, Senge, Watkins, Marsick, Argyris, Schon and others). I chose to do a review of it because learning organization literature can and does inform the work of Agile practitioners. The writer, Tara Fenwick, offers a critique of this literature as an academic and practitioner in the field of adult education. Even though the language and tone of the article is judgmental and at times affronting to the corporate trainer audience, it is never-the-less challenging and valuable because she raises interesting ethical questions that can serve as cautions against potential trends that can distort agile practice. I will summarize her argument in the some of the areas most relevant to Agile practice. Fenwick's summary of the model of learning organization found in the literature, is an organization that: “creates continuous learning opportunities, promotes inquiry and dialog, encourages collaboration and team learning, establishes systems to capture and share learning, empowers people toward collective vision and connects the organization to its environment.” The following is a summary list of some of Fenwick's critiques: Who's Interests are Served How Learning is Defined Assumptions about Learners Diversity and Privilege Overlooked Fenwick sheds a clear light on where the good philosophies of the learning organization are found wanting. The Agile community can benefit from asking some of the same ethical questions she asks in relation to our work. Her critique is a good challenge for Agile practitioners. It challenges us to: Reflecting on these issues will go a long way to contributing to the development of agile practice. The full text of an old version of Fenwick's article can be found here.
Posted by Shabnam Tashakour at 09:35 PM
|
|
A good place to check out agile-related blog posts: http://www.undefined.com/ia/archives/2005/09/carnival_of_the_3.html
Posted by Mishkin Berteig at 11:49 PM
|
|
It seems to me that most people who have had any kind of success on serious projects, or in life, can probably point to a profound collaborative experience at the core of that experience. In my last posting, "tools vs. capabilities" I said that because Agile is fundamentally a process of collaboration and our culture is fundamentally is a culture of contest, we need to recognize that learning Agile requires a transformation at the level of character more than methodology. Despite the fact that we may have had profound experiences with collaboration, because we are also deeply influenced by our environment, there are limits to what we can understand about it. We need not look further than the agile disciplines to see how most of our working and social practices are not supportive of Agile perspectives. For example empowering the team and the concept of self-organizing team is a direct challenge to most of our social, economic, cultural, community and familial structures which are essentially hierarchical. The discipline of amplifying learning is a direct challenge to the practice of excessive specialization which manifests itself in the form of expert elitism. How can any one of us ever hope to have a culture of learning and innovation if we come from a culture of expertise and hierarchy based on that expertise? This is where transformative learning comes in. Agile requires of us not just an ordinary, but transformative learning experience. When we learn, we take something new and fit it into an old category or assign an old meaning to it. Categories are ways in which we organize our learning, they can also be called frames of reference. If we encounter an experience for which we have no category it is hard to understand it. For example have you ever been in a conversation or taken part in a course where what you were learning was so foreign to you that you didn't even know what kinds of questions to ask to help you understand it? Our frames of reference are shaped through the influence of our culture, language, and experiences, which all interact to set boundaries to future learning. This is because outside of these categories it is impossible for us even to register something new, let alone seek out its reality in an unprejudiced manner. How often do you find yourself in a new learning situation where you feel overwhelmed, frustrated or even angry? It is possible that at those times you may be at the threshold of a transformative learning experience. You can have two reactions: one would be to dig deep and try to figure out why you are disturbed and see what insights you are led to and the other would be to just give up on the idea and find arguments against it. Another way to recognize a potential opportunity for tranformative learning is to reflect on the following question: have you ever had an experience where you were faced with some new learning and because you have had a similar experience or because for some reason you see yourself as an expert in that field you have not been able to derive the proper learning from that experience? You may have realized this at a later time after numerous interactions with a similar experience where you slowly started to recognize gaps in your own understanding. In order to derive the full benefit of a new experience that doesn't fit into the realm of our experience we must have a transformative learning experience. A transformative learning experience is an experience that requires of us to examine the values and limitations of our old categories and assign new meanings to them. This does not mean that all of our previous learning is invalid. A transformative learning experience allows us to expand our frames of reference to allow for more complexity and at times possibly to integrate two previously perceived dichotomous approaches. For a detailed introduction to transformative learning theories, its thinkers and history check out this link:
Posted by Shabnam Tashakour at 10:50 PM
|
|
It has a permanent place over on the right just below the list of Agile Work Axioms. You can also go here to download it.
Posted by Mishkin Berteig at 09:30 AM
|
|
I highly recommend this article on Collaboration Rules. Great stuff in there about developing teams, developing organizations and how important communication and trust are to doing so. The article draws examples from and compares the open-source development and maintenance of the Linux kernal and the operation of the Toyota Production System.
Posted by Mishkin Berteig at 10:48 PM
|
|
Agile Work is a system that can be created inside many types of organizations and work environments. I recently came across an interesting article about the viability of systems. The article describes an interesting recursive breakdown of systems into sub-systems of specific types. Over the course of the next few weeks, I will use this model to try to analyze Agile Work to see if it is viable.
Posted by Mishkin Berteig at 08:36 AM
|
|
The Transparent Society, an essay by David Brin is an excellent statement about the possibilities and challenges that technology presents to us as a society. What is interesting about this paper is that it presents a possible society that is very similar to some of the goals in establishing an agile environment: open communication, accountability, free access to information and status, and close collaboration.
Posted by Mishkin Berteig at 11:58 PM
|
|
There is a fantastic article about software productivity: http://www.joelonsoftware.com/articles/HighNotes.html. I love Joel's writing style, and this article in particular has important lessons for us all, regardless of our profession: find what you can be the best at, and do that. Interestingly enough this is part of the message of the book Good to Great but applied to a whole corporation. It also applies in the context of self-organizing teams: each individual should be able to find/learn in what way they can best contribute and do that more than they do other stuff.
Posted by Mishkin Berteig at 11:41 AM
|
|
Good stuff, in particular about lean, at Reforming Project Management. Applicable to agile work in many circumstances.
Posted by Mishkin Berteig at 12:45 PM
|
|
Notes: 1. Iterative Delivery is a specific way of managing queues of work. As such, rote work is generally better served by other applications of queuing theory. 2. There is one universal condition under which iterative delivery is awkward, if not inadvisable. If one's horizon of predictability is longer than the size of a work package by some substantial amount (e.g. 2:1 ratio), it can be more natural to use queuing theory and a pull system to flow work through the team. The actual ratio between the horizon of predictability and work package size that is used to switch over to a queue system must be determined empirically in your own circumstances. This empirical analysis can be done using a regular process reflection meeting.
Posted by Mishkin Berteig at 03:14 PM
|
|
From the Link: Calculating the True Price of Software by Robert Lefkowitz -- Businesses have long viewed support and maintenance as essential components of software. Open source business models often focus on charging for support and customization. Is there an economic model that can demonstrate the true worth of a piece of software and the option for support, maintenance, and upgrades? Robert Lefkowitz argues that open source exposes the true value of software itself as, essentially, worth less in comparison to support and maintenance.
Posted by Mishkin Berteig at 04:37 PM
|
|
Overview The Tipping Point: How Little Things Can Make a Big Difference is a book that is about the way ideas, things and behaviors go from obscurity to ubiquity in a very short period. The basic model is that of an epidemic in which three types of factors contribute to quick dissemination: 1) the network of people involved including "connectors", "mavens" or respected experts, and "salesmen", 2) the ability of that which is spreading to stick around, the "stickiness factor", and 3) the importance of small physical, mental and social factors, in creating a conducive environment. The Author, Malcolm Gladwell, includes some excerpts on his web site. Assessment This is a fascinating book, well written. Some of the anecdotes and "case studies" are mind-blowing. However, there is a bit of weakness in parts. In particular, the Afterword and the sections on The Power of Context are weakly put together - ideas do not flow well, or are too stream-of-consciousness. As well, the weight of evidence, while strong, is not totally convincing. That said, there are a couple of really fabulous stories. One story that stands out is the study related to the "Good Samaritan". In brief, researchers set up an experiment to test what factors influenced a person's behavior when presented with someone obviously in need of help. At a seminary, the researchers had students prepare and deliver a brief talk on some topic. One of the topics given randomly to some of the students was the story of the Good Samaritan. The students were to take a short amount of time to prepare their talk and then immediately go to another building to deliver it. Planted by the researchers along the path to the second building was an actor made up to appear in a great deal of physical distress. As each student was sent out the door, the researchers would breifly comment either that the student was running a little early, or that they were late and needed to hurry to deliver their talk. The results were astounding: of those students who were told that they were late 90% ignored the person in distress regardless of the topic of their presentation, while 63% those with a few minutes to spare stopped to help (pages 163-165). Relevance There are several ways in which this book is relevent to those of us practicing Agile Work and related methods. Most obviously, the ideas in The Tipping Point suggest some lines of action we can take to promote Agile: finding the connectors, mavens and salespeople, working to make Agile sticky, and making the environment hospitible to the spread of Agile. This applies both inside organizations and in the world at large. In my own opinion, the drafters of the Agile Software Manifesto, either by design or otherwise, came up with an incredibly sticky term: Agile. Finally, when coaching a team to adopt agile practices, it may be most important to focus on the Power of Context. Small suggestions, small physical changes, body language, all can have a large influence on the success or failure of an agile adoption. If a coach (Scrummaster/Team Lead/etc.) can find the connectors, mavens and salespeople in the sphere of influence of the team, and convince those people of the efficacy of Agile, then convincing the team will become that much easier.
Posted by Mishkin Berteig at 09:59 AM
|
|
Notes: 1. Self-Steering may be difficult to implement in some cultural circumstances. An organization that is very comfortable with a command-and-control system can benefit from self-steering teams, but the effort to shift the culture should be realistically assessed. An excellent reference for corporate culture change is "The Corporate Culture Survival Guide" by Edgar H. Schein. 2. Self-Steering in a rote work environment boils down to teams empowered to learn how to do the rote work as effectively as possible. This learning process must include the power to change the process with the goal of doing the work faster or with fewer defects. For example, in a manufacturing environment, this means people being able to identify problems and make improvements to the manufacturing process. In a rote work environment, not all changes the team makes will be improvements, but they must be accepted. A mechanism for measuring the result of changes must be in place so that the team can assess the effect of their changes, and make corrections as appropriate.
Posted by Mishkin Berteig at 06:38 PM
|
|
Esther Derby wrote about a great, incredibly obvious, but sometimes missed never-the-less, intervention for helping teams make a decision: write the options down (20050724: corrected link).
Posted by Mishkin Berteig at 02:42 PM
|
|
In an agile environment, all work done needs to be directly related to the needs of stakeholders. Stakeholders request or “pull” work from the team, and they do this by defining prioritized work packages. The team needs some way to know when they have completed a work package, so both work packages and iteration tasks need to have testable acceptance or success criteria. The team collaborates with the stakeholders to determine what needs to be done to successfully complete a work package. Based on the acceptance criteria, tests are described or created. Ideally, these tests are created before or simultaneously to any work that is done on the work package or task. Any work done is done only to make the tests succeed – no speculative (wasteful) work should be done. The team members should carefully avoid the belief that they can predict work that needs to be done if there is no test for that work. Tests can be informal, formal or even automated depending on the environment and the type of work being done. Tests can be questions or measurements and their expected results. A test can also be a procedure to follow and the results of that procedure. If the environment supports it, automating tests can be an excellent investment for reducing waste. In an ideal environment and work domain, tests can fullfil all the attributes of an ideal test. Test driven work has two solid benefits: it helps ensure close collaboration between the team and the stakeholders, and it helps eliminate the waste of unnecessary work. Thus it supports the three agile work disciplines of Empower the Team, Amplify Learning and Eliminate Waste. In software development, where Test-Driven Work is very sophisticated, there are a number of excellent testing tools and resources.
Posted by Mishkin Berteig at 06:01 PM
|
|
I heard a story about a situation where someone was refused career advancement because she had made an enemy a long time ago. It made me think. Why do we make enemies? Is it because we don't really know how to make friends? In Agile Work, where communication, collaboration, teamwork and truthfulness are so important, making enemies is the worst thing a person can do. (It might not be such a big problem in mechanistic environments.) The golden rule is a good starting place for learning how to make friends. Esther derby has a great course on teamwork that could help. An of course there's the old classic: How to Win Friends & Influence People which really is very good (if a little dated). If anyone knows some other good books or resources about learning to make friends, please reply in the comments!
Posted by Mishkin Berteig at 03:26 PM
|
|
These six qualities of tests describe how to make a test as effective and as useful as possible. The qualities are similar in style to the INVEST qualities of user stories - but they don't form a nice acronym. Decisive: The test contains all the information required to automatically determine success or failure. Manual inspection of test results is not necessary to determine success or failure. The test is expressed in a way that produces a pass/fail answer rather than a numerical or qualitative result. Decisive tests are often expressed as assertions. Valid: The test produces a result that matches the intention for the work artifact under test. Test failure indicates failure in the artifact under test and test success indicates correct operation or configuration of the artifact under test. Simply put: the result of a test should be true. Complete: The test contains all the information it needs to run correctly with a given test harness and work artifact under test. The test performs all activities and provides all the data necessary. The test does not require any input outside of itself in order to run. Repeatable: The test always gives the same results if the test harness and the artifact under test are the same. The test is created in such a way that the result is deterministic. Even if the system under test is not deterministic, the test should be created to account for that (possibly with statistical analysis) and produce a deterministic result. Isolated: The test result is not affected by other tests run before it nor does a test affect the results of tests run after it. The test and the test harness work together to clean up after every test is run. A collection of tests can be run in any order and always produce the same results. Any test that depends upon the results or side-effects of a previous test is not isolated. Automated: The test requires only a start signal in order to run to completion in a finite amount of time. No manual intervention is required after the test is started. Tests that are automated can be put together into a test suite and run one after another without human intervention. Automation of tests requires the creation of a test harness system. Update 20060106 I've added a little bit more detail to the above qualities. I also wanted to say a few words about my experience with testing: I first started doing test-driven development almost seven years ago after reading the book Refactoring by Martin Fowler. I picked it up in Windsor Ontario while I was driving to San Francisco for my first contract position as an independent. I had to stay the night there due to the immigration office being closed so I read a lot of the book in my motel room that night. By time I got to California four days later, I was totally convinced that I should be using JUnit and refactoring for everything I did. Fortunately my project was ammenable to this approach. Over the next four months I built a Java JMS layer on top of Tibco Rendezvous. In the process I discovered methods for doing unit tests for asynchronous multi-threaded distributed functionality. And my tests satisfied all the above qualities. I delivered code with 100% test coverage and zero defects discovered until more than two years later when a very rare and obscure deadlock issue was found. Suffice it to say, I was convinced from a quality perspective. But there is more. To build tests that follow all the above qualities, you need code that is testable. I have come to believe that testability is the most important architectural attribute of code for most software. The implications of having testable code include code that is easily changed, that is verifiable, and that is easy to understand. Refactoring plays a big role here too. For getting a basic but very practical sense of test driven development, I strongly recomment Test Driven Development: By Example I have also written a couple of articles recently about quality: Quality is Not Negotiable in which I talk about how to handle defects - by always treating them as top priority work items. and Technical Debt in which I expand on this common analogy between lack of testing and debt to show that technical debt is even worse than financial debt.
Posted by Mishkin Berteig at 06:48 PM
|
|
In a previous entry about constant change, the idea of a horizon of predictability was introduced. This concept, along with the agile discipline of amplifying learning, suggest a strategy for addressing problems in a project. Shorten the length of the iterations you are using. Contract your "planning horizon". The length of your iterations should be motivated by the horizon of predictability for your environment. If your project encounters trouble, particularly of the sort where it looks like you might not accomplish your commitments for an iteration, then shortening the length of iterations will enable you to resolve your problems. First off, by shortening your iteration length, your opportunities for learning become more frequent. Secondly, a contracted planning horizon will put you more firmly inside the horizon of predictability... and therefore there will be fewer unexpected changes (on the whole, not in any specific iteration). A related article is The Pros and Cons of Short Iterations.
Posted by Mishkin Berteig at 06:34 PM
|
|
Just a link to the Self Organizing System FAQ - glanced through it, it looks amazing.
Posted by Mishkin Berteig at 10:29 PM
|
|
Lean Metrics... are Lean Conclusions for Scrum and Agile in General Don't prescribe specific metrics! Agile work is about an empirical process where a team responds to change, learns, and self-regulates. An agile team has the power to choose their own metrics for their own self-inspection. For upper management, the single economic driver that is part of the "Good to Great" process should be sufficient. See also: Appropriate Metrics and A Metric Leading to Success.
Posted by Mishkin Berteig at 07:14 PM
|
|
Empowerment is the ability of a team to make decisions about how to do their work and execute on those decisions without outside interference. If a team is empowered, then it will be more capable of responding to change, and it will be able to focus on manifesting the members' creative potential. Empowerment comes from a combination of several factors: 1. members of the team have a deep sense of self-worth that includes nobility, and contribution to the progress of humanity 2. tacit or explicit authority and responsibility for results as a team and as individuals 3. a team environment which is honest, trusting and allows for mistakes 4. the absence of personal attacks against individuals on the team and in particular a total lack of gossip and backbiting There are several ways that team members will demonstrate their empowerment. People will derive joy from their work. Team members will be dedicated to the work and the team. Individuals on the team will frequently take individual initiative to accomplish tasks, share insights, and develop improvements. Spontaneous leadership will become common. Individuals will step out of comfort zones or areas of specialization in order to assist the team. Empowering a team is a process that can sometimes take a great deal of time and effort. In order to start on this process, the team members should carefully listen to each other and ask many questions. More mature individuals should lead and teach by example. And all the team members can start to question and challenge the rules and procedures of an environment that are preventing effective work. If the team is in an organizational environment where team members have management to report to, then management must be aware of this opportunity for empowerment and support it. An empowered team can gradually understand and internalize the agile work principles (People are Creators, Change is Constant, Perception mediates Reality). By internalizing these principles, a team can move beyond specific agile work practices and become a high performing team setting their own work practices. Jeff Sutherland has a very brief blurb about the progress of teams as they evolve in their use of Scrum. Future entries here will discuss the methods of creating empowered teams.
Posted by Mishkin Berteig at 11:04 PM
|
|
As part of the Advanced Scrum Training, Esther Derby presents a section on conflict. One very insightful part of the presentation is a description of four reasons for the existance of conflict or disagreement. They are as follows (adapted from "Advanced Scrum: Collaboration Skills for Scrum Teams" (c)2004-2005 Esther Derby): 1. Lack of Clarity - the communication between parties is missing information or the information is not being communicated in a consistant manner. 2. Position Focus - the parties involved have already each decided on their own solution and are failing to discuss the problem those solutions are addressing. 3. Different Values - the parties are unable to agree because they are holding different sets of values but not articulating those values as part of the discussion. 4. Past History/Personalities - the parties have a previous unresolved conflict that is negatively affecting their ability to work together. All of these types of conflict are based on either conscious or unconscious failure to be truthful... and therefore the different parties have incompatible perceptions of reality. The Agile Work axiom "Reality is Perceived" then gives us a hint as to how to resolve all of these types of conflict. Find a way to share perception among the parties in conflict so that they have a compatible view of reality.
Posted by Mishkin Berteig at 10:52 PM
|
|
| TrackBack
Kent Beck's book "Extreme Programming Explained : Embrace Change" provides a good introduction to how software development can embrace the constant change that affects our world. Some of the practices he introduces are very software-specific. However, the overall basic message is sound and provides a foundational principle for all agile work. (By the way, the book is excellent.) Change really does occur everywhere. Change is constant. A google search for "embrace change" or "change is constant" will both turn up an incredible variety of articles, papers, discussions, books and viewpoints that all affirm the constant nature of change and the need to embrace it. Nevertheless, it is sometimes difficult to accomodate change when we also have a legitimate and deep desire to know what is coming next. For many teams, the environment in which they work is constantly changing. This change can be caused by competition between organizations, scientific or technological advances, fads and cultural shifts, major events in people's personal lives or even just a change of opinion with a stakeholder. Any change, even small change, can invalidate a planned course of action. However, goals (as distinct from plans) are more stable and often survive even major environmental changes. Therefore, rather than trying to plan the future, an agile team can focus on being able to respond to change while still reaching a goal. Nevertheless, a team needs some sense of what it will do in the near future. A team can work with a “horizon of predictability”. This is the distance into the future which a team can be reasonably certain that plans will be stable. Depending on the environment, this may be as little as a few minutes, or as long as a month. It is rarely longer. The horizon of predictability is not a precise demarcation, rather, expect change with a probability based on the horizon of predictability. Then, plan to respond to change. Be detached from the concrete details of a plan, particularly if they occur outside the horizon of predictability. The terms “agility” or “agile work” refer to this principle of embracing constant change since it is the most visible of the principles. However, the ability to respond to change relies on the establishment of agile work disciplines and practices.
Posted by Mishkin Berteig at 06:57 PM
|
|
I have just run across a web site about applying agile practices, specifically from Extreme Programming (XP) to architecture. This site, called "Architectural Practices - Extreme Project Management for Architects" has a great deal of information. This site represents a set of ideas that have come full-circle. Christopher Alexander wrote a book called "A Pattern Language: Towns, Buildings, Construction (Center for Environmental Structure Series)" about a different way of looking at architecture, interior design, landscape design and city planning. This book made a big impression on some people in the software industry. In particular, it inspired the book "Design Patterns" by Erich Gamma et. al. This book became required reading in the software industry. Many participants in the Agile Software Development movement consider it foundational. And now we see agile practices being adapted back to architecture. Cool.
Posted by Mishkin Berteig at 04:15 PM
|
|
An article called Are You Ready for the Agile Future presents a brief discussion about the role of HR in an agile organization. There are several very good ideas. The basic idea is that the HR function must adapt to the nature of agility. This in turn means, for example, hiring people that are agile, nimble, adaptable etc. There are however some mis-steps in the article. One is an ommission: the HR organization must itself become agile. In one organization that I worked, it took at a minimum 4 weeks and typically 12 weeks to get a contractor onto a project. Three months lead time!!! Now admittedly, it is not easy to bring an individual on-board quickly. However, it is possible. Some organizations I have worked at have lead times for getting new people into the organization that are on the order of 2 weeks including search, selection, administration and orientation. In these organizations, the HR organization maintains an attitude to their own work as service to the larger organzation... and the faster the service (without sacrificing quality), the better. The article also misses the mark on employee performance. Employees should be measured on their sphere of influence, not their sphere of responsibility. In other words, if a person is a member of a team, their own performance should be judged by the performance of the team as a whole. This mitigates people's competitive habits and positively reinforces collaboration. People should not be measured against their role discription. One of the recommendations in the article is to "Create selection, testing and hiring criteria that identify diverse, resilient, nimble people." Unfortunately, there is no guidance on how to do this. Here are some ideas: look for people who have moved between projects, roles, employers and even locations frequently, look for people whose resumes contain lots of work that doesn't fit their job titles, look for people who have hobbies and interests that are outside their field of specialization, look for people who have diverse volunteer experience, look for people who ask lots of questions. (Thanks to Deb Hartmann for the link.)
Posted by Mishkin Berteig at 09:48 PM
|
|
Two interesting visual presentations of the progress of adoption of Scrum practices. These are marginally software-specific but could very easily be adapted to non-software agile work situations. http://wiki.scrums.org/index.cgi?ScrumScoreboard
Posted by Mishkin Berteig at 04:31 PM
|
|
The online CIO Insight has a great article/interview about a forthcoming book: "The World Is Flat: A Brief History of the Twenty-First Century". Choice quote:
November 25, 2005
Iterations Stories and Velocity
November 04, 2005
Carnival of the Agilists for 2005/11/03
October 14, 2005
Carnival of the Agilists for 2005/10/13
October 10, 2005
Agile, the Adult Educator and Ethical Considerations
Although the learning organization literature holds great promise for a more humanitarian and egalitarian workplace, it has the potential to distort learning “into a tool for competitive advantage” and in turn, exploit people as resources in the pursuit of profit. To explore this idea she asks a valuable question: “Who's interests are being served by the concept of learning organization, and what relations of power does it help to secure?” She argues that learning organization literature tends to serve the interests of educators working as trainers in organizations and managers interested in their own self preservation.
Learning, in learning organization literature seems to be defined as that which benefits the organization, all other learning falls into the dysfunctional category. This perspective negates other ways that people create meaning and learn and potentially causes a person to become “alienated from their own meaning and block flourishing of this learning into something to benefit the community.”
The learning organization literature subordinates employees by seeing them as “undifferentiated learners-in-deficit”. Educators and managers are the architects of the learning organization while employees are busy “learning more, learning better and faster” trying to correct their knowledge deficit. In the learning organization workers become responsible for the health of the organization without the authority to determine alternative ways to reach that health. The fear of being left behind in a quickly changing market environment is used to create anxiety and fear as motivations for learning. All of these factors serve to put serious limits on the potential of people to learn in the work environment.
Perspectives of race, class and gender -which research has shown affects the way people learn and collaborate- are lacking in the literature. Fenwick challenges the notion of achieving a democratically ideal situation for open dialog -that the learning organization literature calls for- when all people in the work place do not “have equal opportunity to participate, reflect, and refute one another” (for example because of the status of ones job, character, gender, class, age etc.) September 29, 2005
Carnival of the Agilists
Transformative Learning and Agile
http://en.wikipedia.org/wiki/Transformative_learning on Wikipedia.August 23, 2005
Agile Work Cheat Sheet Published
August 18, 2005
Harvard Business Review Article
August 17, 2005
The Viable Systems Model
August 09, 2005
The Transparent Society
August 04, 2005
Just In Case You Haven't Seen It Yet
July 31, 2005
Another Excellent Blog: Reforming Project Management
July 25, 2005
Applicability Matrix Tool for Iterative Delivery
July 23, 2005
The True Cost of Software
Book Review - "The Tipping Point"
July 22, 2005
Applicability Matrix Tool for Self-Steering Team
July 17, 2005
A Nice Little Intervention
May 19, 2005
Test-Driven Work
May 18, 2005
Making Friends Sure Beats Making Enemies
May 17, 2005
The Qualities of an Ideal Test
May 15, 2005
What To Do With the Horizon of Predictability
May 13, 2005
Self Organizing Systems FAQ
May 12, 2005
Appropriate Metrics - Continued
In the book Lean Software Development by Mary and Tom Poppendieck, there are a small number of references to metrics: process cycle time, process cycle efficiency, business models. Lean practices focus very much on diagnostic metrics that are used to help people find and eliminate waste and improve value and quality. The other aspect of metrics is to measure up for purposes of motivation and performance measurement.May 10, 2005
Empower the Team
May 09, 2005
Reasons for Conflict or Disagreement
May 05, 2005
Change is Natural - "Embrace Change"
Responding to change requires a major mental shift for many people that is difficult and takes time and environmental support. People are often penalized socially or formally for being flexible or adaptable. This quality can appear to be “wishy-washy”, uncertain, indecisive, uncommitted or even rebellious.May 04, 2005
Agile Practices Applied to Architecture
April 24, 2005
Agile HR - Sort Of
April 20, 2005
Scrum Scorecards - Measurements to See Progress of Agile Adoption
April 09, 2005
Article on CIO Insight
What I am trying to do is say that something important really is happening. The value-creation model is moving away from a vertical silo model to an increasingly collaborative horizontal model, from command and control to collaborate and connect, and that's going to change everything.
This comment alone is a fairly close hit at the essense of Agile Work. The rest of the article is very interesting and touches on many topics of interest relating to globalization, business, information technology, outsourcing and politics.
There is an interesting article at The Economist also about this book. It is very critical.
Posted by Mishkin Berteig at 11:49 PM | |