Agile Advice

Posted by Mishkin Berteig at 02:02 PM | |

November 25, 2005

Iterations Stories and Velocity

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" is one that I recommend highly to most people who are actually using agile methods.

Posted by Mishkin Berteig at 10:08 AM | |

November 22, 2005

Cynicism, Apathy and Agile

I am currently one of those consultants working in a large organization that is trying to implement Agile.

Without a doubt there is huge, mostly unconscious, resistance to the cultural change that Agile requires of a highly-regulated command and control organization. Yet even with that, introducing a few simple agile practices in a reasonable fashion such as iterative delivery, daily status for self-organization, colocated teams and a few information radiators has made a huge difference in teams' ability to deliver and in their satisfaction with their work. The jury is still out about this change at this organization: will it be permanent? or will it be another fad? or will it remain a weak version of agile?

Like almost any idealistic movement, Agile cannot succeed in the short term. People's hearts need to be transformed, their habits changed and their thoughts changed. This can happen quickly for some, but for most it is a long process often preceded by the pain of doing things badly. For the most part, Agile is a movement that is being driven by the grassroots: folks in IT who see it as the better way. However, even if every programmer and project manager in an organization decideds that Agile is the way to go, it could still fail before it wins. The corporate culture change required to fully adopt agile can take years and years and can be scuttled at any time by the whim of those in power. If that happens, some of those folks who wanted Agile will become cynical and immunized to the idealistic pull of Agile.

The faster we go, the less patience we have, the more people will become immunized.

The attraction of the financial side of things for consulting, training, publishing, all threaten to poison our community. In the Baha'i Community, to which I belong, our religious laws prohibit "professional" Baha'is. The mix of money with an ideal would destroy the goals of our community: peace, unity. Of course, that means it takes hundreds of years if not thousands to build our capacity, to demonstrate to others the bounties we have to offer.

In the Agile community, like in many other places, there is no sense that this is a movement to span hundreds of years, nor even decades. It is a young set of ideas and has only been visible for six or seven years. We don't have the patience to wait decades, partly because we are excited, but also partly because we all need to earn a living and I don't think any of us really want to be economic martyrs to the cause of Agile. Nevertheless, sometimes we do have to have courage and walk away from a bad deal.

Thanks for Tobias Mayer for a message on the ScrumDevelopment Yahoo! group. That message inspired this one.

Posted by Mishkin Berteig at 11:43 PM | |

November 20, 2005

Amplifying Learning Through Fostering Critical Reflection

I have written previously about the tendency we have to limit future learning based on previous learning. This tendency has aptly been termed by Mezirow as the central learning problem of adulthood: "that we fail to notice that failing to notice shapes our thoughts and deeds." In Transformative Learning literature a central method advocated for overcoming this learning problem is critical reflection. Critical reflection is the act of becoming conscious of our beliefs and assumptions (Where do they come from? Are they valid? What are their limitations? etc.) and either expanding, validating or discarding them.

Stephen Brookfield has written extensively about critical reflection and the following is a brief summary of a part of a chapter he wrote in a text on adult and continuing education entitled "The Concept of Critically Reflective Practice."

Brookfield outlines Four Traditions of Criticality found in different fields:

Ideology critique
It is based on a premise that uncritically accepted and unjust dominant ideologies are embedded in everyday situation and practices. The purpose of ideology critique is to examine these assumptions in order to effect change at the social and institutional level. An example of this kind of approach to learning is found in the work of American popular educator Myles Horton. As the founder of Highlander Folk School, during the civil rights movement he started literacy program for African Americans. Study groups would learn to read while engaging in ideology critique in their own lives and communities using the Universal Declaration of Human Rights as a the text.

Psychoanalytic and psycho therapeutically inclined critique
These are traditions that work on identifying and reappraising limitations created through childhood traumas. This tradition advocates individual and group therapy for personal learning and development for the purpose of integration of all aspects of self.

Analytic philosophy and logic
This is the tradition that for most is closely associated to critical reflection. Here critical reflection means to recognize logical fallacies and see the difference between bias and fact and opinion and evidence, and become effective at using different forms of reasoning.

Pragmatic Constructivism
This tradition is based on the premise that reality is perceived, that is, we construct our own meaning out of experiences. The focus here is how people interpret their experience v.s. universal and recognizable truths. There is also a strong emphasis on creating new realities together.

