« December 2005 | Main | February 2006 »
January 27, 2006
People vs. Process
One of my favorite little management blurbs, seen on the door of an SVP at a major financial services company: "Processes don't write software, people do!" And of course, the Agile Manifesto states: "... we have come to value: Individuals and Interactions over Processes and Tools..." Here's an interesting little writeup about people and process. My own take is quite similar: a process can be more or less helpful, but only if people are willing to learn and change can true progress be made.
Posted by Mishkin Berteig at 07:54 AM | |
January 25, 2006
The Pros and Cons of Short Iterations
My first experience with any process that was similar to an Agile approach was in a startup ten years ago. We did 3-day-long iterations on a software project with a three person development team. That experience, followed by its antithesis, shaped the rest of my life. And yet, short iterations aren't always the best way to go.
A short iteration length for a given type of work will depend on the horizon of predictability for that work. In software development, anything five working days or less could be considered short. In daily newspaper publishing, fifteen minutes or less could be considered short. As a rule of thumb, "short" simply means that it is possible to fit two or more iterations in the length of the horizon of predictability.
Pros of Short Iterations
- deliver work fast: the first potentially shippable features are available after only a very small amount of time
- people keep focused on the goal(s) for the iteration; there is no chance to get distracted
- very tight learning feedback loop allows for quick discovery of optimal solutions
Cons of Short Iterations
- intensity of work can lead to burnout
- strategic thinking can be hard to fit into the "schedule"
- overhead tasks that must be done every iteration take a larger proportion of the time in the iteration
- waiting for resources or people outside of the team can make it more likely for work to span iterations
Guidelines: Choosing Iteration Length
1. Start by understanding the horizon of predictability in your environment. This is the maximum length for your iterations. In most IT organizations, this is somewhere around four weeks, whereas in web environments, it is usually much shorter.
2. Consider your constraints for delivering potentially shippable work units. Also consider the team size and the communication overhead that results. These two factors can guide you to determine a minimum iteration length. Identifiable overhead should not account for more than 25% of your time.
3. At the start of a work effort with a team new to Agile Work, consider erring towards shorter iterations. Shorter iterations can shock people into discarding bad habits by changing people's mental model of how to work effectively. Teams with successful agile experience may consider longer iterations.
4. Consider your ability to automate overhead work tasks and testing tasks. If you can develop a highly automated environment, shorter iterations are possible. If on the other hand, manual efforts will be required (no pun intended), consider a longer iteration length.
5. Consider the overall amount of schedule/funding. For a team to learn the domain and stabilize their velocity, consider trying to fit eight or more iterations into the overall schedule. The first three our four iterations include a lot of learning about the team, the process and the domain.
Some people recommend other methods of choosing the length of your iterations: How Long is a Timebox.
What We Did Way Back When...
The three day iteration length was largely determined by how frequently the sales folks could bring in potential customers for a demo. Every time we demoed, we were using working software. We would do a fairly complete walkthrough of the software and gather feedback. We would balance the feedback with outstanding features and make a call about what to add/change over the course of the next iteration. This constant involvement of customers and the requirement to have always-working software set my expectations for software development in a way that my experience up to that point had not even hinted at. When I went to my next job (which was at Sun Microsystems), I was appalled by the long cycle time to produce working software and the almost complete lack of customer involvement in the process. I vowed never to work that way again...
... and became a consultant and an agilist :-)
Posted by Mishkin Berteig at 01:39 AM | |
January 11, 2006
The One True Metric
Agile Work requires that we align our perception of reality in order to understand each other and do work that is considered valuable by everyone. One very blunt and seemingly simple way to do this is with metrics. But metrics need to be in context and that is the part that is hard to get right. Does your organization get it right?
Having a Goal
The point of Agile Work is to get stuff done. Sound simple? It is, but it requires that you actually have a goal. Ideally a single goal. That goal forms the basis for your work and is the target towards which you drive yourself and your organization. For most corporations, that goal is related to either revenue, profit or market share. For most non-profit organizations, that goal is related to helping some group. For communities, the goal is usually related to growth or relationships. For individuals... well, it really depends on you.
There has been much written about goal setting. Here are a few quick interesting links:
The Goal
Be Excellent: Goal Setting Study from 2005
Success Through Goal-Setting
Built to Last : Successful Habits of Visionary Companies
If you are working with many people in a team, an organization or a community, goal setting is a bit more complicated. There are many techniques for finding goals, gaining consensus and acting upon those goals. Brainstorming methods, doing off-sites, getting business or strategic coaching, and using various decision-making processes will all help.
Improve Against Your Goal
Once you have a goal, the next obvious thing to do is to start to move towards it. That motion must be planned and there are many ways to do this. In Agile Work methods, adaptive planning is the method most commonly used. If your goal is farther than your horizon of predictability, or if your goal somehow represents a moving target, then adaptive planning is a necessity. The specific steps you take towards your goal create an opportunity to inspect and adapt. In order to inspect your progress towards your goal, you need some way of measuring where you are and where your goal is.
One True Metric
Since your single goal is your most important destination, and since all your work should be to get towards that goal, you should only have one thing to measure. At this point, it helps to give a couple of examples.
If my goal is to drive from Toronto to San Francisco, all I really care about is estimated time to arrival. This allows me to call my friends and say things like: "Hi Jesse, I'm going to be in San Francisco at about 3pm tomorrow." I can find a value for estimated time to arrival if I can estimate my speed, my current road distance from San Francisco, and how much time I will take stopped for breaks. This single value is all I really care about.
For a large commercial organization, finding the single measurement, the One True Metric, can be more complex. Profit is not always the best measurement, all by itself. Usually, a better metric is profit per something. In Good to Great: Why Some Companies Make the Leap... and Others Don't
Behavior
It is often claimed that metrics drive behavior. In reality, there are a large number of factors which drive behavior and metrics are only a small part of that environment. Nevertheless, if you are missing good metrics, your chances of having desirable behavior are lower.
The One True Metric, by being single, simple and universal to your organization, can have a large effect on behavior.
Once you have the One True Metric in place, then what? Well, the obvious first step is to start measuring it immediately. Each measurement of the One True Metric should be no farther from the others than your organizations Horizon of Predictability. The results of this measurement must be published far and wide in your organization to every human being who works there either management or labor, employee or contractor, full-time or part-time, day shift or night shift, on-site or off-shore. Absolutely everyone should be constantly aware of this metric.
Contextual Temporary Metrics
With everyone in the organization hyper-aware of the One True Metric, you can then begin to use contextual temporary metrics to help understand details or troubls spots. These "CTMs" are qualitatively different from your One True Metric: they are used only for a short time and only in a very limited context. Two examples of CTMs are Time to Obstacle Removal and Obstacles Removed per Iteration.
Like the above example metrics, there are three important questions that must be answered about any CTM:
- Why Use This CTM?
- When to Use This CTM?
- When to Stop Using This CTM?
Every contextual temporary metric must be aligned with the One True Metric so that a good result with the CTM will not cause a bad result for the One True Metric. It is critical to understand that good results with CTMs don't guarantee good results with the One True Metric. All CTMs can be gamed; people can produce good results against the metric while doing something that isn't really valuable or is possibly harmful.
At some organizations, people are measured by how busy they are: their utilization levels. There are many reasons this is a bad idea, and here is one story of the consequences.
An organization I worked at decided that the larger the percentage of time that people worked, the more cost effective the organization would become. Labor was a primary cost for this organization. In order to make this idea stick, people were punished and rewarded based on their utilization rates. If you were 50% utilized, you were out the door, and if you were 100% utilized, you were lauded. But management noticed three problems:
1) it started to take a really long time to get projects done
2) people were working on several projects simultaneously
3) it was very hard to find people available for new projects
Further digging revealed that people were making up projects to fill in their time! Measuring utilization had turned into a disaster.
The improper use of metrics can cause no end of subtle problems. By using proper goal setting combined with the establishment of One True Metric and contextual temporary metrics, an organization can become aligned to its purpose and efficient at executing on that purpose.
See also: Appropriate Metrics.
Posted by Mishkin Berteig at 04:20 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 | |
January 05, 2006
Lovely Poem Related to Agile and Coaching
Tobias Mayer has written a brief comment about the poem "Cutting Up an Ox". I haven't encountered this poem previously so here's a "Thanks!" to Tobias. I'll also throw in my own two bits...
Another model that is expository rather than poetic is that of Shu-Ha-Ri. Here is a brief article that describes this model in terms of its original context, the martial arts.
I love that the word "agile" is so evocative of dance and martial arts. Agile is the dance of teams, the dance of organizations taken to a new level. Instead of chaos or instead of strict bureaucracy, agile provides the Shu practices to balance chaos and bureaucracy, the Ha principles to allow for variation, and the space for Ri for a team to become agile and define agile by its very behavior.
As Tobias implied, teams will learn to cut the Ox of the bureaucratic organization. But teams will also learn to turn the chaos of life into a beautiful dance.
Posted by Mishkin Berteig at 01:52 PM | |
January 04, 2006
Scrum Saves the Day For Media Student
Scrum is one of the Agile Methods that can be applied in many different fields of work. Last year, I was able to present the basic Scrum framework in a two hour session to a class of media students at Keyano College in northern Alberta. They used Scrum for their class project - a documentary video. One of the students really took to Scrum, and used it in his next class to save another group project... and get the best mark in the class! Full story follows...
Note: names have been changed.
I just wanted to let you know how and why the scrum format was useful for me this year in New Media 1000.The largest assignment (a whopping 40% of our mark) this semester was a "Reverse Storyboard", where we took screenshots from the film "Run Lola Run", reworked them following the same compositional guidelines, and then created a narrative from our reworked screenshots. This new narrative was fleshed out, storyboarded, scheduled, and shot.
I was a team leader for a group of 4 students (myself and 3 others), and initially our group was struggling to keep focused and on track. Our storyboard was late and miniscule, and our planning was substandard. The group (myself included) was blaming this misadventure on "schedule conflicts".
I decided to implement the scrum format (at least in part) to keep our group on the right course. Despite all of the students in the group having different schedules, a 10 minute meeting was manageable every day. Our group sat down, discussed, and planned out a week by week (and somtimes bi-weekly) shooting schedule with iterations as key goals to achieve every week.
According to the assignment [specifications], the film was to be broken down into six sequences, together totalling around five minutes in length. We created a separate Adobe Premiere (shudder... yuck...) file for each sequence, and each student was accountable for the bulk of the hands-on editing on at least one sequence, but the planning for each sequence was covered in the scrum meetings. The remaining sequences were picked up collectively; worked on by multiple group members at a time.
I was the ScrumMaster, and would email the group the "minutes" every day after class, adding questions at the end of the email to spawn group discussion about the work.
The scrum meetings helped us keep specific goals, (our iterations) in focus, and helped us organize ourselves into units for production, i.e - Joe and myself would shoot the scenes that only involved one of us, Joe, Lara, and myself would shoot the scenes that involved two of us, etc. This worked well for filming and for production, as Nancy, our fourth member was very restricted for time and could only film for about one hour a day, three days a week.
Nancy was an interesting group member. She was very biased and uncooperative, and had no faith in the power of editing, as she had never worked on a video before (none of the group members, save myself, had). I don't want to site specific instances, but consistantly throughout the filming and editing process, she seriously hindered the group, and was a constant source of agitation for us all. Despite this frustration, the scrum meetings served to diffuse many of the issues she caused, providing a forum for group discussion and enabling us to speak our minds without sounding too aggressive or seeming to individually attack her (often counterproductive and nonsensical) ideas.
We ended up getting the best mark out of the entire class, a 29.5 out of 30.
Without the scrum format I can only imagine what kind of chaos would have ensued. Thank you Garry and Mishkin for providing me with such a useful tool for group organization.
Take Care,
Jason.
Thanks Jason (named changed) for the great story! If you are interested in learning more about Scrum and how to apply it to unusual types of work, Berteig Consulting Inc. offers public training for individuals and in-house training for teams.
Posted by Mishkin Berteig at 04:48 PM | |