« November 2005 | Main | January 2006 »
December 30, 2005
On Passion and Sustainable Pace
You love your work. You love your family. It's a difficult balancing act: which is winning at your house, these days?
Perhaps, right now, the fulcrum on this precarious teeter-totter is set for more teetering than tottering. How to move the fulcrum? Readjusting work-life balance, while desirable, may seem impossible given the projects we are embroiled in right now. How do we get into this situation? How do we get out?
I work in the world of software development, and in the traditional way of working here, so many things were out of my control. In my days as a developer, I had no influence on our delivery dates or scope, and these externally imposed controls threatened either the completion or the integrity of my work. Here's where my personal life came in: this job paid my mortgage. The people were nice, it was close to my house. I wanted that job.
The company's success, we were told, was dependent on our own success in meeting delivery deadlines. Given the choice, many of us chose to borrow time from our personal lives to allow creation of quality work products within the given timeframes.
Hmmm: "borrow time from our personal lives"? Eventually this strategy reveals its true face: co-workers now expect this level of committment from us and we realise that we will never get that time back. The desire for sustainability now provokes a different dilemma: disappoint our co-workers or our friends and family? When we are passionate about both our teams and our home life this dichotomy adds further pressure to the long days we are heroically accomplishing. Over time, morale can erode, and despite our passion the quality of our collective work can suffer. Analogous situations emerge in other work roles: architect, manager, [your job role here]. The details may differ but the end result looks similar: stress, discouragement, sub-optimal performance.
Agile Work is an approach that offers hope to rectify this imbalance by realigning the accountabilities and responsabilities of project participants. But we tend to carry our old ways of thinking into these new ways of working. Agile practices alone are not the answer - the realignment must reach deep into our own beliefs about work. Achieving this is is one aim of the Agile practice of periodic Reflection, or Retrospective. Some of you have a head start on this: a few Agile coaches discussed this important topic in the context of their own roles recently, at the Boulder Scrum Gathering.
I'll write more about this topic in January. In the meantime, I invite you to reflect on your work-life teeter-totter... how's it doing? What do you really want, I mean really? Many of us are away from our offices this week: a good opportunity to remember who we are and what makes us happy. Leaving behind "ought" and "must": can you imagine a life in which work and home do not compete, but complement each other? Imagining it can help you discover the next change you want to make - and it may not be the biggest or most obvious!
Hold on to your passion - it's part of who you are. And savour your time with family and friends - it will help you channel that passion in healthy ways, to adjust your balance. Sustainability can rekindle your creativity and bring back a joy you thought was lost.
I wish, for you and those you love, a restful and healing time as you prepare for an exciting new year, in which you can "work smarter, not longer."
Peace,
deb
Further reading:
Book Review: Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency, book by Tom DeMarco
Book: Peopleware: Productive Projects and Teams, 2nd Ed., by Tom DeMarco
Book: The Responsibility Virus: How Control Freaks, Shrinking Violets-And the Rest of Us-Can Harness the Power of True Partnership, by Roger L. Martin
Discussion notes: Sustainable pace for coaches, mentors and change agents
Posted by Deborah Hartmann at 11:09 PM | |
December 22, 2005
Acting on the Essential Advice for Agile Coaches
In the entry "Essential Advice for Agile Coaches" I mentioned seven responsibilities that we have. These seven responsibilites can be used as a framework for self-evaluation and goal setting. I have created a simple spreadsheet tool to help track this work.
OpenOffice.org
Sample of Agile Coach Assessment.ods
Microsoft Excel
Sample of Agile Coach Assessment.xls
Terms of Use: Copyright 2005, Berteig Consulting Inc. No warranty express or implied, blah dee blah... If you want to give people copies, please go ahead just don't take out the link to the help page. If you want to distribute modified copies, you must send me a copy first with permission to use your modifications if I like. If I find out you've been bad, I might not like you as much any more... then again, I'm Canadian so I'll probably say "sorry!"
Posted by Mishkin Berteig at 03:23 PM | |
Entries over the Holiday Season
Hello all! I'm travelling and visiting and working over the holiday season so my posting frequency is going to be very low... My most exciting thing is that on the 28th and 29th I'm going to be delivering the ScrumMaster Certification course in Toronto to a great group of interesting folks. Have a great holiday season!
Posted by Mishkin Berteig at 03:01 PM | |
December 21, 2005
Social Dynamics for Agile Organizations
Article: A Group Is Its Own Worst Enemy by Clay Shirky.
Clay is writing about social environments enabled by technology and what we have learned about groups from these environments. He points to several failed online communities as well as research pre-dating the Internet and points out "Three Things to Accept" and "Four Things to Design For". Both lists are critical for us to map into Agile organizations. I have some thoughts on how to make the mapping to those Three Things to Accept.
Three Things to Accept... in an Agile Organization
1. We cannot completely separate social and technical issues.
In Agile, this is a recognition that having an open team room (and no offices), influences team success... and that team dynamics will influence the use and effectiveness of that team room's space.
For an Agile organization, your organizational communication mechanisms such as email, telephones, video conferencing all play a role in how effective the Agile community becomes... and that the Agile community in your organization will change the way that technology is used to communicate.
One company I have coached has struggled with developing a strong community of internal Agile practitioners because there is no easy way for them to communicate in a collaborative manner. The corporate policies about networks, hardware, etc. make it very difficult to set something up in an ad hoc manner. Now, however, the needs of the internal Agile community have become strong enough that there is an effort to set up a wiki... but the organization has no idea what kinds of challenges that can open up. What will be the rules for using the wiki? Can people put stuff up that is "off-topic"? What constitutes acceptable material? Will it need moderation?
This relationship between the social aspect and the technological (or media) aspect must be accepted.
2. Members are different than users.
There may be lots of people involved in Agile projects, Agile training, Agile coaching, Agile management etc. in an organization... but not all of those people will be members of your internal agile community. Some of them will do it as their day job. And some will get excited and become leaders of the community. These self-selecting leaders must be nutured and supported.
You can identify these people because they will have ideas, attend lots of meetings, and generally want to be with other people doing agile in the organization. This should not be considered wasteful, but rather a natural extension of people's desire for community. These people have an important role to play. Therefore a great deal of attention should be paid to giving them access to lots of training, exploratory implementations of Agile, etc.
3. The core group has rights that trump individual rights in some circumstances.
The self-selecting core group has to be protected. This does not mean protecting individual members of the core group. In other words, a member of the core group who for some reason starts to undermine the group or the Agile community should not be protected. Rather, the community needs to be protected, possibly by ejecting a member who is causing problems.
In societies where individual rights are considered the highest priority, this can be difficult. Unfortunately, if you want the community to survive, then you have to have some community rights that are stronger than individual rights. If on the other hand, as an organization, you truly believe that individual rights are most important, then you might not want to bother trying to create an Agile community... since it will fail (read the linked article for details).
Someday I might also write about the "Four Things to Design For" :-)
Posted by Mishkin Berteig at 05:27 PM | |
December 19, 2005
Penny Queueing Exercise - Lean Process
This simple simulation exercise helps people to understand the efficiency that can come from moving away from a waterfall or large batch process. The exercise can be done with 20 pennies, 5 people and a clock with a second hand.
The exercise simulates processing work in the form of flipping pennies from heads to tails and back. Four people in the Team sit at a table or other hard surface in a line beside each other. The surface must allow for easily sliding the pennies. The fifth person, the Manager, starts the process and times it. The Team will process the pennies twice...
First Pass - Waterfall Large Batch
1. The Manager gives all the pennies to the first person in the Team and notes the start time. The pennies should be in a big jumble.
2. The first Team member chooses a side (heads or tails) and flips all the pennies onto that side.
3. The person with the pennies passes the whole pile of pennies to the next person. That person then flips all the pennies to the other side.
4. Repeat step three until the last person on the Team has flipped them.
5. The manager notes how long this took.
Second Pass - Waterfall Small Batch
1. The Manager gives all the pennies to the first person in the Team and notes the start time. The pennies should be in a big jumble.
2. The first Team member chooses a side (heads or tails) and flips all the pennies onto that side. As each penny is flipped, the Team member passes it along to the next person.
3. Each person flips their pennies as quickly as possible and immediately passes them on to next person.
4. Do this until they are all flipped.
5. The manager notes how long it took for the first penny to go through all four Team members, and how long it took for all of them to finish.
Optional Third Pass - Parallel Small Batch
1. All the pennies are in a random jumble in the middle of the table.
2. One Team member calls heads or tails and the manager notes the start time.
3. Each person grabs a penny at a time from the pile.
4. All working at the same time as quickly as possible, each person flips the pennies first so they are all the same as the original call if needed, and then three more times
5. As each penny is finished 3 or 4 flips (as appropriate) it is pushed into a separate done pile in the middle of the table.
6. The Manager records the time for the first penny to be put into the done pile and for all of them to be completed.
I heard of this exercise through the agile coaching grapevine, originally from one of my apprentice coaches. After attempting to trace it back to its origins, I believe that it may originate in some lean training, but I am uncertain at this time. I have made my own modifications to the original exercise and these are reflected above. If I am able to properly acknowledge the origin of this exercise, I will update this entry to do so.
Posted by Mishkin Berteig at 11:53 AM | |
December 16, 2005
Two Motivational Metrics for Agile Teams
In general, an organization should have one metric that is used to measure success. However, along the way, it may be useful to temporarily use other metrics to help motivate, track, or predict work. Here are two metrics that can be used in this temporary manner for Agile Work.
Time to Obstacle Removal
TTOR = sum of calendar time elapsed for all unresolved obstacles divided by number of unresolved obstacles
Why Use TTOR: the team, process owner and product owner need to work hard to remove obstacles quickly. This metric tracks how well this is going.
When Use TTOR: use this only when people and the organization are not driven to remove obstacles. This metric can be tied to bonuses and/or compensation in order to give it teeth. Do not measure individuals with this metric. It is only applicable at the team level or higher (e.g. program or division level).
When to Stop Using TTOR: When TTOR has been reduced to less than the time between status meetings (usually one day), then the organization is doing well and this metric should be discontinued.
Obstacles Removed per Iteration
OR/I = number of obstacles closed as removed (not ignored or deferred) in a single iteration
Why Use OR/I: this is a "game" metric or score that encourages large numbers of obstacles to be identified and removed. The more obstacles removed in an organization or team context, the faster the work can be done.
When Use OR/I: if a team is not identifying obstacles in the status meetings, consider implementing this metric to encourage obstacle identification... and critically... resolution. This metric is for team use only.
When to Stop Using OR/I: this metric stops being useful if team members are spending time concocting obstacles that are trivial or worse, deliberately creating obstacles to be resolved. The Process Facilitator needs to be sensitive to these potential pitfalls of this metric. Once the team is consistently identifying one or two obstacles per status meeting, and they are getting resolved in equal quantity, this metric must be discontinued.
A Word of Caution: there is no substitute for a . These two metrics are contextual and temporary. Do not use them if they are not indicated by the circumstances and be sure to discontinue use when symptoms disappear.
Posted by Mishkin Berteig at 11:57 PM | |
December 15, 2005
What Happens When a Team Doesn't "Get to Done" in an Iteration?
At the start of the iteration, a team commits to a goal and a certain amount of work. Burndown charts help a team to monitor their own progress against that goal. The team works together in a room with a process facilitator and product owner. Everthing seems to be okay, and yet, the team doesn't fulfill its commitment. What to do?
How Bad is This?
If the team is just adopting Agile Work methods, is a new team, and is on a new project, then this problem is common and to be expected as an early part of the team's learning. In other circumstances, this is a disfunction.
The severity varies greatly, but the worst thing that can happen is that the team gets in the habit of doing this regularly and therefore starts to believe that it is okay. It is not okay. One of the most important aspects of Agile Work is the closure of work completed at the end of the iteration.
This closure has all sorts of benefits: a feeling of accomplishment for the team, delivery of real value to the customer on a regular basis, better capacity planning based on actually completed work history, and accurate feedback from the customer on a regular basis. If the work is not completed, none of these benefits are possible.
Planning Failure
One way the team fails to get to done is simply through poor estimation and planning. There are several key practices to use in agile planning: tracking velocity, tracking availability, estimating work and iteration planning. In order to correct this type of failure, try the following simple iteration planning steps:
1. At the beginning of an iteration, the team records it's "velocity" for the previous iteration. This number is equal to the beginning estimated size of work for the iteration plus the original estimated size of any work added during the iteration minus any work left over. The team may also wish to record exactly how many person-days were worked in the previous iteration based on when people were sick, on vacation, in training, left the team or joined the team. (If it is your first iteration, you may want to use drag factors - the subject of a future article - or the team may just take a wild guess as to its velocity.)
2. The team then collaborates to put an estimate on each piece of work to be done. There are several systems for doing estimates including "Story Points", "Ideal Hours/Days", or "Ping-pong Balls". Sum these estimates up into a total proposed work size for the iteration. If the team determined person-days worked in the previous iteration, then estimate person-days available in this iteration taking into account the same factors.
3. If the estimated work to be done is greater than the team's velocity for the previous iteration (and optionally factoring in the ratio of person-days worked/available) then remove the lowest priority scope from the iteration until the estimated work to be done fits the team's capacity.
Obstacle Removal Failure
Sometimes a team will be unable to complete the work of the iteration due to an obstacle that was not cleared. Possibly the obstacle was not identified or only identified very late in the iteration. Possibly the Process Facilitator was irresponsible or incapable of removing the obstacle for the team. Or possibly the organization around the team was unable to remove the obstacle or forbade its removal.
The team must be certain of the nature of the obstacle. A brief pull-up or more in-depth retrospective may be necessary and thinking tools such as the "Five Whys" may be useful. Once the obstacle and its nature are understood, its consequences must be fully exposed to all members of the team and all stakeholders. In the full light of the obstacle's nature and consequences, the team and stakeholders can decide what to do: remove the obstacle, mitigate its effects, or live with it. Choosing to live with an obstacle should be seen as a last resort and even in this case resolving the obstacle should be put on the work item list to be revisited sometime down the road.
Regardless of the status of the obstacle, the team must adjust its planning for the remainder of the iteration or the next iteration in order to take into account how it was dealt with.
Failure to Abort the Iteration
Sometimes information comes to light that invalidates the work of the team for the iteration. The Process Facilitator, the team and the Product Owner must collaborate to decide if the iteration should be aborted early. If this new information is ignored for any reason, then a team may continue working on the iteration but not get to done.
Aborting an iteration is a healthy thing to do and is a legitimate part of being agile. It should not be considered a failure. Aborting the iteration can be a powerful means of communication and re-planning. It is meant to be done rarely and it is designed to send a strong message.
Posted by Mishkin Berteig at 03:30 PM | |
December 13, 2005
Agile Work Uses Lean Thinking - Team Self-Organization
This third and final installment of the "Agile Work Uses Lean Thinking" series introduces Team Self-Organization from a lean and agile prespective. Find out what lean practice relating to people is not commonly used in agile methods... (Previous installments are Empirical Process Control and Queuing Theory. A polished version of all three articles will appear soon as a downloadable PDF.
The people who actually do certain work on a day to day basis know that work intimately... more intimately than anyone else. Anyone else who knows the work either knows it historically or in theory, but not in the same intimate manner. This intimate knowledge carries a great deal of potential. In order to release that potential, people must accept individual responsibility and collective responsibility. Management and organizational culture must support that responsibility. Lean and agile have a very similar approach to supporting this self-organization.
The first aspect of this support is just a simple recognition of this intimate knowledge. The people doing the work must have their expertise acknowledged both individually and collectively. The second aspect of this support is to share with these people the strategic and tactical "why" of what they are doing. This can include sharing financial models, strategic assessments, etc. The third aspect of this support is in allowing individuals and teams to create and implement their own process improvements. In lean this focuses on "identifying and eliminating waste" and in agile this focuses on "identifying and removing obstacles". The fourth aspect of this support, and perhaps the most important, is that of self-organization: teams and individuals organize themselves around the work. Managers no longer have the authority to tell people how to do their jobs.
In agile teams, this concept of self-organization is taken quite far. Team members collaborate to get work done. No one orders a team or an individual to do specific work. The team members volunteer for work that they see needs doing, even if it is not something that is in their area of expertise. An agile team is constantly promoting learning in its people. Agile teams are also cross-functional so that the team can get work done without relying on external services. The team therefore represents a complete work unit capable of taking a function valuable to customers from start to finish, from idea to deployment.
One aspect of lean systems that is not commonly practiced in an agile environment is the idea of stopping the production line when a flaw or defect or error is discovered. In lean manufacturing, every person working on the line has the authority to stop the whole line if they notice something wrong. Then, everyone works on correcting the defect all the way to the root cause of that defect before starting the line again. This is a very powerful mechanism for making certain that there is constant improvement in the production process. Giving people the power and authority to stop the line takes a great deal of trust.
Posted by Mishkin Berteig at 09:09 PM | |
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 11, 2005
The Power of Iterative Delivery and Adaptive Planning
As a coach, it is nice to have some simple ways to show people the power of Agile methods. This quick little exercise is an excellent way to demonstrate the weakness of the waterfall approach to working with up-front requirements analysis versus the power of the agile iterative/adaptive approach. UPDATED 20051213!
Find the Number
Work in pairs with someone you don't know. One person will choose a number at random between 0 and 1000. The other will try to figure out the number chosen. You have sixty seconds to communicate the number but...
FIRST METHOD:
1. Write down the number so the other person can't see it.
2. Come up with clues about the number. You cannot use any math either explicitly or implicitly in your clues. E.g. if the number is "256" here is a good clue: "the first and second digits are rotationally symetrical on an LED display", and here is a disallowed clue: "it is an even number" (uses a mathematical feature).
3. As you figure out clues, tell them to the other person.
4. The person trying to determine the number cannot ask questions.
5. Before the sixty seconds are up, the person must state a number they think is correct (and the other person must tell them if they are correct). Only one "guess" is allowed.
SECOND METHOD:
1. Switch roles with your partner.
2. Write down the number so the other person can't see it.
3. The person trying to find the number guesses a number at random.
4. The person who knows the number tells the other person if the guess is low, high or correct.
5. Repeat steps 3. and 4. every six seconds.
Debriefing
1. How was the first part of the exercise like the waterfall method? Was it successful/how close did you get?
2. How was the second part of the exercise like the iterative/adaptive method? Was it successful/how close did you get?
3. What other interesting things did you notice about this exercise?
Acknowledgements: the second part of this simulation exercise comes from a discussion with Jim York of CCpace.
Posted by Mishkin Berteig at 08:39 AM | |
December 10, 2005
The Toyota Production System
Here's a good article about the Toyota Production System (TPS). Agile work takes many of the ideas here and adapts them to a non-manufacturing situation. There's an interesting comment about the "5 Whys"....
From the linked article:
When an error occurs, the first thing that needs to be done is fix the error. Minoura recalls that Ohno used to order them to ask the question "Why?" five times over because "that way you'll find the root cause, and if you get rid of that it'll never happen again." However, Minoura emphasizes that on-the-spot observation rather than deduction is the only correct way to answer a "Why?" question. "I'm always struck that the five-why method doesn't seem to be working as well as it should be because there's been a lack of practical training. The reason is that they end up falling back on deduction. Yes, deduction. So when I ask them 'Why?' they reel off five causes as quick as a flash by deduction. Then I ask them five whys again for each of the causes they came up with. The result is that they start falling back on deduction again, and so many causes come back that you end up totally confused as to which of them is important."
Posted by Mishkin Berteig at 12:00 AM | |
December 08, 2005
Essential Advice for Agile Coaches
As coaches, we have a great deal of responsibility. Through our words and actions we lead and guide our teams and apprentices as they encounter the new way of working that Agile requires. We are responsible for their success as well as the success of the endeavor they are working on. How can we ensure we are doing everything in our power to live up to this responsibility?
Pairing Spend time sitting with team members to learn what they are doing and appreciate their work. Maybe even find ways to help them out. This time will help you develop a personal connection with each team member. Doing this will also help you become attuned to the non-obvious obstacles that impede the team's progress.
Service Don't let anything get in your way of serving the team. Meetings, training, and other things can easily become excuses not to do the hard work of service. Make sure that you aren't sacrificing the team's well-being for your own.
Team Building Keep thinking about and encouraging team building exercises. Little things can often make a big impact. You don't need a full-day wilderness off-site to get a team to work well together. There is a huge difference between a bunch of individuals working towards the same goal vs. a team which is "in the zone" of super-productivity. As a coach, getting the time to spend as much time in this state of flow is your primary objective.
Experiment Aggressively experiment with new ways of doing things and encourage the team to do so as well. Every experiment that fails is just as important to improving as every experiment that succeeds. If every individual is experimenting with ways to improve their own work, then we can trust an evolutionary process to take place where better and better improvements are constantly being found.
Personal Development Constantly strive to develop personally in terms of behavior, knowledge, thought, and morals so that you can lead by example. "Truthfulness is the foundation of all human virtues" and so it is a good place to start. This personal development may require getting your own coach or even a therapist. Your own barriers to improvement can best be overcome with help from someone else.
Learning Actively seek new reading materials and research subjects that are related to agility. Expand your reading to organizational culture, community development, economics, the philosophy of science, sociology, as well as technical fields. This diversity of knowledge will allow you to see otherwise hidden opportunities.
Breakdowns Encourage little breakdowns to avoid the big ones... little ones are much easier to handle. Lots of little breakdowns can become opportunities for transformative learning, but letting them accumulate until they create a catastrophe usually just hurts. The small breakdowns are difficult enough.
That's a big list. I don't do all that perfectly, but that is the standard I am constantly striving towards. It is a standard of constant improvement, just like Agile Work itself.
Posted by Mishkin Berteig at 05:35 AM | |
December 07, 2005
Catastrophe, Crisis and Victory
Today I came across Tobias Mayer's article Catastrophic Organizational Change. Much as his thoughts on the topic resonate with me, I think there is something still missing.
His process reminds me of the term "crisis and victory" which in my faith community is used to describe an ongoing (and never-ending) process of learning and advancement. When this cycle stops, it means we have stopped learning and advancing. This applies to an individual learning about agile, a team learning about agile or an organization learning about agile. So perhaps we should also discuss the terms "Catastrophic Team Change" and "Catastrophic Personal Change"?
And yet, frankly, much as I like the rebellious and in-your-face feeling of the word "catastrophic", I think it does a dis-service to the actual process involved. Catastrophic change is what happens when you ignore incremental crises until they build up to a point where nothing can be done any longer except pass through an enourmous destructive process in order to re-build. Catastrophic change at any level is the sign of disease. As agile coaches, trainers, practitioners, we should be encouraging a healthy cycle of crisis and victory not a process of crisis, crisis, crisis, crisis, crisis, CRISIS!, CATASTROPHE!!!,... change.
Several of the best coaches that I know actively encourage small breakdowns. Little crises. These breakdowns then become learning opportunities. The work can then become an environment for transformative learning. It's hard work for team members. People have to actually think, develop personally, change themselves instead of expecting their environment to change. But it is at the core of being Agile.
Posted by Mishkin Berteig at 12:52 PM | |
Email Notifications
If coming back to Agile Advice and checking for new entries is getting to be a pain, consider signing up with Bloglet for an email subscription. I've tried it out for a couple days myself the emails I get are very non-invasive, with a simple link to the articles. If other blogs you read also allow Bloglet subscriptions, you can aggregate all the activity into a single daily email. Very convenient!
Posted by Mishkin Berteig at 09:08 AM | |
December 06, 2005
Agile Work for "Flow Projects"
A "flow project" is a type of work where a team is working on many very similar, independent, small work items. This type of project is quite common in IT departments doing infrastructure work, maintenance work or support work. Agile Work practices can be applied to this type of project with just a little tweaking.
Self-Organizing Team
The basic principles of agile require that the team determine how it does its work without compulsion. One of the key mechanisms for this is the frequent reporting of individual status to the team. In a flow project, the normal three questions can become quite repetitive and so an emphasis should be made on elucidating obstacles. The process facilitator must be very aware of obstacles even if they are only implied. As well, a "stop the line" policy may be necessary to fully expose the urgency of obstacles. In this case, an individual declares a problem with the work item they are currently handling and everyone on the team stops to help until the problem is fully resolved. Strong medicine? Yes, but if you are working on several hundred or thousands of work items, this can lead to enourmous efficiencies as obstacles are removed, never to be seen again.
Iterative Delivery
Iterative delivery is normally used to take a very large piece of work (a project) and chunk it into consistently sized smaller pieces of work. This chunking is done in order to gain efficiencies that can be found by applying queueing theory. In a flow project, the work is already chunked into small and relatively consistently-sized work items. In fact, the work items are typically much smaller than "normal" iterations (1-4 weeks). This means that other aspects of queueing theory become more important, particularly the gating function and managing the queue sizes (more below). Iterations can still be useful, but now they are predominantly used as checkpoints for process improvement, and domain and technical knowledge-sharing. Releasing work completed may be done in a flow manner as each work item is completed.
Adaptive Planning
Adaptive planning, normally done between iterations, now takes on more importance and must be done continuously. The work must still be prioritized as with a normal agile project. However, as work flows through the team, work items are constantly being removed from the top of the work list. In some cases, a work item will have to be put through several stages before it is complete. Each stage must have its own queue of work items that are ready to go into that stage. The sizes of these queues of work must be managed so they never grow beyond a certain number of items. One way to manage this is to have individuals responsible for a work item from start to finish throught the process. However, due to specialization of skills or roles, this is sometimes difficult or impossible to do. Nevertheless, despite apparent inefficiencies, it is critical to manage the flow of work as a pull system.
Test-Driven Work
Also known as "build quality in"... If you need to go fast, one of the best ways is to never have errors or defects. And one of the best ways to do this is to create a test to ensure that your work is correct before actually doing the work. In a flow project, the conditions of success for each work item are often either the same or similar in a consistent manner. It is well worth it to invest a little time in developing an automated system to check the quality of work as the work is being done. In certain domains such as software and manufacturing, this is fairly easy to do with various tools. In other domains it can be more difficult. Nevertheless, get your team to investigate this problem and implement solutions even if they are only partial solutions. Having all of your work flow through your process without defects will prevent many occurances of the waste of rework.
Maximize Communication
The basic agile practice of maximizing communication applys almost without change to flow projects. Getting all of the team in the same room, having big visible charts to show the status of work and other tools to maximize communication are all important. In order to stop the line when an obstacle is found, it is necessary that everyone on the team is immediatly aware that they are to stop! If everyone is supposed to work intensly on removing an obstacle when the line is stopped, then they all need to be in close collaboration. Team-building techniques that encourage friendships, dealing with conflict, respect, and collaboration are all critical to going fast with a flow project.
Appropriate Metrics
In an agile project, the delivery of valuable results is the most important thing to be measured. However, in flow projects, an additional measurement is often very useful: Process Cycle Time. Reward the team for reducing cycle time while keeping quality constant or improving quality. This is one of the best ways to encourage creative methods of getting work done in a flow project.
Agile Work Axioms and Disciplines
The three Agile Work Axioms and Disciplines all apply to flow projects just as much as to "normal" agile projects. The only change is in their emphasis and target. For example, "We are Creators", now applies much more to the problem-solving aspect of trying to make the overall work go as quickly as possible. One goal of a flow project should be to automate as much of the work as possible. This automation work is definitely a creative endeavor even if the work itself doesn't offer much room for creativity.
Posted by Mishkin Berteig at 02:52 PM | |
More on Daily Status for Self-Organizing Teams
It's a little old, but I just found and read Rachel Davies article about variations on the daily standup. Personally, I like the extremely simple three questions defined in standard Scrum, but I can certainly understand that there might be circumstances where those are insufficient.
Note: I've added new sections to the recommended links page. The sections come from the Agile Work Cheat Sheet. The above article about daily standups is included in the Self-Organizing Team section.
Posted by Mishkin Berteig at 07:25 AM | |
December 05, 2005
Mastering Agile Work
Not everyone will master the techniques of Agile. Mastery of any discipline takes much more than reading a few books and taking a few courses. Here's my take on mastery...
Mastery of any discipline depends on four conditions:
1. Will. If you have the will to master a discipline, you will put in the effort required.
2. Assistance. Mastery requires an environment which supports the learning process. The learning opportunities available must fit with your personal learning style.
3. Constraints. In order to truly master a discipline, the process of mastery must include dealing with constraints and other challenges. Learning from failure is just as important as learning from success.
4. Opportunity. A person must have the time or the ability to free the time to work on mastering a discipline. The amount of time necessary depends on one's starting point in personal capabilities.
Mastering Agile Work
Mastering a discipline takes more than just learning the practice and being able to do it well. There are in total four components to a discipline that need to be accounted for:
1. Theory. Agile Work theory includes Lean and queueing theory, adult education, organizational learning, systems theory, and economics. Understanding this theory allows a person to extend their mastery of Agile into unfamiliar situations.
2. Practice. The practice of Agile Work has simple basics, but includes a vast array of combinations, minor practices, and disfunctional practices to be avoided. Experience actually trying, failing and succeeding at a majority of these practices is necessary for mastery.
3. History. Understanding how Agile evolved, who were the leaders in the field, and various anecdotes about Agile implementations are critical for being able to link our own activities into a larger community. This larger community allows us to understand the constraints of Agile, and provides a peer group to share with and learn from. Mastery can only be ongoing in a historical context.
4. Criticism. No person can grow in their understanding of a discipline without also understanding how to do critical reflection of one's own work and the work of others. Fortunately for those interested in Agile, this process of critical reflection is built into the Agile process and practices to a large degree.
Call to Action
The vast majority of current discussion in the Agile community is around practices and focused on software development specifically. There is only a little work being done in the Theory, History and Criticism aspects of the discipline. In order to become a fully respected discipline, all aspects need to be given appropriate weight.
Those of you who consider yourselves masters of the Agile practices, can you see yourselves investigating these other aspects? The question "why?" is just as important, if not more so, than the question "how?" Let's investigate these wonderful methods of ours.
Posted by Mishkin Berteig at 12:13 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 | |