Brookfield proposes that to engage in reflection is not the same as engaging in critical reflection. His understanding of critical reflection is centered on ideology critique rooted in the pragmatic constructivist approach. Renowned Brazilian educator Paulo Friere speaks of a similar process by which adults "achieve a deepening awareness of both the sociocultural reality which shapes their lives and... their capacity to transform that reality through action." Ideology critique is rarely used in the work place. For the most part a culture of conformity and obedience is promoted by organizations.

Brookfield presents a picture of what the process may look like: "The adult educator's task is that of helping people articulate their experience in dialogic circles and then encouraging them to review this through the multiple lenses provided by colleagues in the circle. On the basis of these collaborative critical reflections on experience adults reenter the work to take critically informed actions that are then brought back to the circle for further critical analysis."

To engage in collaborative critical reflection based on a rhythm of action and reflection is not only a process of building collective knowledge and consensus, but also strong foundations for both trans formative learning in the work place and thriving self-organized teams. It is also a way to discover appropriate forms of metrics because it helps people apply multiple lenses of analysis to their work.

Critical reflection should be taught to teams through modeling. For example the coach disclosing his/her won process of critical reflection. Critical reflection should no be associated with self berating and putting others down or the culture of "telling it like it is" without regard for others.

Try the list of questions in the extended text to get a sense of how your work as an Agile practitioner (or whatever work you do) can be enhanced by critical reflection.

Critical Reflection Questions for the Educator
Taken from "Understanding and Promoting Transformative learning"
By: Patricia Cranton

What is my self concept as an educator?

How is my self concept as an educator a part of my self concept outside my profession?

To what degree do I feel I have personal control in my work as an educator?

What do I like and dislike about being an educator?

What personal needs does being an educator fulfill?

How does my personality suit or not suit my being an educator?

Self awareness of sociolinguistics perspective on being an educator:

What are the perceptions of an educator in my community?

How do the media represent educators?

Was my decision to be an educator influenced by my cultural background?

What social role should an educator take?

How does society script or determine educator roles?

What language is used to talk of an educator’s work, and what do these terms or phrases imply about other’s perceptions?

Do people treat me differently when they know that I am an educator? If so, how?

What are my learners’ expectations of the role of educator?

What are my organization’s or institutions expectations of educators?

Where and how did I gain my knowledge of being an educator?

What is my teaching style?

What is my philosophy of educations?

What is my learning style?

How much do I know about being an educator? How much more might there be to learn?

How much do I think about being an educator?

How do I (would I) evaluate my performance as an educator?

What do my learners and colleagues say about me as an educator?

Do I see myself as always being an educator?

What aspects of being an educator am I most interested in?

Posted by Shabnam Tashakour at 11:55 PM | |

November 19, 2005

Article on Slashdot

I posted an article on Slashdot about Microsoft, Yahoo!, and Google using agile methods for software last Sunday and it was accepted... my first one on Slashdot :-) John Brothers did a nice summary of some of the comments.

Posted by Mishkin Berteig at 08:46 AM | |

November 16, 2005

A Metric Leading to Success

I just recently read the article by Ron Jeffries: A Metric Leading to Agility. It's a good, well written, well thought out article. If you are in the software business, check it out if you haven't already.

However, much as it is good advice, I believe that I must add a cautionary note.

Why Agility?

The title of the above article, and the metric suggested (Running Tested Features), imply some pretty serious questions: why agility? Aren't we really trying to help organizations succeed? Isn't agility just a means?

I've seen organizations adopt Agile in some form or another for lots of different reasons. The best reason is because it is recognized as a means to succeed. However, as a means, you don't want Agile to drive change in your organization. Something else should be doing that. Some need, some failing, some gap or some pain. And that need should be measured.

Appropriate Metrics

Running Tested Features as a metric is indeed powerful: it is difficult to "game" and it seems to promote the delivery of features, which presumably are valuable. The problem comes with the presumption of value. What if you end up choosing the wrong features? What if you are using agile on a non-new-product, non-software project? What if you don't care what method you use, but you want a metric that will drive success (and might as a by-product encourage Agile approaches)?

One great approach to Metrics comes from the book "Good to Great" by Jim Collins. The research team for the book discovered that every organization (in their sample) that made a sustainable change from mediocre to great results had a central, single metric (among other things) that was used as an economic driver to guide and measure the transformation. I enquired of the author about this: did the research team discover the use of more than one metric? Joanne Ernst on the research team responded:

