« July 2006 | Main | September 2006 »
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 28, 2006
Nice Interview with Mary Poppendieck
Mary and I worked together for a short time almost two years ago now. When we worked together I was impressed by her honesty, insight and wisdom. Here is a brief on-line interview she has done. It is focused on software development, but many of the ideas she discusses can be easily translated into other types of work.
Posted by Mishkin Berteig at 10:13 PM | |
August 27, 2006
Oops! Servers down over the weekend!
Sorry for the inconvenience, but it turns out a telephone cable was severed due to some nearby construction work. Fortunately, things are back to normal!
Posted by Mishkin Berteig at 11:35 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 24, 2006
New Schedule for Canada Agile/Scrum Courses
The fall schedule for Agile Project Management / ScrumMaster Certification courses has been posted on the Berteig Consulting web site. If you register through Agile Advice before Sept. 15th, you will receive a 15% discount on the course fee (this discount will be reflected on the course information display). The Beijing course is not available at a discounted price.
Posted by Mishkin Berteig at 08:27 PM | |
Waterfall, Lean, Agile Simulation Exercise
Last December, I wrote about a nice simulation exercise that can be done in a small group to demonstrate the difference between waterfall, lean and agile approches to work. I have now run this exercise approximately 40 times and I would like to share the results.
I should note that these results are eyeball statistics, not carefully tracked statistics.
For Round One, using a waterfall large-batch approach to processing pennies, the results are such that the first and all pennies are completed simultaneously. Typically, the processing time is as follows:
1st Done: 55-65 seconds
All Done: 55-65 seconds
Once in a while there are outliers on the long side: up to 130 seconds. This is usually caused by a team member misunderstanding the instructions or making a large error e.g. dropping all the pennies.
For Round Two, using a lean production line with small batches, the results are substantially better for all the pennies being completed, and much much better for the completion of the first penny. This corresponds to the early and continuous delivery of value that working in small batches can enable. The processing time is typically as follows:
1st Done: 4-8 seconds
All Done: 25-35 seconds
People in my courses are usually astonished by this difference. But it gets even better.
For Round Three, using an agile team working simultaneously on all stages of the penny processing, the gains continue, particularly in how quickly all the pennies are processed. These excellent processing times are as follows:
1st Done: 3-5 seconds
All Done: 15-20 seconds
Although proportionally, this isn't as big an improvement as that between rounds one and two, it is still a substantial change.
Usually in discussing this exercise, the group is concerned that processing pennies is nothing like developing software, managing a business, etc. because there is so much knowledge and skill required to do these real-world things.
Although this concern is legitimate, nevertheless, my own real-world experience confirms that these levels of improvement are possible. One large organization that I worked with has tracked many projects using waterfall, lean and agile approaches and has observed these types of improvements in terms of initial delivery of finished work, and final delivery of all scheduled work.
Posted by Mishkin Berteig at 07:11 PM | |
What's Causing All These Problems?
Yesterday, an important and interesting story passed through the scrumdevelopment yahoo group. It seems that a team was experiencing substantial pain using Scrum. This story shows an interesting and effective method of addressing that pain during a retrospective. Pete Deemer, who is Chief Product Officer of Yahoo!’s 700-person Research and Development organization based in Bangalore, India, tells the story:
I wanted to share an interesting experience I had today.I was doing a retrospective with a team that's about 2 months / 3 sprints into scrum. Coming into the retrospective the team seemed to be feeling pretty low – they had yet to hit their sprint goals, and were seeing other unpleasant things -- and comments like "IF we keep using scrum" were coming up in their conversation.
Over the first hour or so of the retrospective the team came up with two lists: "what's working" and "what's not working". The "what's not working" list wound up being about 17 items, almost twice the length of the "what's working" list. Most of the discussion centered around the things that were not working; it was an imposing list, made all the more so by the fact that it was a lot longer than the other one, and we spent most of the time talking about it. Once the lists were complete, the group spent a moment or two staring quietly at them.
Then, I tried something I hadn't done before. I suggested the team go through both lists, and mark each item as either "C" (caused by Scrum), "V" (made visible by Scrum, ie would be happening with or without Scrum), or "N" (not related to Scrum, ie the weather, etc). Then we tallied them up.
Under "what's working", the score was C=7, V=1, N=2.
Under "what's NOT working", the score was C=5, V=12, N=2.
We stared at the results for a minute. Then one of the junior members of the team volunteered, a little tentatively: "so it looks like Scrum is actually CAUSING the good stuff, but the bad stuff is mostly just things it's MAKING VISIBLE. [pause] That's exactly what we want, isn't it?". The rest of the team nodded and murmured in agreement. In an instant, the group's understanding of its situation went through what felt like a polar reversal.
It was a really wonderful moment!
For a process facilitator using any agile method, this is an important tool to be able to use. It is simple, and gets to the heart of the unspoken concern that many new teams have that agile is causing all the problems. In fact, most often, agile is simply exposing all the problems that are part of the organization, the environment, the team dynamics, the technology being used, or even the people on the team.
About Pete Deemer:
Pete Deemer is Chief Product Officer of Yahoo!’s 700-person Research and Development organization based in Bangalore, India. In this role, he oversees product development and innovation for products in both the US and Indian markets. Pete served previously as Yahoo!’s US VP of Product Development, guiding product development practices company-wide, including the adoption of Scrum. He has served in executive roles at CNET, Ziff-Davis / ZDNet, International Data Group, and was Publisher of the Let’s Go guide series. Pete has an honors degree from Harvard University, and served for a number of years served as a lecturer at the University of California – Berkeley’s Haas School of Business and UC-B’s Graduate School of Journalism, teaching classes in product development and strategy.
Posted by Mishkin Berteig at 07:36 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 | |
United Action
A few nights ago, I was having a conversation with my father, Garry Berteig, who is also an agile coach. He had an interesting insight based on a recent experience in Beijing: unity is a precondition to assistance.
In Beijing, he was helping my brother, Alexei, get ready for his upcoming wedding to a wonderful Chinese woman, Ma Jin. The three of them were out shopping. Alexei needed new furniture. As they shopped, Alexei and Ma Jin discussed the various items, their prices, qualities, etc. It took quite a while, but eventually they agreed upon a set of furniture. They became united in their understanding and perception of reality, and agreed without hesitation.
At this point, my father was able to offer his assistance to purchase the furniture as a gift for their wedding. Once Alexei and Ma Jin were united, it was possible to not just offer the assistance, but actually execute on it. If they had not come to a unity of vision, it would have been a mistake to execute on the assistance.
I believe this applies in teams and organizations. In agile environments, managers become "servant leaders". This service is only effective once the self-organizing team is united in its understanding of its needs. If the team is not united, then the service of the manager can lead to problems: some members of the team may feel discounted, some may feel (falsely) that management supports their side, and finally, management may not be able to offer whole-hearted support in the future as complaints come in.
Posted by Mishkin Berteig at 01:20 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 | |
Spots Remaining in Upcoming Agile Project Management Course
There are still spots available in this two-day course occuring on the 24th and 25th in the Toronto area. Details and registration information can be found on the Berteig Consulting Inc. agile course listings.
Posted by Mishkin Berteig at 03:53 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 21, 2006
Quality is Not Negotiable
Most of the teams and organizations I coach are working on using agile methods to improve their software development approach. Somewhere along the way, someone has realized that there must be a better way... either better than chaos, or better than bureaucracy. Over the years that I have been practicing agile methods, I have come to believe that quality is not negotiable.
The problem is this: when you have a defect in your work, you have no way of predicting how long it will take to remove the defect and remove it in such a way that it never occurs again. This is because the process of understanding a defect is unbounded: it is investigatory and exploratory and experimental. Once the defect is fully understood, the solution becomes clear and therefore estimable. Until that time, a defect represents an unknown amount of risk.
Before I started using agile methods, and in particular Test-Driven Work, I built software poorly. I delivered software which had unknown numbers of defects. I would often find myself trying to implement a feature (something of value) only to be thwarted by a defect in the software built so far. Until I could fix the defect, I was blocked from adding in the new feature.
The moment I started using Test-Driven Work to build my software, was the moment that I could start accurately predicting how long it would take me to build new features. I started delivering defect-free software. (Yes, it's possible!) I delivered a complex multi-threaded, guaranteed-delivery, message-oriented-middleware framework that went through QA and Pre-Production testing with zero defects found. It was in production for two years before an obscure multi-threaded non-critical error was found... and none after that for a few more years. This sort of level of quality should be normal, not something to brag about.
Test-Driven Work depends on a clear understanding of how to make good tests. It also depends on an extremely high level of professional discipline. And most importantly, it depends on a supportive organization and management.
Often times, management, marketing or sales will put pressure on a development organization to "just get it done", "don't worry about doing it right", etc. Unfortunately, most developers and development managers have not been instilled with a strong sense of professional ethics. Much more often than not, the response of the developers will be "yes, sir!" and then to go off and build crappy software that on the surface satisfies the pressure, but in the long term ends of sinking the organization.
How does this happen? It's simple. Every time the developers sacrifice quality for schedule/cost/features, they incur a debt. Sometimes this is called "technical debt". I like to call it lying.
Despite my preference for the more direct terminology, the term "technical debt" is a useful euphemism. As you accumulate debt, you have to make interest payments to maintain the debt. This shows up in the workarounds, the design cruft, the inelegant solutions, and ultimately in the slow down of the team in implementing new features. It is the cause of the industry's propensity to rebuild products and systems from scratch every 3 to 5 years, and occasionally it is the cause of the failure of a business.
The only way to deal with technical debt is to confront it directly. First, the development team needs to start to refuse to compromise. No new work will be done without adhering to the highest standards of quality. Secondly, the team must start to clean up the old stuff. Doing this takes, courage, time and therefore money.
While I don't recommend people lose their jobs for this, I do recommend that people look for other work if their organization is not willing to make this transition.
On a softer note, I also acknowledge that sometimes people make honest mistakes that end up introducing defects. This is fine... just make sure that as individuals and as an organization you are investing the time and effort to make sure this happens less and less frequently. Training, reading, practice, collaboration, all can help with this process. One can't go from poor quality to perfect quality instantly... it can take time to make the changes necessary.
Here's a software-specific article that articulates these ideas exceptionally clearly: Why Expensive Bugs are Cheap to Fix.
Here's a follow-up article about technical debt.
Posted by Mishkin Berteig at 03:35 PM | |
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 17, 2006
The Queue Master
Given my interest in applying agile methods outside of software new product development, I've been often uncomfortable with the term "Product Owner". My problem is two-fold: it's too specific a term (referring to product development), and it fails to denote the responsibilities except in the most generic fashion. In other words, I think that it is both too specific, and at the same time, not specific enough. Updated the Agile Work cheat sheets to reflect this new terminology.
Several weeks ago an insightful software engineer I was talking with by the name of Sin Stokic came up with a great alternative name for the role: Queue Master.
This name appeals to me by solving my two problems with the Product Owner term:
1. It is a term that is not specific to a problem domain. Agile methods can be applied to all sorts of non-product type of work including operations, services, remediation and exploration. The term "Queue Master" is generic enough to cover all these types of work.
2. It is a term that denotes the actual function that the person filling this role performs, namely, controlling the queue of work that is being fed to the performing team. Since so much of agile methods rests theoretically on queuing theory, this is an appropriate, and more specific term than "Product Owner".
Additionally, the term "master" is beneficial because it implies a great deal of control and/or expertise that is an essential aspect of this role. The Queue Master must be 1) the master who manages the behavior and properties of the queue of work (the Work Item List), and 2) have mastery of the subject matter contained in the queue of work items.
I would now re-write my previous definition of this role as follows:
The Queue Master holds the final authority for determining the value, priority and details of all work done by an Agile team by controlling the content and ordering of the Work Item List. The Queue Master 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 of the endeavor.
I have updated the Agile Work cheat sheets to reflect this new terminology.
All that said, I'm open to suggestions for even better names for this role. I also considered a number of variants such as "Queue Manager", "Queue Facilitator" and "Queue Keeper" (which has a nice alliteration, but is also a little corny). Thoughts? Reactions?
Posted by Mishkin Berteig at 12:57 PM | |
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 | |
August 13, 2006
Missing Terminology
I discovered that the agile methods that I know well (XP, Scrum, Lean) have no word or term for an important part of their process!
I'm working with an organization that is trying out 2-day long iterations (why is a whole other story). In order to track their work effectively, we are going to be doing brief status checks to update a burndown chart every hour. What is the period of time called between those status checks?
In most agile methods, that period of time is always 24 hours in duration - daily. Therefore it is easy to talk about without a special name for it...
But if the period of time between status checks is longer or shorter than a day, then it becomes more awkward to talk about it. So, I've decided to give it a name:
Work Period
The team I am working with is using a 1 hour work periods inside a 2 day iteration. They have 10 work periods each iteration.
Scrum recommends a 24 hour work period inside a 30 day Sprint.
In my training classes, I run an agile simulation with a 10 minute work period inside a 50 minute iteration.
In the last work period, I completed my two form processing tasks. Next work period I will get the database code for the report completed. I have no obstacles to report from this last work period.
I like the term "work period" because it is simple and generic. It also evokes the term "periodic" and the idea of a concentrated effort on the task at hand.
Thoughts? Any agile methods that _do_ have a term to refer to this period of time between status meetings?
Posted by Mishkin Berteig at 09:38 PM | |