I discussed your email with Jim, and he says that all of the metrics/measures that were consistently shared by GTG companies were reported in the book – e.g., the economic driver. (Personal Communication, 26 Jun 2005)

When looking at an organizational level, suddenly Running Tested Features seems like it might be a little beside the point. Mary and Tom Poppendieck in "Lean Software Development" discuss using financial models to help drive a team's work to become more Lean, more Agile... and specifically to be aligned with what is going to bring success to the organization.

Using metrics to drive behavior or performance is tricky business. Simpler is better, fewer is better and directly related to overall organizational goals is better. Measuring Running Tested Features can indeed drive a team to become more agile, but that might not be the best thing for the organization, or it may not be applicable to the organization. There is no One True Metric. Each organization and team has to find out what works best based on application of principles and experimentation.

One metric that leads to agile? Maybe. One metric that leads to success? That's what your organization needs to find for itself.

See also: Appropriate Metrics, The One True Metric.

Posted by Mishkin Berteig at 07:15 AM | |

November 15, 2005

Experiment - You Submit Entries

I have created a Guest account to allow readers to become writers. Do you have an interesting agile story? Have you been thinking about Agile in connection with some wierd or wonderful other field? Have you been pondering the deeper meaning of Agile? Or maybe you just found another site that everyone needs to know about. Here's how to do this:

Go to http://www.agileadvice.com/mt/mt.cgi. Log in with username "Guest" and password "guest#9". Create an entry and save it.

If you are confident that your entry is top-notch or otherwise ready to go on the front page, feel free to save it with the "Publish" post status. If you are not so certain, go ahead and use the "Future" post status and I will review it for you.

Here are the rules:

1. I will delete or edit anything for any reason if I want. I will ban anyone that I want. And I will discontinue this experiment at any time that I want.
2. Content guidelines: no offensive material or spam.
3. Berteig Consulting Inc. will own the copyright on all anonymously submitted entries.
4. If you sign your name to your entry, you will retain copyright but grant Berteig Consulting Inc. unlimited non-exclusive use of the contents.
5. Go ahead and include self-promoting links, affiliate links, etc. as long as they are on-topic.

Have Fun!

Posted by Guest at 11:49 AM | |

Salutogenesis and Agile

Twenty-five years ago American-Israeli Medical Sociologist, Aron Antonovsky developed the theory of salutogenesis. As opposed to the traditional pathogenic model of medicine focused on the study of disease, salutogenesis is the study of health. Since then, his work has been integrated into the field of public health and health education. This asset or strength based type of approach to individual or institutional development has been found in other fields such as organizational development and community development. In organizational development the field of Appreciative Inquiry and in community development the Asset Based Community Development model share the essential premises of salutogenesis. Quoting Garmezy, Antonovsky highlights the medical professions focus on deficits:

our mental health practitioners and researchers are predisposed by interest, investment and training in seeing deviance, psychopathology and weakness wherever they look.

This type of approach to work based on weakness and deficit can be found in most of our organizations. It seems to me that although Agile exposes inefficiencies and problems in organizations, it's focus never-the-less is to build on strengths and assets. It is in this light that I have been thinking about Antonovsky's work and what it can offer to Agile.

Antonovsky came to this theory of salutogenisis when he carried out a study on Israeli women going through menopause. He found that there were a number of women who, according to all indications of the pathogenic model, should be suffering severe symptoms (because they faced severe stressors which cause illness). But they were not suffering at all. To his surprise he discovered that these women happened to be survivors of concentration camps. He found certain qualities in these women that resulted in what he called a higher “Sense of Coherence” than the other women.

Sense of Coherence is made up of three factors; comprehensibility, manageability, and meaningfulness.

Comprehensibility means that whatever happens to a person, she is able to make sense of it and understand it, that is, the challenge is in some way "structured, predictable, and explicable." Manageability means that either the resources are available to one to meet the demands posed by the stimuli,or one has a way to find them. Meaningfulness involves having a sense of meaning in the important areas of one's life or recognizing "these demands are challenges, worthy of investment and engagement."

Antonovsky found meaningfulness to be the motivational factor of the three, although he also found that all three mutually reinforce one another. For example if one has a high sense of comprehensibility but is low on the other two, one ends up not having the motivation to find resources and soon after this causes comprehensibility to be lost. If one is high on meaning and missing the other two, Antonovsky explains that there is a good chance to find the other two.

The theory of Salutogenisis may provide researched and proven reasons why Agile is so empowering for people. This research may also provide more insight into how to deepen Agile experiences to higher levels of empowerment. Agile methods help people to make sense of the market place by allowing for iterative delivery and adaptive planning, thus increasing their level of comprehensibility. Iterative delivery, adaptive planning and the concept of amplifying learning are all conducive to increased sense of manageability. Because people spend most of their time at work, it is quite important that they feel a sense of meaning in their work. The concept of empowering the team and the practice of self-organized teams and appropriate metrics can contribute to increased sense of meaning in one's work.

Salutogenic food for thought for the Agile practitioner:

Antonovsky associated comprehensibility with consistency which he defined as "the extent to which one’s work situation allows and fosters the clarity of seeing the entire work picture and ones place in it, provides confidence in job security, and supports communicability and feedback in social relations at the workplace".

How can the concept of consistency be promoted in Agile projects?

Manageability is related to under load/overload balance which is defined as "the availability of resources to the individual and to the collectivity within which there is interaction to get the job done well" and "...the extent to which the work situation has room for allowing potential to be utilized in substantively complex work." The opposite of the former results in overload and the opposite of the latter is a situation of under load.

How can Agile projects guard against overload? How can an Agile coach and Agile teams fully utilize the capacities of its members?

Meaningfulness is closely associated with participation in shaping outcomes. Antonovsky explains beautifully the relationship between these two concepts:

When others decide everything for us-when they set the task, formulate the rules, and manage the outcome-and we have no say in the matter, we are reduced to objects. A world thus experienced as being indifferent to what we do comes to be seen as a world devoid of meaning.

In light of the concept of meaningfulness how can the principle of self organized team and shared decision making be deepened in Agile work?

Reference:
Antonovsky, Aron (1988). Unraveling the Mystery of Health: How People Manage Stress and Stay Well (Jossey Bass Social and Behavioral Science Series)

Posted by Shabnam Tashakour at 07:50 AM | |

November 14, 2005

Call for Contributors

I'm looking for two people to volunteer to write about Agile for this site. In particular, I'm interested in stories about Agile being used outside of technical fields and Agile being used in management. Of course, if you have a burning desire to write about something else, please let me know: mishkin@berteigconsulting.com.

Terms:
- You get to use any name or alias you wish, your authorship will be listed with each blog entry, and each entry you submit will link to a web page or email address of your choice.
- You can include in your entries affiliate links for specific products related to your entry.
- If you become a regular contributor (more than two entries per calendar month), I will include a link to a web site of your choice on the front page.
- Entries are subject to editing or removal for any reason whatsoever. In general, if you are writing about something related to Agile, Teamwork, Process, Management, Learning, Community you should be okay. If I remove your entry, I will keep a backup copy of it.
- You will not be paid by Agile Advice, Berteig Consulting Inc. or any affiliated web sites, companies or individuals for your entries submitted. You give Berteig Consulting Inc. a non-exclusive unlimited license to publish your entries to the Agile Advice web site and any derived works.
- You must provide a permanent link from a web page of your authorship and choosing to the front page of Agile Advice.
- Any questions you have about these terms should be directed to Mishkin Berteig by email: mishkin@berteigconsulting.com.

Posted by Mishkin Berteig at 02:34 AM | |

Agile Work Axioms - Discussion

It's taken a while to get the phrasing for the Agile Work Axioms to the point that it is currently at. I've had personal conversations, one-on-one with a few people that I trust in order to see if what I have written makes sense. But the time has come to ask you, dear reader, for help.

I am trying to formulate a really simple way of describing the underlying assumptions and beliefs about life, the universe and everything that are driving the success of Agile. Right now I have this:

Agile Work Axioms:
We are Creators
Reality is Perceived
Change is Natural

I've written just a bit more than that and it can be found at the Agile Work Axioms web site.

What do you think? Do these relate well to what we find in the Agile Software Development Manifesto (notice the "software development" stuck in there... I'm hoping the Agile Work Axioms apply to other types of work besides software development)? Is there anything missing? Do these make sense? Why?

Posted by Mishkin Berteig at 02:11 AM | |

November 12, 2005

Agile Work Business Case - Pragmatic Reasons for Using Agile Work

Time to market/process cycle time is improved, possibly to reducing the time to that of a single iteration. This reduced time to market can produce an incredible competitive advantage both by increasing an organization's ability to respond to change and by proactively instigating change that other organizations will not be able to respond to adequately.

Using Agile Work practices and focusing on Agile Work disciplines improves the chance of projects being delivered under budget. In fact, the whole notion of budget becomes meaningless when agile projects are delivering incredible value incredibly quickly. Profit-oriented organizations will see their budgets expand as their profit grows and non-profit organizations will see the value they deliver grow far beyond expectations with a constant budget.

Stakeholders, in particular end-users have ownership of the solution and are more likely to accept it. Whatever system or result Agile Work is used to create, that result will have very low levels of waste due to non-acceptance. This is also a reduction of the risk that the wrong solution or a poor solution is delivered.

Improvements in staff development and retention by providing a positive learning culture. In some industries and sectors staff turnover is a major expense or source of waste. Agile Work is interesting, exciting and satisfying. People who have experienced Agile Work actively promote it and seek it out because it creates a situation where their talents are valued and used effectively. Adopting Agile Work will attract talented team players to your organization.

Posted by Mishkin Berteig at 09:09 AM | |

November 11, 2005

Agile Planning

I recently read a great little article about agile planning by Martin Fowler. I find that one of the more difficult tasks to do early on in an Agile project is to get the team to as a whole, take responsibility for the amount of work taken into an iteration. Often, individuals will take on work that is role-specific (e.g. Dev work) without consulting the whole cross-functional team and the product owner.

I haven't read it yet, but I suspect that Mike Cohn's new book, Agile Estimating and Planning, might have some excellent ideas about all this.

Posted by Mishkin Berteig at 08:54 AM | |

November 10, 2005

Agile and Defined Processes

People who are organizationally minded, or who are risk adverse often have difficulty understanding the benefits and safety afforded by Agile as opposed to defined processes. This often manifests in a desire to standardize tools or processes so they become defined.

For example: an organization may wish to standardize on a spreadsheet template to use for iteration backlogs for all Agile teams. This seems innocuous. While I understand the desire to standardize, I believe even doing this would be detrimental to an organization. Some Agile teams may not use spreadsheets at all. In fact, using spreadsheets is considered a last resort used only if you have an extremely complex project. Generally speaking, user story and task cards along with a burndown on a white board are meant to be sufficient. Standardizing on spreadsheets would _impose_ process where it is not necessary and would be taking us all back along the path of a non-agile approach to projects.

In one instance where I have coached, we did in fact use a spreadsheet because we have up to 300 tasks per team per two week iteration. It would have been very difficult to manage all these tasks manually. Additionally, we customized our spreadsheet to work for our circumstances which are unique. Agile specifically encourages the values of simplicity and adaptability. I am perfectly happy to share our spreadsheet for other people to learn from, but the whole notion of standardizing the spreadsheets seems to be against agile principles. Think of it this way: would anyone be happy if an organization decided that everyone needed to drive the same car to work? Each person's car serves their own transportation needs. In exactly the same way, each team's spreadsheet/whiteboard/cards serves their needs… and not necessarily the needs of anyone else. It is true that everyone needs transportation, and in the same way an organization needs every team to track their user stories and tasks, but how exactly it is done should be left up to the teams.

Posted by Mishkin Berteig at 02:35 PM | |

November 09, 2005

Agile Work Uses Lean Thinking - Empirical Process Control

This is Part 2 of a 3 part series.
Part 1
Part 3 - not posted yet :-)

Some work processes cannot be perfectly controlled nor perfectly defined. There may be non-linear interactions between steps in a process or there may be creative input from a human required. Processes with these qualities require empirical process control.
The basic attribute of empirical process control constitutes a continuous cycle of inspecting the process for correct operation and results and adapting the process as needed. A simple example of this is detecting impending failure of equipment by constantly monitoring the operation of that equipment. For Agile Work, the book Agile Software Development with Scrum provides an excellent chapter about this topic of Empirical Process Control.

In human processes like those to which Agile Work applies, the frequency of inspecting and adapting must match the needs of the process. Many projects occur in the context of constant change. This constant change makes long-term planning a wasteful effort. Rather, short-term planning with constant feedback provides a simple inspect and adapt cycle. This cycle can play out at different levels: daily for a team, monthly for a client of the team. The team inspects and adapts daily at the level of the tasks that it is performing. The client inspects and adapts monthly at the level of the team's actual delivered results.

Both lean and agile methods claim to increase both speed and quality. Many people believe that there are four constraints in a system that can be controlled: speed (or schedule, or time to market, or process cycle time), quality (number of defects), scope (how much functionality), and cost savings (how much to spend on the work). Frequently, management believes that one has to trade off between these four constraints; spend more money, get more scope; lower quality, go faster. But in fact, lean and agile strongly support the idea that as you increase quality, you also increase speed... you just have to do it right.

In Agile Work, increasing speed and quality is done in three ways. First, increase the frequency and quality of communication among team members so that errors are detected early or avoided altogether. Second, drive the work with the creation and execution of automated testing. No work is done without a test in place to check if it is done correctly. This constant testing means that work is always defect-free and therefore very little time/money is spent on fixing defects. Third, eliminate wasteful work steps or obstacles to performance of work. This last one is difficult to do an bears closer examination.

Wasteful work is done in every process, no matter how efficient. Lean tells us that there are several types of waste in a manufacturing process. Those types of waste have analogies in Agile Work. For example, documenting something you plan to do instead of just doing it is wasteful. Another example is waiting while someone completes work that you depend upon. Any step or task that does not add value to the final product of an effort is waste. This standard is very high and most organizations have about 80% of their efforts going into wasteful tasks. An organization that has done an initial cut of wasteful work might stand at about 50% waste. The leanest organizations, such as Toyota, stand at about 20% waste.

Agile work eliminates waste in the form of barriers or obstacles that come up when a team is trying to go fast. Sometimes this is in the form of waiting for another group to do something for the agile team... an outsourced request for service. Sometimes waste is in the form of corporate standards or policies around documentation of work. The Process Facilitator role in an agile team has responsibility for working with the team and others to help overcome these obstacles.

Posted by Mishkin Berteig at 02:08 PM | |

November 08, 2005

ScrumMaster Certification Course for Software Project Management

Berteig Consulting Inc. is offering a ScrumMaster Certification course on Dec. 28 and 29 in Toronto, ON. This course is focused on software and IT projects, but will cover many of the basic Agile Work principles and practices. This is always a slow time at work and if you have already used your vacation time, consider getting your employer to send you to this course.

Posted by Mishkin Berteig at 10:38 PM | |

Retrospectives

First, a link: Retrospectives.com. From the site, the Retrospective Prime Directive:

Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.

Today I assisted a fellow-coach, Deborah Hartmann with a retrospective for a team that she is coaching. Deb is actually coaching two teams in a program and couldn't be with them both at the same time. She introduced me to a very simple yet pleasant and effective method for retrospectives. I am not sure of its ultimate source, but it was introduced to Deb by Michael Spayd. Here is the basic outline:

Materials: pad of largish PostIt notes, large pad of poster-size paper, marker, pens for everyone

Set up in a space where everyone can see each other and the poster pad.

Step One: get everyone's attention, organize around the table, turn off laptops, put cell phones on buzz, and state ground rules: no interrupting each other, and that this is not a discussion until you (the facilitator) say so
Step Two: display and recite the cardinal rule (above) and the purpose of the retrospective
Step Three: What Went Well?
- everyone takes three PostIts
- write down on the PostIts what went well (technical, team, organizational, process, general or specific)
- facilitator puts them on the poster in a way that they are not visible to the group
- facilitator reads them all out in random order with no comments
- facilitator gets the group to brainstorm (no criticism) on themes of what went well and writes them down for all to see
Step Four: What Needs Improvement?
- repeat Step Three
- vote on the importance of the themes and chose the three most important to discuss
- facilitate discussion to generate action items for making improvements based on the three most important themes

Posted by Mishkin Berteig at 07:36 PM | |

November 07, 2005

Agile Practices for Disability Planning

I just found a very interesting presentation about using Agile Work to do planning for programs for people with disabilities. I didn't understand everything in the presentation because the field is something that I am not familiar with, but it appears that someone has taken Agile from IT and applied it to social and economic development programs for disabled people.

Posted by Mishkin Berteig at 06:14 PM | |

November 04, 2005

Agile Work Uses Lean Thinking - Queueing Theory

Queueing theory describes the statistical and theoretical behavior of queues. In a queue system, there are two basic parts: work items and worker units. Worker units perform some work upon work items. The streaming of work items through worker units composes a queueing system. The time it takes for a work item to enter the system to exit the system is the process cycle time. From the study of real queueing systems and from simulation of queueing systems, researchers have shown there are some simple methods for creating an efficient queueing system that minimizes process cycle time.

One method for making a queueing system more efficient relates to the size of work items and how this relates to worker unit utilization levels and process cycle time. Queues behave in a very interesting way in relation to utilization and process cycle time. As utilization of a worker unit approaches 100%, process cycle time goes up very quickly. Not only that, but the more variability there is in the size of the work items, the worse this effect becomes. With a queue with work items that are all the same size, the worker units can maintain a very high level of utilization and the process cycle time is not significantly affected. However, with a queue with work items that are many different sizes, a worker unit will slow down significantly and process cycle times become worse even with relatively low levels of utilization.

Lean and Agile both use these ideas. Lean applies these ideas to manufacturing and other production processes and Agile applies these ideas to project work.

In Agile, iterations are used to create consistently small sized units of work that are then taken on by a team. In other words, the work items are designed to be exactly the size of an iteration and the worker unit is the Agile team. Since iterations are typically much smaller than the size of the overall project and since each iteration is always the same size, this allows the team to achieve very high levels of utilization while maintaining extremely short cycle times (the length of the iteration or release). Compare this to the waterfall approach to project management where the work is only finally delivered at the very end of a long process and you can see that not only do you have a very long cycle time, but each project will be highly variable in size and therefore it will be hard to get good utilization out of teams (think resource planning and leveling).

The Theory of Constraints, which is nicely introduced in The Goal by Eli Goldratt, presents some additional basic techniques for making improvements in efficiency of a process. The basic idea is that one can always find a slowest point or constraint in a process by finding out where there is a buildup of unfinished work. For example, if two people are cleaning a kitchen, one washing dishes and the other drying, if the number of wet washed dishes keeps building up, then the constraint for the process is the person drying. In more complex processes either in manufacturing or in creative work such as software development, it is sometimes more difficult to see where the constraint is. Typically, if you find that you have people waiting for work that is coming from someone else, then that someone else is a constraint and means can be found to improve their efficiency. In Agile, the focus on resolving the constraint would be to provide that person extra training or get other members of the team to assist in the work. Agile tends to shy away from a mechanistic perspective on efficiency.

Finally, in any queueing system there is some point at which work enters the system. This point of entry is very important because it can be used to control the utilization levels of worker units in a queue. In Agile Work, this control is accomplished through backlog management, iterative delivery and adaptive planning. All possible requests, features, constraints, improvements for a project are put into a master Work Item List. This list is strictly prioritized in descending order by a person empowered with this responsibility (called the Product Owner). This list of work items becomes the basis for deciding what work the team will do each iteration. The process of managing this list and how the work is chosen for this iteration allows the customer/client to prioritize important things to be delivered quickly and allows the team to work on consistently sized work units (iterations) and therefore achieve very high levels of utilization. In queueing theory this process is referred to as the gating function in that it provides a gate that lets work items into the system. All work must go through this gate or work item list management process in order for the team to function effectively. If the team is interrupted with work that has somehow skipped the gate it will seriously reduce the efficiency of the team(e.g. a senior sales person comes to the team and declares that it must work on X, it'll only take a day, a potential client really needs this, surely that won't hurt?).

Posted by Mishkin Berteig at 01:44 PM | |

Carnival of the Agilists for 2005/11/03

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 | |

November 02, 2005

Iteration Progress Information Radiators

A fellow agile coach pointed me to this great little article about burndown/up charts. It has some nice drawings of alternatives to the basic simple burndown that most teams start with.

These alternative forms of burndown attempt to provide more information about the status and history of an iteration basically by providing a means to update the "baseline" estimates. The advantage of doing this is that it allows for easier discussion of when and why new work was discovered. As well, it maintains the existing advantage of a burndown with its clear focus on getting to done by the end of the iteration.

Posted by Mishkin Berteig at 01:03 PM | |

Redistributing Work Among Teams - Simple Self-Organization

I coached a long-running program with at times up to 8 teams, 6 of which were running as agile teams. We used a program-level status meeting daily to do "official" coordination among teams.

Early on in the program, one of the team members who was maintaining the backlog for the iteration came to me and told me that Team 4 was done their work ahead of the end of the iteration and Team 3 was struggling to get their work done in the iteration. As the Process Facilitator I got this person plus members of the two teams together to have a quick 2 minute disucussion about the problem (T4 running out of work). They quickly worked it out amongst themselves and then let the other team member know so that he could maintain the backlog by redistributing the work items and tasks. The two teams easily fixed the problem and the iteration ended successfully.

If you have worked in a highly bureaucratic environment you will know that it can be extremely difficult to adjust plans to allow this sort of on-the-fly rebalancing of work. In chaotic environments, on the other hand, it is just too difficult to see these sorts of opportunities for rebalancing in the face of constant crisis and "heroic" efforts by people on the teams. Agile Work and the process facilitator provide a balanced context in which this adaptability and self-organization can flourish.

Posted by Mishkin Berteig at 08:37 AM | |

November 01, 2005

Mishkin Berteig attains ScrumMaster Training Designation

Mishkin Berteig, the founder of Berteig Consulting Inc. and a principal contributor to the Agile Advice blog has been listed on the Control Chaos web site as a Certified ScrumMaster Trainer. This certification represents acknowledgement of Mishkin's ability to deliver the ScrumMaster certification course. Scrum is a collection of management patterns used to implement agile principles and practices for software new product development.

Posted by Mishkin Berteig at 09:28 AM | |

Agile, Cognitive Scripts and Diversity

Steve L. Robins, Professor and Diversity Trainer speaks about Unintentional Intelligence:
M1 (mindlessness) + M2 (multiple redundancy messages) = UI (unintentional Intelligence)

He explains that cognitively we can only do one thing at a time. Our brain writes cognitive scripts for what we do, so we can be efficient by not having to spend time thinking carefully about everything. We do this for anything from breathing, brushing our teeth and driving. We have very good cognitive scripts for complex tasks.

M2 (multiple redundancy messages

Because of this state of mindlessness, if we get the same message over and over again we have no defense against it. We can brand products, concepts, professions (i.e. a nurse is a woman a doctor is a man)... we brand people, race. We can get 13 year old girls to want to kill themselves because they are not thin enough.

Robins did the following experiment with us to demonstrate this point: He told us to repeat the word “top” ten times and after the tenth time he asked us the following question, which we were supposed to answer without thinking: “What do you do when you get to a green light?” We all said stop. He went on to point out that if with such a simple exercise he could get us to give the wrong answer, when we all knew the right answer, then a lot of different kind of beliefs about different races can also affect us even if they are not true.

Robins went on to talk about how to change these pattern: Neurons in the brain are connected by synapses, every time we act the body releases a protein in the synapses that when repeated solidifies the pattern down in our brain. In order to form new patterns a person has to have a chance to practice that pattern over and over again.

In our working cultures we have all kinds of cognitive scripts related to how we see and value diversity and these are formed partly by the multiple redundancy messages sent to us by our culture, our own lack of knowledge and experience of different perspectives and ways of seeing the world (because we tend to naturally associate with people who are like us) and our organizational culture that generally tends to value a certain kind of personality over another.

So what does this have to do with Agile? Well, so much of agile is about innovation and amplifying learning. Corporate cultures are not typically examples of thriving places that value diversity (and I don't mean just having affirmative action programs, but beyond that, having a working culture that allows people to bring their diversity into the work place and rewards it). Diversity is a direct challenge to our mindless orientation towards work. It can challenge us to be more mindful, and mindfulness is an important basis of amplifying learning and being innovative.

I find the concept of cognitive scripts a helpful one for my own approach to Agile Work. Part of the work of a Process Facilitator is to help people to become conscious of their cognitive scrips, nurture diversity in the group so that cognitive scripts can be challenged to give birth to innovation. The key to this kind of change is for the Process Facilitator to work closely with team members to create repeated opportunities for this kind of interaction so that new cognitive scripts can be written.

It is helpful for the Process Facilitator to work with team members to reflect on the relationship between multiple redundancy messages as they relate to Agile Work. For example when starting an Agile project, beginning by reflecting on the fact that Agile Work transforms our competitive orientation towards work into a collaborative orientation. An examination of the multiple redundancy messages we receive in popular culture and corporate culture about these two orientations may be very useful for team members to become conscious of, if they are to make this shift in thinking and practice. As an exercise, a Process Facilitator could simply ask the team to list examples of corporate and media messages that support competition and those that support collaboration.

Posted by Shabnam Tashakour at 08:08 AM | |