Agile Advice

September 24, 2007

Agile Benefits: Five Essential Reasons to Try Agile

Although there many other benefits of agile, and although those provide us with other reasons to try agile, the five essential benefits of agile are:

Rapid Learning - disciplined application of the scientific method to explore the best ways to deliver valuable results.

Early Return on Investment - opportunity to use the results of work starting with the work delivered at the end of the first iteration.

Satisfied Stakeholders - engagement in the process in a way that allows meaningful contributions from all stakeholders.

Increased Control - mechanisms to track/measure and therefore steer the direction that work is going so that it meets goals.

Responsiveness to Change - processes, tools, roles and principles that allow a team and an organization to embrace change rather than reject, control or suffer from change.

These reasons are sufficient and apply to operations work, project work and open-ended research work, whenever humans are involved. The above links take you to more detailed descriptions of each of these benefits.

What are some of the other benefits of agile?

Posted by Mishkin Berteig at 10:47 PM | |

February 27, 2007

Interesting Quote

I couldn't find this anywhere with my few Google searches, so if anyone knows where this is from, please let me know:

The bitterness of poor quality lasts longer than the sweet taste of meeting a deadline

Posted by Mishkin Berteig at 12:02 PM | |

January 02, 2007

Top Ten Most Popular Entries from 2006

If you are new to Agile Advice, these are not just some of the most popular articles, they are also some of the best! Take a look around; you will find ideas to inspire you, challenge your thinking and maybe that one little thing that will make the difference in applying agile methods in your situation.

1. How Two Hours Can Waste Two Weeks - 25,617 unique views
This little hypothetical story by Dmitri Zimine was very popular on Reddit, and Joel on Software ranted a bit about it.

2. The Case for Context Switching - 2,936 unique views
My rebuttal to Joel's rant. Goes well with Dmitri's article. Emphasizes the idea of building trust in an organization.

3. The Qualities of an Ideal Test - 1,579 unique views
Six qualities that will help make your tests as valuable as can be. Similar to the ACID properties of databases or the INVEST properties of user stories.

4. The Pros and Cons of Short Iterations - 1,555 unique views
A few words that will help you decide how long to make your iteration length. This is an important decision, and most teams and organizations don't know the factors involved.

5. Five Signs of Trouble in an Iteration - 1,489 unique views
A good howto on using burndown charts to discover problems in an iteration.

6. Seventeen Tips for Iteration Planning - 1,427 unique views
A good list of hints and tips that can make the difference between struggling with iteration planning and having it go smoothly and effectively. This is a key part of the Agile Work process, so getting good at it is a high priority for any team new to Agile Work.

7. Change is Natural - "Embrace Change" - 1,397 unique views
A short riff on the universality of change. Also introduces the idea of the "horizon of predictability".

8. The Art of Obstacle Removal - 1,287 unique views
This is a good reference article on types of obstacles and methods for removing them... a critical practice for Process Facilitators.

9. The Seven Core Practices of Agile Work - 1,285 unique views
Agile Work is really quite simple. This is a concise list of the practices that make up this effective methodology.

10. Interview with Alistair Cockburn - Agile and House Renovations - 902 unique views
Applying agile methods to home and garden renovations! Learn a bit about how this luminary of the agile world has taken agile practices out of the software world and into the hardware world.

Posted by Mishkin Berteig at 06:32 PM | |

My First Iteration Planning

I've done my iteration planning for my first iteration called "Beginnings". The length of my iterations is one week (including weekends). Here is the list of backlog items that I have committed to (some detail removed):

Catch up on Scrum course follow-up work
Advertize future courses
Finish eBook 2nd Draft
- email request for feedback return
- go through feedback
- finish references
- finish diagrams
Invoice
Finalize India Trip
Interview (Tuesday)
Meet up with and co. (Sunday)
Continue development work for

I have broken all of these into tasks, but only put here the ones for finishing my eBook since the rest get into lots of private detail.

I'm currently using TiddlyWiki to track my Work Queue, my tasks and my recurring/scheduled duties. I create a new wikiword for each iteration and copy items from the Work Queue into that section. I also have a menu that has links to my daily, weekly and monthly tasks.

I'm not doing any estimation on either Work Queue items or tasks. This may become a problem, but for now I'm going to try doing the work without the estimation overhead.

I also spoke with my wife, Melanie who is my business partner about all this. She agrees that using Agile Work is a good step to take and looks forward to all the benefits of my being more organized :-)

Posted by Mishkin Berteig at 12:05 PM | |

December 18, 2006

Lean, Agile and Capitalism - Just a Thought

It occurred to me to ask: If the "invisible hand" in the free markets of capitalism is making for efficient markets, efficient work... then why is there some much room for improvement when we start using non-competitive, collaborative techniques such as lean and agile?

And if these collaborative techniques work on a small scale to improve efficiency, does this mean that we could do this across organizations as a "replacement" for capitalism somehow?

In agile methods, we "assume positive intent" on the part of individuals. What if we could do this across organizations? I'm not living in a dream world yet, but I think I have an inkling of what it might look like: Toyota and its collaborative, leaned-out supply chain.

Posted by Mishkin Berteig at 06:39 PM | |

November 15, 2006

The Case for Context Switching

Recently, Dimitri Zimine wrote an excellent little story about context switching. Joel Spolsky writes in "From the 'You Call this Agile' Department":

Dmitri is only looking at one side of the cost/benefit equation. He's laid out a very convincing argument why Sarah should not interrupt her carefully planned two week iteration, but he hasn't even mentioned arguments for the other side: the important sale that will be lost.

Okay... I'll bite.

Let's look at that argument from the perspective of the sales person first since that is where Joel's concern starts:

The Sales Guy Perspective

"I need the 'ezhibal' feature now! Big bucks coming soon if we can get it now."

Let's suppose that this urgent email has come in somewhere near the start of our two week iteration. The normal response to this in Scrum is to push back a little. The ScrumMaster says something to the effect of: "Look if you wait 7 days we can put this on the top of the list for our next iteration."

First reaction, and it's a normal one, is for Sales Guy to freak out. I've actually heard people saying things like "You're going to lose your job over this! I'm getting the VP involved and he's not going to like it" and then they stalk off to find the big dog to come and bark at us. Anyway, let's pretend that the Sales Guy is willing to be reasonable and not instantly escalate the "problem". So what he actually says is: "Look, this is super important, it'll probably only take a few minutes for us to talk about it and then we can figure out how long it will take to fix. Let's just do a quick phone call and yadda, yadda, yadda, blah dee blah..."

---

Enough of the Sales Guy perspective.

Nowadays, if I'm in this situation, I do a value assessement. I tell the team to keep working on their plan, nothing's changed yet, and I sit down with Sales Guy and the person who's sponsoring the current work and we start a discussion about the options of which there are really only two that work in Scrum:

1. Stay the Course
2. Cancel the Iteration

First, let's talk about how we decide which option to take. Then we'll talk about why.

Deciding on the option is easy. You look at the value of the work currently being done and compare it to the value of the work that Sales Guy needs. You take into account probabilities. If Sales Guy doesn't have a signed contract, then it's hard to day if there's going to be any real revenue from the 'ezhibal' feature. Still, you might be able to do an assessment of the probabilities based on your level of trust and history with the client, etc. You also need to take into account the time value of money. Does delaying the current work have consequences for another client or stakeholder? What is the cost of those consequences.

This is a relatively simple cost/benefit analysis and comparison. If you're not comfortable with money and numbers and spreadsheets, you better get comfortable!

---

Okay, so we have a way of comparing the two bits of work. Now let's look at the two "allowed" responses and a third "bad" response.

Stay the Course

Turns out that the potential benefit of the stuff Sales Guy wants is not quite as high as the potential benefit of the stuff that Suzie Stakeholder prioritized for the current iteration. Well, that's easy. Put the request from Sales Guy in our prioritized list of work and get to it when there is an appropriate level of benefit relative to the other work.

Cancel the Iteration

The stuff Sales Guy wants is super-valuable. So let's get the whole team to stop what they are doing and everyone supports this very valuble work. Stopping the whole team is appropriate because obvioulsy, the stuff they're working on isn't as valuable. Oh, and because we treat a team as a unit in Scrum. And because the team needs to commit to work, not individuals. This isn't so obvious... more later.

Peel Sarah off to do the 'ezhibal' Feature

This is what normally happens, and in a "normal" non-agile environment, it's probably okay. In a non-agile environment, Sarah hasn't made any commitments (she's been forced to agree to dates and scope, etc., but she hasn't made a commitment that she is empowered to live up to). So if she goes off and does this one little thing, it probably will be just business as usual. In an agile environment, the team has made a commitment and doing this work this way invalidates the team's commitment.

---

Why do we do it this way? The main reason is around trust and commitment. Yup, it's that soft icky stuff that we're so incredibly bad at that customers think that bugs are normal, that management shoves the kitchen sink into projects in the frustrated hope that they'll get something out of the IT team at the end of the project. Sound familiar to anyone?

Anyway. An iteration is a commitment. It is a firm and solid commitment. The team as a group of smart and honorable people is making a definite commitment to the rest of the organization to get a certain amount of work done in a fixed amount of time. In return, management is agreeing to give the team every support in reaching this commitment. When a team is new at this, they might get it wrong. But having done this with dozens of teams now, I know that after a few tries, the team gets the hang of it and commits to appropriate amounts of work, and management provides appropriate levels of support.

This commitment is essential for developing trust. And anything that comes in the way of the team meeting its commitment is considered "BAD". An obstacle to do away with.

This is interesting, because Joel's second example is about defects. And I strongly agree that defects are "BAD" and need to be dealt with at a very high level of priority. The reason is simple: they prevent a team from meeting its commitment.

---

One team I was coaching was constantly bombarded by these types of it'll-just-take-a-few-minutes-need-it-asap requests. They had many stakeholders and very very limited resources to service these requests. They had several small projects that were taking literally years to do because they couldn't get enough concentrated time on any one thing. This was considered normal and good in their environment.

The trouble is, no one had really looked at the overall consequences. Everyone was doing local optimization. For us geeks, we all know that local optimization is something to be avoided if possible. We climb a peak only to discover that we have to climb back down a ways to get up to the higher peak we now see is next to this one. We climb up that one only to discover yet another higher peak even further along thus requiring us to climb down and up again... When really what we should have done is stepped back a ways, looked at the lay of the land and said, "hey, that peak over there is the highest of them all, let's go climb that one."

Scrum helps us avoid local optimization by forcing all feature requests for a team to be prioritized in a list of work, and by allowing the team to complete small pieces of work so it actually gets _something_ done that you can learn from.

---

Joel said:

Agile is not supposed to be about swapping out one set of bureaucratic, rigid procedures for another equally rigid set of procedures that still doesn't take customer's needs into account.

True enough! But it also demonstrates a serious lack of understanding about what is being done in Dmitri's example! First of all, without being agile at all, it is possible to switch from 18 month projects to two week projects. Both can be bureaucratic as you please (well, actually, there's only so much bureaucracy you can cram into two weeks and still get something done). The shorter projects will allow you to be much more responsive to customer needs... by definition!

So what happens when you add in all the other things that agile really is about? Transparency. Truthfulness. Creativity. Learning. Meta-Learning. Prioritization. Self-Organizating Teams. Eliminating Waste.

Well, first of what you get is something that's damn hard to do right. It goes against almost everything we've been taught to do: the extreme of heroics of the extreme of careful planning and process.

Secondly, what you get is something that needs safety zones and meta-rules. Like mutual, freely-given, team-to-stakeholders commitment. Like assuming positive intent.

And thirdly, what you get is an environment where not only is the business getting what it needs more than it used to, but also, the team likes working with the business, and the business likes working with the team.

---

I admit that the point Joel is making isn't too different. Yes: look at the costs and the benefits. But agile isn't quite about instantaneous responsiveness. That's a red herring and I'm suprised that Joel threw it's stinky carcass into the discussion. Agile is also about balancing that responsiveness with the overall view of value for the team and the organization. The tool for doing that is the prioritized list of work, not the email message from Sales Guy to Sarah.

Posted by Mishkin Berteig at 04:13 AM | |

April 20, 2006

An Introduction to General Systems Thinking

I recently completed reading An Introduction to General Systems Thinking by Gerald M. Weinberg. Since it was mind-blowingly fantastic, I thought I should probably write a brief review of it so you-all can check it out!

The Subject

This book is about science, philosophy, behavior, organizations, organisms, problems, solutions, faith, reason, and everything in between. Specifically, it is about a general approach to dealing with systems given the limitations of our human abilities.

The Ideas

One of the strongest ideas in the whole book is that there is a class of systems for which we have only very poor tools to understand them. These systems, which he calls "organized complexity" are contrasted to "organized simplicity (machines)" and "unorganized complexity (aggregates)". Machines can be dealt with purely analytically and in a deterministic manner. Aggregates can be dealt with statistically. Systems that are in the organized complexity category are too complex for a purely analytical approach but too simple for a reasonable statistical analysis. The book is focused on methods for dealing with this class of systems.

The Writing

Mr. Weinberg's writing is, first and foremost, engaging. He writes in an informal voice that is a wonderful complement to the subject matter. Even with the informal tone, he is nevertheless able to communicate some tricky ideas with a great deal of precision and clarity. His use of examples, diagrams, stories and quotes throughout the book is excellent. Although I did not do the exercises he includes, upon reading them, I was satisfied to see that they are all interesting. Since I intend to re-read the book in six months or so, I will also publicly commit to doing a good chunck of the exercises too. Maybe you'll see some of my efforts here since many of them are apropos to Agile Work.

How Does This Apply to Agile Work?

Much of the emphasis in agile methods is on the intractability of building a perfect plan for a set of work (particularly in software projects). The group of human beings that are building something is in itself a system of "organized complexity". As a result, it is impossible to treat that group of people as a system that can be made to work in a deterministic manner. We simply can't account for all the variables. At the same time, we would like to have a lot more certainty about the behavior of the group than we could just using statistical methods. (Check out Systematic HR for some related articles.) Agile methods help us find this middle way that gives us a very good shot at reaching our goals, but acknowledges our inability to determine precisely how we'll get there. A good understanding of Systems Thinking helps us comprehend the necessity and applicability of agile methods.

The Table of Contents

The chapter and section titles of this book tell a great deal about the scope of the work. I have reproduced the table of contents here for your reference.

Chapter 1 The Problem
- The complexity of the World
- Mechanism and Mechanics
- The Square Law of Computation
- The Simplificiation of Science and the Science of Simplification
- Statistical Mechanics and the Law of Large Numbers
- The Law of Medium Numbers

Chapter 2 The Approach
- Organism, Analogy, and Vitalism
- The Scientist and His Categories
- The Main Article of General Systems Faith
- The Nature of General Systems Laws
- Varieties of Systems Thinking

Chapter 3 System and Illusion
- A System Is a Way of Looking at the World
- Absolute and Relative Thinking
- A System is a Set
- Observers and Observations
- The Principle of Indifference

Chapter 4 Interpreting Observations
- States
- The Eye-Brain Law
- The Generalized Thermodynamic Law
- Functional Notation and Reductionist Thought
- Incompleteness and Overcompleteness
- The Generalized Law of Complementarity

Chapter 5 Breaking Down Observations
- The Metaphors of Science
- Boundaries and Things
- Qualities and the Principle of Invariance
- Partitions
- The Strong Connection Law

Chapter 6 Describing Behavior
- Simulation - The White Box
- State Spaces
- Time as a Standard of Behavior
- Behavior in Open Systems
- The Principle of Indeterminability

Chapter 7 Some Systems Questions
- The Systems Triumvirate
- Stability
- Survival
- Identity
- Regulation and Adaptation
- The Used Car Law

---

Also, check it out, Mr. Weinberg has started a blog on writing fiction. He also helps run the AYE Conference (amplifying your effectiveness).

Posted by Mishkin Berteig at 05:18 PM | |

April 12, 2006

Follow the Principles and Adjust the Practices

In "Built to Last : Successful Habits of Visionary Companies" Jim Collins repeatedly emphasizes that long-lasting successful companies have a very single-minded focus. But that focus is not stupid or blind. Rather, Collins uses the phrase "Preserve the core / stimulate progress". This is also the essense of agility.

Follow the Principles

What exactly are the principles? The foundation starts with Trust and Truthfulness. "Truthfulness is the foundation of all human virtues." Everything we do with agile should be about truthfulness (visibility, transparency) and building trust.

With this as a strong foundation, we can look at the Agile Axioms:

---

We are Creators
Reality is Perceived
Change is Natural

---

All of the other principles and practices associated with Agile Work flow from these basic assumptions about the world. We can't prove that the above three axioms are "true". But they either resonate with us or they don't. If they do, then it will be easy to use these axioms as a checkpoint for all the activities we engage in using Agile Work, wherever we apply it.

We are creators... therefore we derive our sense of value from our ability to create. If our creations are accepted by others, our team, our stakeholders or our community, all the better. But fundamentally, this is inherent to us as human beings. However, sometimes this natural drive is suppressed or repressed. In order to activate it, we need to work in empowered teams.

Have you ever experienced inspiration or "flow" or joy when working with someone else? Perhaps you were solving a problem. Perhaps you were playing a musical instrument - jamming - and got into a fertile groove. Perhaps you were teaching your children and created the light of understanding in them. Perhaps you built a beautiful set of bookshelves for your home. Or maybe you told a joke that created a brief moment of genuine levity in a group of friends. We are all constantly creating!

This basic principle then means that Agile Work methods and practices should not be imposed. Taught to us, perhaps... given to us as a template, perhaps... but once we understand the practices and are familiar with them, we should immediately be given the freedom to use the learning cycle to be creative with the process and practices of Agile Work itself. If we do not participate in creation, we become dis-empowered and that eventually leads to resentment or apathy.

Reality is perceived... therefore we need to work hard to build a common perception of reality if we are to work together effectively. We need to amplify our learning. We can't assume that our own understanding of a situation is going to be shared by others. At the very least we need to check: "do you see this?"

Let's recognize that in some way or another we are all blind:

Again, the learning cycle comes into play. The guidance, detachment, love, courage and search we go through all help us to build a common understanding of reality. This allows us to see new ways to apply the Agile Work principles and practices that make sense not only to our context, but also to everyone else participating in the work.

Change is natural... therefore instead of fighting change, we need to anticipate it, adjust to it, embrace it, and be gracious or even enthusiastic. Not only does change happen to us, but we also instigate change. If things get to boring, whatever the circumstance, we find ways to change things. We rebel at stasis and ennui.

Each practice and procedure done in the context of Agile Work must be explicity and implicitly accomodating of change. If a procedure can't tolerate change it will either lead to a dissonance or conflict... or if we are embracing change, then we will modify or discard the procedure. Our creative nature loves to create, but if we become too attached, too "in love" with our creations, we will support them past their point of relevance.

Our latest greatest idea will be good for a while. But eventually change will make it irrelevent.

---

So we see that all three Agile Axioms are also interrelated.

Our creations will be washed away through change and if we are lucky or wise we will perceive the change in reality - be truthful to ourselves and others - and allow a new creation to take the place of the old one.

When we perceive a certain truth, and try to share that with others, we will be asking those others to change their own perceptions. This change can be difficult and may even require the destruction of a mental model created with love and care over a lifetime. Sensitivity to this loss and encouragement to build a new creation will help build a shared perception... as long as we too are open to new perceptions!

Adjust the Practices

And of course, all this foundation of creation, perception and change must be connected to the practical day-to-day reality of our lives. Our family lives, our work lives, our social lives, our volunteer lives, our intellectual lives, our emotional lives, our spiritual lives... our whole lives.

The Agile Work practices are simple to state:

---

Manage Ourselves
Deliver Frequently
Adapt our Plans
Communicate Powerfully
Test Everything
Measure Value
Remove Obstacles

---

These practices provide a starting point. A basic set of activities that will assist you, your team or your organization to advance quickly towards whatever goal you have set for yourselves. The way these practices succeed is by making sure that the Agile Axioms are always remembered and their implications accepted. These practices will set up a virtuous circle by building trust and allowing truthfulness. More trust and truthfulness will allow a fuller and more nuanced expression of the practices...

But if these practices become canonized, if they become a rote process imposed and followed blindly, then it means that we have lost sight of the Axioms. We have forgotten to check our practices against the context of creation, perception and change.

The reason we follow these practices is because we believe that we are all creators, that we can learn from our diverse perception of reality and that change is a force of growth. We don't believe these Axioms because we blindly perform these practices.

---

This is all available as a nicely formatted pdf: Agile Axioms - a Brief Exposition.

Posted by Mishkin Berteig at 01:45 AM | |

March 27, 2006

Dehumanizing Documents

This past weekend, I was honored to host a small gathering of Agile coaches at my home. Our conversation varied over many topics and I'll be covering some of them in the upcoming days. The first I would like to cover came from a comment that Christian Gruber made. In the Agile Software Manifesto there is the statement that we value "working software over comprehensive documentation" and in the Agile Axioms we say "we are creators". These two statements are closely related.

The comment Christian made was roughly as follows (and I've inserted a bunch of words to make the context clear):

When we communicate through documents in large organizations, there is often no specific person that is receiving the document. Rather, the document is being written by a role for a role both of which are part of some corporate process.

Since both the writing and receiving are being done in relation to abstract roles, the document itself becomes very abstract. The writer of the document must forget his or her humanity and write as a machine: precise, complete, making assumptions explicit, and carefully structured. In other words, write in a way which is very unnatural compared to normal human communication.

How do you feel when you read such a document? Bored? Insulted? Frustrated? Turned Off? Resentful?

No wonder! It wasn't written for you. It was written for the least common denominator of you, namely, the role you play in an organization. This is dehumanizing. It is an attempt to make the people in an organization predictable and robotic in their communication.

So, in order to change this, Agile methods encourage that we write the least possible amount of documentation (not none). I would add, that when we must write documentation, we write it to a specific person. We find out who will be reading our document, get to know them at least a little bit. Then, write it with their name in it. Write it as an extended conversation. Make assumptions about what that person knows. Put your own personality into it. And of course, put in the crucial information. After all, you are writing for a reason :-)

Posted by Mishkin Berteig at 07:28 AM | |

October 10, 2005

Agile, the Adult Educator and Ethical Considerations

A review of Tara J. Fenwick's “Limits of the Learning Organization: A Critical Look” (article found in Learning for life: Canadian readings in adult education).

This article is a critique of learning organization literature (as presented in the works of Peters, Senge, Watkins, Marsick, Argyris, Schon and others). I chose to do a review of it because learning organization literature can and does inform the work of Agile practitioners. The writer, Tara Fenwick, offers a critique of this literature as an academic and practitioner in the field of adult education. Even though the language and tone of the article is judgmental and at times affronting to the corporate trainer audience, it is never-the-less challenging and valuable because she raises interesting ethical questions that can serve as cautions against potential trends that can distort agile practice. I will summarize her argument in the some of the areas most relevant to Agile practice.

Fenwick's summary of the model of learning organization found in the literature, is an organization that: “creates continuous learning opportunities, promotes inquiry and dialog, encourages collaboration and team learning, establishes systems to capture and share learning, empowers people toward collective vision and connects the organization to its environment.”

The following is a summary list of some of Fenwick's critiques:

Who's Interests are Served
Although the learning organization literature holds great promise for a more humanitarian and egalitarian workplace, it has the potential to distort learning “into a tool for competitive advantage” and in turn, exploit people as resources in the pursuit of profit. To explore this idea she asks a valuable question: “Who's interests are being served by the concept of learning organization, and what relations of power does it help to secure?” She argues that learning organization literature tends to serve the interests of educators working as trainers in organizations and managers interested in their own self preservation.

How Learning is Defined
Learning, in learning organization literature seems to be defined as that which benefits the organization, all other learning falls into the dysfunctional category. This perspective negates other ways that people create meaning and learn and potentially causes a person to become “alienated from their own meaning and block flourishing of this learning into something to benefit the community.”

Assumptions about Learners
The learning organization literature subordinates employees by seeing them as “undifferentiated learners-in-deficit”. Educators and managers are the architects of the learning organization while employees are busy “learning more, learning better and faster” trying to correct their knowledge deficit. In the learning organization workers become responsible for the health of the organization without the authority to determine alternative ways to reach that health. The fear of being left behind in a quickly changing market environment is used to create anxiety and fear as motivations for learning. All of these factors serve to put serious limits on the potential of people to learn in the work environment.

Diversity and Privilege Overlooked
Perspectives of race, class and gender -which research has shown affects the way people learn and collaborate- are lacking in the literature. Fenwick challenges the notion of achieving a democratically ideal situation for open dialog -that the learning organization literature calls for- when all people in the work place do not “have equal opportunity to participate, reflect, and refute one another” (for example because of the status of ones job, character, gender, class, age etc.)

Fenwick sheds a clear light on where the good philosophies of the learning organization are found wanting. The Agile community can benefit from asking some of the same ethical questions she asks in relation to our work. Her critique is a good challenge for Agile practitioners. It challenges us to:

• Continue to strive for higher levels of ethical excellence in our work
• To consider issues of power in our work
• To become conscious of how we use our own power
• To give thought to what voices are included / excluded in the creation of the learning organization
• Pay attention to how we motivate learners
• How to foster collaborative environments that are conscious of the privileging of some over others
• Think about who decides what is valuable knowledge and learning and how that affects the knowledge creation process

Reflecting on these issues will go a long way to contributing to the development of agile practice.

The full text of an old version of Fenwick's article can be found here.

Posted by Shabnam Tashakour at 09:35 PM | |

September 22, 2005

A Good Quote

"It is a mistake to try to look too far ahead. The chain of destiny can only be grasped one link at a time." - Sir Winston Churchill

(Thanks to Chris Celsie for pointing this out!)

Posted by Mishkin Berteig at 01:46 AM | |

August 18, 2005

Harvard Business Review Article

I highly recommend this article on Collaboration Rules. Great stuff in there about developing teams, developing organizations and how important communication and trust are to doing so. The article draws examples from and compares the open-source development and maintenance of the Linux kernal and the operation of the Toyota Production System.

Posted by Mishkin Berteig at 10:48 PM | |

August 17, 2005

The Viable Systems Model

Agile Work is a system that can be created inside many types of organizations and work environments. I recently came across an interesting article about the viability of systems. The article describes an interesting recursive breakdown of systems into sub-systems of specific types. Over the course of the next few weeks, I will use this model to try to analyze Agile Work to see if it is viable.

Posted by Mishkin Berteig at 08:36 AM | |

August 09, 2005

The Transparent Society

The Transparent Society, an essay by David Brin is an excellent statement about the possibilities and challenges that technology presents to us as a society. What is interesting about this paper is that it presents a possible society that is very similar to some of the goals in establishing an agile environment: open communication, accountability, free access to information and status, and close collaboration.

Posted by Mishkin Berteig at 11:58 PM | |

August 06, 2005

Generalizing Specialists

The term "generalizing specialists" has come to mean an individual who has a particular area of deep expertise but also has experience in a large number of other areas that may not be directly related to their core area. This type of person typically has strong talent in their specialty but also has a generally strong talent for learning new skills and ideas quickly. The origin of the term seems to be in the software industry referring to programmers who can do other software-development related tasks.

In self-organizing teams, a generalizing specialist is a more valuable team member than a pure specialist. The pure specialist often has an attitude that they should not need to do work outside their specialty. This can be destructive to the team's morale. On the other hand, the generalizing specialist is willing and able to learn new skills - to stretch as the needs of the team change. And since change is natural, this is an essential attitude for team members.

However, we are usually trained, and strongly encouraged to have a deep specialty. This approach to education and training is a natural consequence to the typical organizational model for work and society. Therefore, if a team is converting to agile work methods, people need to be coached to stretch themselves and learn new things. For some people, particularly those who already have multiple hobbies outside work, this is an easy transition to make. For others, it is a very difficult transition. In some extreme cases, this may call for the removal of someone from the team. (Note: I have never seen this myself and I only mention it with great reservation. I strongly feel that only those who could be called "ill" will be so incapable of changing their way of working. For other recalcitrants, it is usually a matter of motivation.)

Other terms that are similar to "generalizing specialist" include "craftsperson", "renaissance man", and "polymath".

Posted by Mishkin Berteig at 08:05 PM | |

August 04, 2005

Just In Case You Haven't Seen It Yet

There is a fantastic article about software productivity: http://www.joelonsoftware.com/articles/HighNotes.html. I love Joel's writing style, and this article in particular has important lessons for us all, regardless of our profession: find what you can be the best at, and do that. Interestingly enough this is part of the message of the book Good to Great but applied to a whole corporation. It also applies in the context of self-organizing teams: each individual should be able to find/learn in what way they can best contribute and do that more than they do other stuff.

Posted by Mishkin Berteig at 11:41 AM | |

August 02, 2005

Memory and Mystery

My father, Garry Berteig, recently took a trip to China to visit my brother in Beijing. Garry is an artist and an educator of great skill and insight. While there, he had the following insight:

Memory (traditional forms) is undone by Mystery (abstract forms). The next step is to combine the two into new forms in a postmodern sense... unity through diversity.

I believe this can be related to the idea of levels of mastery which I first encountered in Alistair Cockburns excellent book "Agile Software Development". Since I don't have the book in front of me, I have to go from memory. First there is rote learning, memorization of predefined forms. Then comes understanding of why the forms are the way they are. Finally comes the wisdom and experience to innovate on the forms.

If anyone else has any ideas about this, I would love to discuss them!

Posted by Mishkin Berteig at 12:00 PM | |

August 01, 2005

Broadcast Mode Communication

The book "The Mythical Man-Month"* discusses some of the reasons that larger teams are inefficient. The main concern is with the number of possible connections between team members. If you have two team members, there's only one channel of communication. However, if you have n team members, then you have n(n-1)/2 channels... which grows quickly (order n^2) as n becomes larger. If one is required to work with a large team, say more than 10 to 12 people, it becomes imperative to find ways to improve communication efficiency.

One of the best ways to do this is to use broadcast mode communications. Information radiators are a simple broadcast mode tool. In a subtler way, having the team co-located** also takes advantage of broadcast mode communication: if everyone can overhear all the conversations that are going on in a room, then people can tune in when they hear something of relevance.

It is important to note that there are several other forms of broadcast communication that are useful in certain circumstances: e-mail, blogs with RSS or Atom feeds, analog radio, television (if you can think of others, please let me know in the comments). These tend to be more useful for very large communities. Radio and television have severe limits: they are not easily used in a communal fashion.

Some forms of communication may seem to be broadcast, but in fact are not. A simple web site is not because it requires that people poll it to see if it has been updated. Conference calls are marginally broadcast in that while they are occuring, everyone participating hears everyone else. However, a conference call requires active synchronized attention on the part of all the participants.

The subject of media and communication is a vast one. Some of the best writers include Marshall McLuhan and Gregory Bateson. However, there are many many more.

*Highly recommended!

**A search on dictionary.com for collocation indicates that three spellings are all correct: collocate, colocate, and co-locate, this latter spelling being the most common on the web.

Posted by Mishkin Berteig at 11:18 AM | |

July 31, 2005

Another Excellent Blog: Reforming Project Management

Good stuff, in particular about lean, at Reforming Project Management. Applicable to agile work in many circumstances.

Posted by Mishkin Berteig at 12:45 PM | |

July 25, 2005

Applicability Matrix Tool for Iterative Delivery

Notes:

1. Iterative Delivery is a specific way of managing queues of work. As such, rote work is generally better served by other applications of queuing theory.

2. There is one universal condition under which iterative delivery is awkward, if not inadvisable. If one's horizon of predictability is longer than the size of a work package by some substantial amount (e.g. 2:1 ratio), it can be more natural to use queuing theory and a pull system to flow work through the team. The actual ratio between the horizon of predictability and work package size that is used to switch over to a queue system must be determined empirically in your own circumstances. This empirical analysis can be done using a regular process reflection meeting.

Posted by Mishkin Berteig at 03:14 PM | |

July 23, 2005

The True Cost of Software

From the Link: Calculating the True Price of Software by Robert Lefkowitz -- Businesses have long viewed support and maintenance as essential components of software. Open source business models often focus on charging for support and customization. Is there an economic model that can demonstrate the true worth of a piece of software and the option for support, maintenance, and upgrades? Robert Lefkowitz argues that open source exposes the true value of software itself as, essentially, worth less in comparison to support and maintenance.

Posted by Mishkin Berteig at 04:37 PM | |

Book Review - "The Tipping Point"

Overview

The Tipping Point: How Little Things Can Make a Big Difference is a book that is about the way ideas, things and behaviors go from obscurity to ubiquity in a very short period. The basic model is that of an epidemic in which three types of factors contribute to quick dissemination: 1) the network of people involved including "connectors", "mavens" or respected experts, and "salesmen", 2) the ability of that which is spreading to stick around, the "stickiness factor", and 3) the importance of small physical, mental and social factors, in creating a conducive environment. The Author, Malcolm Gladwell, includes some excerpts on his web site.

• Introduction
• One: The Three Rules of Epidemics
• Two: The Law of the Few: Connectors, Mavens, and Salesmen
• Three: The Stickiness Factor: Sesame Street, Blue's Clues, and the Educational Virus
• Four: The Power of Context (Part One): Bernie Goetz and the Rise and Fall of New York City Crime
• Five: The Power of Context (Part Two): The Magic Number One Hundred and Fifty
• Six: Case Study: Rumors, Sneakers, and the Power of Translation
• Seven: Case Study: Suicide, Smoking, and the Search for the Unsticky Cigarette
• Eight: Conclusion: Focus, Test, and Believe
• Afterword: Tipping Point Lessons from the Real World
• Endnotes
• Acknowledgements
• Index

Assessment

This is a fascinating book, well written. Some of the anecdotes and "case studies" are mind-blowing. However, there is a bit of weakness in parts. In particular, the Afterword and the sections on The Power of Context are weakly put together - ideas do not flow well, or are too stream-of-consciousness. As well, the weight of evidence, while strong, is not totally convincing. That said, there are a couple of really fabulous stories.

One story that stands out is the study related to the "Good Samaritan". In brief, researchers set up an experiment to test what factors influenced a person's behavior when presented with someone obviously in need of help. At a seminary, the researchers had students prepare and deliver a brief talk on some topic. One of the topics given randomly to some of the students was the story of the Good Samaritan. The students were to take a short amount of time to prepare their talk and then immediately go to another building to deliver it. Planted by the researchers along the path to the second building was an actor made up to appear in a great deal of physical distress. As each student was sent out the door, the researchers would breifly comment either that the student was running a little early, or that they were late and needed to hurry to deliver their talk. The results were astounding: of those students who were told that they were late 90% ignored the person in distress regardless of the topic of their presentation, while 63% those with a few minutes to spare stopped to help (pages 163-165).

Relevance

There are several ways in which this book is relevent to those of us practicing Agile Work and related methods. Most obviously, the ideas in The Tipping Point suggest some lines of action we can take to promote Agile: finding the connectors, mavens and salespeople, working to make Agile sticky, and making the environment hospitible to the spread of Agile. This applies both inside organizations and in the world at large.

In my own opinion, the drafters of the Agile Software Manifesto, either by design or otherwise, came up with an incredibly sticky term: Agile.

Finally, when coaching a team to adopt agile practices, it may be most important to focus on the Power of Context. Small suggestions, small physical changes, body language, all can have a large influence on the success or failure of an agile adoption. If a coach (Scrummaster/Team Lead/etc.) can find the connectors, mavens and salespeople in the sphere of influence of the team, and convince those people of the efficacy of Agile, then convincing the team will become that much easier.

Posted by Mishkin Berteig at 09:59 AM | |

July 10, 2005

Amplifying Your Effectiveness

At the Scrum Gathering in May, Esther Derby advised me that the AYE Conference is a great place to learn and meet other like-minded people. From the web site:

AYE is a conference that's designed to increase your effectiveness -- in leadership, coaching, managing, influencing, and working in teams.

The AYE Conference is for people who work in arenas where problem solving is a key skill -- environments such as systems development, product development, quality assurance, information technology infrastructure, customer service and consulting.

Posted by Mishkin Berteig at 10:25 PM | |

July 03, 2005

Quotation from the ScrumDevelopment Group

On scrumdevelopment, Mike Dwyer wrote:

Agile is NOT about a logic tree, or a series of causal situations that can be expressed in a state table. Agile is about the management of the anomalous and the leveraging of failure into mind bending, industry shifting, success.

Posted by Mishkin Berteig at 05:31 PM | |

July 02, 2005

Agile Stickiness

In the book, The Tipping Point: How Little Things Can Make a Big Difference by Malcolm Gladwell, the author describes the idea of stickiness this way:

...the content of the message matters too. And the specific quality that a message needs to be successful is the quality of "stickiness." Is the message - or the food, or the movie, or the product - memorable? Is it so memorable, in fact, that it can create change, that it can spur someone to action?

What is it about agile that is its essential stickiness? What aspect or aspects of agile are both memorable and easy to act upon?

In the agile software domain, two examples of stickiness stand out. The first is the Extreme Programming (XP) methodology. The name, as well as some of the more controversial practices of XP such as pair programming and evolving design combine to be memorable and relatively easy to try out. The second example of stickiness is the Agile Software Manifesto. In this manifesto, the four values seem to resonate strongly with IT professionals and software developers... so strongly that many encounter them and then become hooked on trying to implement agile software development in their own sphere of influence.

For agile work in general, the term "agile" itself has some stickiness. The implications of speed, flexibility, responding to change, lack of bureaucracy, and skill rather than chaos are all very integral parts of the word when it is applied to a method of working.

Posted by Mishkin Berteig at 12:15 PM | |

July 01, 2005

Agile Project Management

Sanjiv Augustine, with whom I have had the pleasure of working, has created a neat little web site about Agile Project Management, a very close relation to Agile Work. From the site:

Agile principles are also being applied very successfully to non-software development projects. In particular, the underlying values of Agile Project Management (APM) as laid out in the Declaration of Interdependence are being applied in many organizations large and small to deliver value - reductions in time to market, reduced waste; and increased efficiency, collaboration and customer satisfaction.

The main difference is the explicit role of a manager. Agile Work fits with Agile Project Management, but is more generic: any person or team can adopt and adapt Agile Work practices and principles regardless of the existence of management.

Posted by Mishkin Berteig at 11:55 AM | |

June 28, 2005

The Agile Workplace

From the article:

The study found that agility -- the ability of the workplace to adapt to change -- has emerged as the single highest priority in the workplace industry. The agile workplace needs to be flexible enough to support many ways of working -- no one size fits all -- and its boundaries need to expand to support work at any time, in any place, with anyone.

The study also examined the effects of the agile workplace. It discovered, for example, that organizational structures tend to be more team-oriented and less hierarchical when it's easier for workers to collaborate across the boundaries of time, space and geography.

Cause or effect? I suspect that there is a positive feedback cycle at work here. As teams and organizations adopt agile practices, they adapt their workspaces to be more suitable. As the workspaces change, the organization is able to more effectively adopt agile practices.

At a team level this is certainly true in my experience. At first, many organizations adopt agile practices without, for example, having the team sit all in the same room. As the team becomes more proficient at the agile practices, it becomes more and more of a burden that the team is not co-located. At some point, it becomes critical for the team to be co-located if they are to become any more efficient. The organization/team then bends itself to enabling co-location. Once the team has found itself a space and moved in, it reaches a new level of effectiveness... until the next environmental constraint is encountered.

Posted by Mishkin Berteig at 07:29 PM | |

June 22, 2005

Good Agile Enterprise Resource Site

I have not yet read many of the papers on the site, but Paradigm Shift International hosts a substantial collection of essays and links to other work on the topic of Enterprise Agility. The author of the essays, Rick Dove, has been writing on the topic since November 1994. As I read these essays, I will write up very brief reviews with comments about how his thinking relates to Agile Work.

Posted by Mishkin Berteig at 10:18 AM | |

June 04, 2005

Lean Construction is Agile

I love Hal Macomber's blog "Reforming Project Management". And while he writes from a background of Lean Construction, his posts apply across other domains as well - I find they often resonate with the work I do in Agile software development. His site also includes articles and web conferences, and has an RSS feed so you don't miss his short, salient posts. Have a look!

Reforming Project Management
Hal Macomber, Project Reformer, explores the evolving theory and practices of lean project delivery

Posted by Deborah Hartmann at 08:04 AM | | | TrackBack

June 03, 2005

Agile Manufacturing References

Agile manufacturing: is the ability to accomplish rapid changeover between the manufacture of different assemblies. Rapid changeover is further defined as the ability to move from the assembly of one product to the assembly of a similar product with a minimum of change in tooling and software. Rapid changeover enables the production of small lot sizes, allowing for `just-in-time' production.

The link is to a page with a list of links to other pages about agile manufacturing. Lots of good stuff to be found there.

Posted by Mishkin Berteig at 11:46 PM | |

May 28, 2005

Interesting Article by Scott Berkun

Why smart people defend bad ideas by Scott Berkun looks at a fascinating, and fairly common, problem. Interestingly, this problem of smart people doing dumb things / definding bad ideas, is often related to perception. Agile principles and practices are about aligning perception among all the stakeholders, and in particular, between an execution team and the rest of the stakeholders. By aligning perception, the best environment is created for doing the right thing. In the case of a business, your project team are the experts in "how" to do stuff, and your business team are the experts in "why" to do stuff. This combination of "how" and "why" is done as efficiently as possible using agile work methods.

Posted by Mishkin Berteig at 10:49 PM | |

May 15, 2005

Truck Factor

Truck Factor (definition): "The number of people on your team who have to be hit with a truck before the project is in serious trouble"

Clearly "hit by a truck" is an extreme thought however you could easily substitute "take vacation at the same time" to get the same idea. If any part of your project has a truck factor of one then you are in a particularly fragile situation. If that one person leaves or is unable to work on the project, you will suffer the consequences.

Over time, anyone can be replaced. Truck factor is an indication of how expensive it will be to replace specific people.

In an ideal situation, everyone on the team will know all parts of the system so that the loss of any one person would have minimal impact. In reality, many projects rely on one or more "heros" who are the only one who understand certain critical parts of the system. When these heros leave (and you should assume they will), you must be prepared to recover.

If you have a hero on your team, the best thing you can do is reassign that person to a different part of the system. This will allow the replacement to ramp up while the hero is still available for support. If you wait until the hero has left then the ramp-up will be significantly more expensive.

An added benefit to reassigning the hero is that this person will now have the opportunity to work on something different. Since the hero's tend to be the most technically competent members of the team, this will usually mean that the new area will improve once the hero has worked on it for a while.

Truck factor is a quick metric that will highlight potential problems in your project. Having hero's on your team can be very beneficial but only if you don't become dependant on them. Truck factor is one metric that will highlight your dependencies.

Cross posted from Mike Bowler's Weblog

Posted by Michael Bowler at 06:42 PM | |

May 13, 2005

Self Organizing Systems FAQ

Just a link to the Self Organizing System FAQ - glanced through it, it looks amazing.

Posted by Mishkin Berteig at 10:29 PM | |

May 12, 2005

Scrum Gathering May 2005 in Boston - Rough Notes

Here are my rough notes from the May 2005 Scrum Gathering in Boston. Regrettably I was not in the room for most of Mike Cohn's presentation on User Stories... but his book (User Stories Applied : For Agile Software Development) is excellent :-)

The notes in this entry include predictions from Ken Schwaber, a presentation from Bob Schatz formerly of Primavera on their enterprise-wide implementation of Scrum, a panel discussion with Tim Bacon, Jeff McKenna, and Diana Larsen, moderated by Esther Derby. In the afternoon we heard from Pete Deemer about Yahoo!'s enterprise adoption of Scrum, Mike Cohn about User Stories, and to close the day we had an energetic presentation from Tim Dorsey of WildCard Systems about their enterprise implementation of Scrum.

Scrum Gathering 20050511

Companies using scrum: Microsoft, Sun, Siemens, State Farm, IBM, Federal Reserve Bank, Yahoo

Purpose: implement scrum

http://www.controlchaos.com/playbook.pdf

Predictions by Ken Schwaber:

33% of orgs implementing Scrum get most of the benefits – triple the initial productivity
66% will largely fail – software not that important for these orgs
Current software workload will be done by 25% of the staff
Developer will become a umbrella title for software developers – no longer specialized titles
Scrum and XP will be seen as two complimentary approaches that will start merging – may drop these names over five years

At Wildcard Systems, transition from fixed price to time and materials for clients

Bob Schatz – implemented Scrum at Primavera

Recently left Primavera now at Solstice Software

Enterprise Agile – what does it really mean?
“Enterprise”
multiple teams, same projects
multiple teams, multiple projects
implementing across an enterprise
building enterprise applications
building systems to support an enterprise
implementing across geography and cultures
Enterprise Agile is all of these and more

Implementing agile is a culture changed
culture changes are extremely difficult
transitions are different for everyone
Everyone likes change... as long as it doesn't affect them
Two factors that facilitate faster changes
pain of doing it the old way is greater than pain of chang
new opportunity where the old way simply won't work
Other than that
it takes strong leadership, determination, and TRUST
Learn to crawl before you think about walking

(Primavera did it all in a big chunk – WHAT SITUATIONS MADE THIS WORK?)
- amount of pain – about to start a new project – very challenging, big technical hurdles – asked about doing it with just one team – what's the point? - whole org new the pain – let's just get this done – didn't want to compare apples to oranges (agile to waterfall) – decided to switch pains – bob had a management team that he spent a lot of time talking with – management team was absolutely on board – failures have come in places where management is working at cross purposes

Communication
open communications are critical in agile projects
larger, more complex projects require more communication
across organizational lines
frequent customer communications
Coordination
project managers coordinate the efforts of multiple teams
focus on team building and self-managing teams
progress and obstacles must be visible to everyone
learning and knowledge must be shared across teams
Co-location
individual teams ideally should be co-located in team rooms
the reality is that they can't always be
get creative!
Do the best you can and compensate with technology

No silver bullet
enterprise implies complexity
implementing requires leaders, knowledge, skill, and adaptive techniques
one person will not single handedly change a company
a consultant will not change your culture for you
buying a tool will not make you instantly agile
not everyone will read the stack of books you buy them
executive sponsorship and support is needed (DISAGREE? ANYONE HAVE EXPERIENCE WITH THIS NOT BEING REQUIRED?)

Keys to Success at Primavera (100 people in dev org)
sufficient motivation to change (pain)
good coaching from outside
team rooms
town hall project meetings – like daily scrum but from reps for each team
project manager role transition
information radiators
no OT/weekend working – change perspective of managers that OT is good
test driven development
“science fair” sprint reviews
build process
rotating “Scrum Master” responsibilities (after doing scrum for 1.5 years started seeing little hierarchies in teams) – certified ScrumMasters became cross-team coaches
best team performance rewards @ end of each sprint related to performance, scrum compliance, etc.
team-based bonus component (two components focused on scrum plus teamwork)
feature budgeting – work on feature only budgeted time, if over, negotiate with PO (ESTIMATES DON'T WORK regardless of tools)
sprint defect limits (tradeoff in favor of quality)
customer Webex sprint reviews
commitment to learning!
Combination of these things reduced defects by 75% (year 1 1200 to 600 with scrum, year 2 600 to 300 with XP)

What to Expect
resistance – always resistance to change
setbacks
problems
obstacles
damaged egos
unrealistic expectations (kept implementation of Scrum quiet)
difficult personalities
lack of trust

“The Hurricane's” System!!
Ken -> Hurricane -> disaster/destruction -> rioting -> calm -> Ken
Ken tells it like it is
people get freaked out

What you will get
well-respected motivated focused workforce
creative energetic learning environment
everyone focused on achieving goals
ability to meet commitments and be flexible
high value products
a disciplined repeatable approach to building software
cross functional teams that understand technology and business value
involved satisfied “customers”
Academia does not model cross-functional collaborative team work (e.g. No collaboration with business school)

What can you do?
have a vision and sell it
identify pain points and don't be afraid to try something different
openly discuss behaviors and challenges
look for the “real” issues, not just what people talk about
identify champions and leverage their power (people who influence others – make sure they're on board)
educate people outside of development and involve them in the process
brush up on your influence and negotiation skills
use the language and ceremony of agile
reward good behaviors, celebrate success
work the bad attitudes out of the system
don't sweep them under the carpet
be patient, persistent... don't give up!

What would you do differently
everyone makes mistakes
communication as a leader could have been better

How did you set expectations?
upper management already had low expectations
middle management was told that there were no expectations for the first few sprints

Add process/environment/team improvements to the backlog – someone has to pay the price for it. Everything goes on the backlog! Nothing is ever perfected – always changes and improvement.

Made mistake – Scrum of Scrums was institutionalized with responsibilities – but this caused power and conflict issues – eliminated this and move to town hall meetings (Scrum of Scrums as a meeting rather than an organizational structure)

Times for management feedback
sprint planning and review
special meetings (maybe triggered by observation in daily scrum)

Core of stubbornness, courage or stupidity.

Esther Derby – Panel Discussion of Agile Change: Building the Self-Organizing Enterprise

Tim Bacon – from UK – ScrumMaster and Coach
Jeff McKenna – Original Builder of Scrum
Diana Larson

Tim:
transition to XP since 2000
deal with personal and small group level
culture about how people interact – congruence between thoughts and action – values

Jeff:
1991 Scrum
Agile before that
primarily with small teams but up to 80 people
difficulty – getting people engaged – people don't have responsibility for the things they do – power to make changes in working lives – very difficult
Diana:
culture is the stories we tell ourselves about ourselves
changing language
systems level of change - “freedom's just another word for nothing left to lose” J. Joplin

Deb Hartmann
are there places where we shouldn't bother trying to change?

Yes, but depends on how you like to spend your energy.

Jeff:
if entire org is saying “no” then listen, but sometimes people say “no” without knowing what they are saying “no” to
as a consultant: there are times when you say “I don't want to do this anymore”
if motivation is there “I want to change” then it is easier

Diana:
if some say “yes”
“see where the buffalos of change have roamed before and see what kind of a trail they left” - indicators of where things might go in the future
ego involvement – significant influences who have lots of investment in the way things are can prevent change – or need someone who can move them out of the way
How do you make org change stick?
You don't
orgs keep changing – not really a new status quo, just a breather

Tim:
you can always change starting with yourself
personal integrity and desire to go to work
sometimes need to change other people to keep integrity

Jeff:
find out what people mean by “being agile”
explore what they mean

Going from waterfall to scrum – is there a smooth transition?

Diana:
define “smooth”?
People go through change in different ways – lots of models of change
resistance can be characterized as wanting to hold onto something of value
people need to see new/better value in the destination
may be emotional
the transition in people changing is chaotic and it is hard to do smoothly
some people are not set up psychologically to make a smooth transition
can't completely make transition roughness go away completely

Jeff:
some orgs are easier than others
some orgs have a culture of change
2nd order effect
need some success with change
gain some power to make lives better
rank and file are often pessimistic

Tim:
uncover the pain that is already there
uncover the good things

Ken Schwaber:
a few years ago Martin Fowler: not going to try help unless the org is a train wreck, without hope
now seeing large orgs investigating going agile because of agile's successes
sitting with CEO of corp that want's to go agile
how can I determine if this is even worth doing?
What are some yes/no questions?

Diana:
what types of change and how did they go?
What is it like when someone needs a change from facilities?
How work with HR when needs to be an adjustment?
How do the support systems support the org?
Is the org capable of making a container?

Jeff:
find out where the pain is? What is agile going to address? How is he/she thinking about it?
V.P. Of large company – 2 hours
6 what if's suggested
kept saying couldn't do it
left (maybe someone else could do it)

Tim:
litmus test
looking for intellectual curiosity
actively asking questions
seeing possibilities as you provide suggestions, description

Esther:
what are you willing to do to support this change?

Craig Larman:
ask CEO what do you know about agile? Pair programming
Customer in Scandinavia
successful scrum project compared to other projects
head of project leaving to go to another company
other PMs didn't know about this successes
How do you sell internal success?

Diana:
retrospectives at the end of all projects
what are the root causes of success, not just failure
how do we spread the word?
Risk associated with having only one person lead something like Scrum
need to make explicit the job of knowledge and skills transfer to as many people as possible
e.g. Language “pairing” vs. “shadowing”
use newsletters, brown bags, etc.

Tim:
a big part of all our jobs is to sell what we do
all heard of failures from the inside, but seen as successes from the outside
need to make sure successes are seen as success from the outside
use networks of people
if we don't have the networks, find the “connectors” (The Tipping Point)
secretaries
long-timers
bar, cafeteria

Jeff;
Guerrilla techniques
information radiators
celebrate when work gets done: use a bell
team loves the bell and gets done
other teams ask – what's going on?

Can this be done from a grassroots level? Overallocated people, management confused. Really struggling. Wholesale change is impossible. How?

Tim:
yes

Jeff:
Pete from Yahoo! Will talk about this
warning management
team may have self-starting ability
may bring someone in – should start working on management immediately
technical side can improve team very quickly
constraint moves to management and planning
management will stop work if not ready
management can no longer blame dev for failures
can go higher in management hierarchy

Diana:
start with one team and work from there
team has to manage their boundary between themselves and the rest of the organization

Tim:
we tend to lack courage when implementing from the bottom up
courage is the most important
“be the change you want to see” - Gandhi
there is a lot of fear about change upsetting the status quo

Mike (?):
works outside of development
what are the upside risks? Success can kill you – what happens when you are successful and the org starts to think about institutionalizing Scrum? How do you take this to senior management? Expectation management? Transition and scaling? Lots of cutting of admin work – don't need a lot of middle management to get stuff done.

Diana:
doing self-org teams for 20 years (*********************)
come up against: managers take two stances:
get worried and mess about
abdicate
BUT
role needs to change
what support do these teams need?
Put on workshops about how leadership shifts in this environment
planning going away
resource management, championing, boundary, facilitating all becomes even more important
requires professional development on part of managers

Jeff:
managers who pay attention know they have to learn and improve
always opportunities for improvement
what goes through the membrane between group and rest of org
sole job to manage membrane – 5 to 10 visitors a day
org context
boundaries change and move
new container forming outside of original group
Keep aware of org context and work with that

Tim:
Bob Schatz – managers have an identity problem
transition to leadership – have courage to have vision and lead
subtle
invite senior people to see the teams and join them
always work for these people to do in the team

Bottom up implementation – management happy, later ask about working more hours and weekends to get more work done? What about managers that want to squeeze their people?

Bob Schatz:
OT/weekends lowers quality – period.
Use that quality price to drive behavior
productivity drops because of quality problems

Tim:
find these managers and get them to propose this to the team
team that has successfully transitioned will make reasons for not doing this very very clear
team will supply questions to the manager

Jeff:
just ignore them – worked well
manager broke the team up into two pieces
long hours team velocity went down
normal hours team maintained velocity

Diana:
if question comes up because underlying belief not working enough hours
could be something else going on there – and underlying personal dynamic
could suggest other experiments

Not necessarily that somethings not working. Question about increase productivity based on hours.

Diana:
recruit someone to be team champion
that sort of question can be directed to champion

Jeff:
medical community research about long hours being bad for productivity

Tim:
analogy:
mechanistic thinking
people are machines?
Factories don't run machines at 100% utilization
Lean Software movement
Theory of Constraints
people aren't machines

put it on the backlog as a problem:
how to increase productivity by 25% without increasing manpower

Tim (?): manager may be asking for something realistic

..

Brian (?): what about external customer who says we're not doing agile. How do we help our customers to adopt this? E.g. A client that has contracted for work.

Jeff:
what do you mean by customer?
Is your business taking an external stance on agile?
Boundary is the organization
can have waterfall relationship to client and work agile inside
may have waterfall embedded in law

Diana:
are you asking about influencing the culture of an industry?
Invite them in to be involved with the process as much as they can stand
might not be very much at first
someone internal must become a domain expert and act as customer proxy

Jeff:
start by inviting to monthly demos (relatively easy)
invite them to come more frequently
like teaching children
go visit customer

Tim:
changing relationship to customer is sometimes about asking them to give something up
have to articulate what they have to gain

Ian: how to reward agile teams to get the best out of them? Reward according to influence not control.

Tim:
“Punished by Rewards” - carrots can be just as damaging as sticks
fun work can be its own reward
agile makes work fun again
extrinsic rewards may be an indicator of other problems

Diana:
frequent small rewards better than large infrequent rewards
large cumulative effect
Esther:
worked with team that received huge financial bonus
bonus was nice BUT
want recognition and notice from managers at a personal level

Jeff:
rewards for goals set by someone else is a problem
e.g. Sales quota had no connection to work in field

?: Starting from top down? What are the top three pushbacks from dev org? How do you overcome them?

Diana:
manage your own expectations
imposing change is very difficult task
frame it as an invitation

Jeff:
“yet another change”

Diana:
varies from org to org depending on culture
e.g. “flavor of month – wait it out” passive resistance

Jeff:
keep working the way I always have

?:
working cross functionally is resisted very strongly
want to protect specialization
iterative may seem less efficient locally
Solve: team building, coaching, build on initial successes
First line management team has to buy in
some people will have to move out of the organization

Jeff:
do lots of educational work
find pain points before imposing solution

Ken Schwaber:
very uncomfortable
teams for X-functional
lots of releases
management questions about jobs
power prestige
get people to talk about their feelings and facilitate solutions
notice the problem and facilitate talking about problems

Tim:
fear comes from responsibility for things that were formerly hidden
now get to own solutions

?:
org change
need to paint vision of new organization
resistance comes from what needs to be given up?
Self-image might need to be given up

Diana:
territorialism
prestige
relationships

Jeff:
paradigm shift – whoop de doo
10-20% of people will not change
some people will have to leave the team

?:
Executives have reposed the question:
how do I facilitate a bottom-up

Mishkin:
key driver metric – top down

Tim:
initial response will be emotional

Diana:
Fast Company article “change or die”

Jeff:
limbic system seat of emotion
decisions are made by this system not the rational side
allow people to use much more of themselves

Roger:
inhibitor to change: the old plaster syndrome
things go wrong, put in a solution, solution is institutionalized
have to deal with all the injuries of the past

What about Some Good References for Org Culture and Change? Self-promotion is okay!
-

Tim: Fearless Change: Patterns for Introducing New Ideas
Jeff: Leading Change , The Heart of Change: Real-Life Stories of How People Change Their Organizations
Bob Schatz: Managing Transitions: Making the Most of Change
Diana: Surviving Transition

?: more about cultural changes for creating team rules.

Jeff:
take over conference rooms
build a relationship with facilities
give team both common area and privacy – gradually spend more time in common

Tim:
might be about owning tools

Jeff:
keep separate tools for email etc.
dev machines don't even have personal logins

Brent:
Q&A session to HR people
dealing with emotional level
some who were most concerned went to HR directly

Esther: one sentence of advice:

Jeff:
Pay attention, watch observer, get awareness up

Tim:
be yourself and allow others to be self

Diana:
be patient, positive and don't give up

Pete Deemer From Yahoo!

History @ yahoo! - founded in 1995
Show up at work and just build stuff
No cubes
Until late 2000
Can't spend anymore
Impose control
Hired consulting firm to impose control
The waterfall for 4 years
Last September – Tobias Mayer – organized brown bag by Jeff Sutherland
Email went out
Pete attended along with 100 engineers
Two hours – blew off meetings
We all have “muscle memory” of small nimble projects that just worked
Pete invited Jeff S. to executive team meeting
The execs often do know what is going on
Potentially revolutionary
Exec team said “ya!” - method to madness that we used to have
December groundswell of engineers and executives – never happened before
Six project teams wanted to start
Esther Derby, Mike Cohn, Paul Hodgets brought in to inform
Four teams left
Deal: support in every way needed in exchange for completed training, coaching, one sprint followed religiously then choose
Scrum pilot program started in early Feb.
Tried bribing Ken, he recommended Paul Hodgets
Paul is light touch, close to teams
Mike Cohn – like a football coach
End of first sprint did survey (anonymous)
Team members and managers
90% response rate
Amazed
First sprint really tough...
but there's something here
How much done, cooperation, quality of work life all had substantial improvement
Didn't want to stop
Quote from manager who was sceptical “I don't know how they did it but what those guys accomplished was remarkable.”
Word spread
More teams wanting to do this
Brought in Gabby Benefield
Head of Scrum practices
Now we have 8 teams + more in the queue
From six months so far -> 15 observations for big companies
1.start with the teams that want to use Scrum – scattered seeds of knowledge widely and watched for the seedlings – everyone on the team must be at least open to it working – skepticism is healthy
2.call it a pilot program – we're not migrating to anything – creates air cover for the messiness – purpose is to learn the lessons – never stop being a pilot – stop when no more teams raising their hands – then examine why – teams that raise their hands have the most pain – Yahoo is classic matrix organization with functional silos – what about interaction between agile and non-agile: non-agile teams become enthusiastic about moving to agile
3.change is scary to many people, Scrum is really scary – resistance is “pre-conscious” - presented as common-sense practices that teams choose to take on – not management forcing it – all of this is about people – people change at different speeds – Scrum is like Indian food: some will love it right away, some will need to try it a few times – some of the biggest skeptics have evolved into biggest supporters – actively managed this – ground the exercise in honesty, openness and realism – gives people room to change their mind – don't create us vs. them
4.Patience is a Virtue – err on the side of rolling out fewer teams and spending time getting it right – every team has had issues – don't risk over-extending and having it collapse – at start many more evangelists for failure and news of failure spreads quickly – over budgeted for working through systemic issues that are made visible in teams – what is us, Us and Scrum
5.Find the middle path philosophically – scrum pragmatists – revolutionaries tend to be the purists – incredible passion – but also they can feel anxiety as transfer from guerrilla warfare against the system to being the system – how to keep the purists involved – revolutions eventually become mundane reality – people are messy, scrum is messy – no utopia where things work perfectly – pragmatists are very effective at carrying this out – but prone to compromise and corner-cutting – creative tension between purists and pragmatists
6.Set a high bar and set low expectations – force teams to take personal cost of training – very hard work, very expensive, may not work for you – people know when they are being sold – lots of pain and work moving a team to scrum
7.Scrum is hard – surfaces lots of nasty stuff – every pilot has had to deal with some big nasty issue – make sure people are prepared – emphasize this pain is scrum working not the opposite – was this problem there before, and will fixing it make things better – never had a team that said Scrum created a problem – be ready to go on a rescue mission – sometimes teams need help, can't always solve things on their own – what kind of help? - more facilitative help but can include direct suggestions – teams need to build their muscles
8.get experienced help – mechanics simple, but still help is useful – but outside perspective can be very positive calm reassurance – fear of looking like an “ass” and being the “Scrum guy” as a leader – spot the small stuff that can be very telling – comes with experience
9.your enemy is your friend – spend the most time with the people who like scrum the least – the detractors can have much more impact in early stages – make them informally part of the team – take their problems and ask them to help fix them – some of them might have some good points – figure it out early – don't let battle lines get drawn
10.be prepared to use guerrilla tactics to get things done – some policy/strategy stuff – but many are just little bumps in the road – e.g. Conference room assigned but had a big conference table so couldn't stand up – tried to get table moved by facilities – got email “thanks for getting table moved out” - table disappeared one weekend – someone came in and tipped over table and moved it out – don't know where it went
11.make good information more accessible than bad information – rumor mill will go into overdrive – email updates, brownbags, top 20 myths, FAQ – continuous flow of good info
12.find your evangelists – build a network of scrum proponents in every group and level of the organization – knowledge of reality both good and bad – able to speak with candor – including bad news – anchor since day one – if scrum is as good as it needs to be, it doesn't really need me to defend it – individuals using it should inform the organization about the reality
1.Senior executives – need to have an advocate but have to be careful with it – with a single statement that person can set the tone – danger in getting exec too excited – can lead to top down imposition
1.Story about “Let's Go” travel guides – every student reporter is fired every year – publisher has no power because temp work – used very scrum-like process
2.Something connected to a prior experience
13.Make the result visible – distributed results of survey to the rest of the team – this is the good, this is the bad – made people feel comfortable to enter the conversation – this is Scrum fixing itself
14.The urge to tinker is great – everyone has a way to improve scrum – some are necessary adaptations – a lot of them aren't – e.g. We're going to split out the eng, design and qa sprints (subtle reversion to waterfall), want SM and PO to be same person, want to use some practices – say “That's fine” but reflect and compare – make very clear what is and what is not Scrum – say “using agile practices” - don't let Scrum's name get sullied by experiments that aren't scrum – but experiments are still okay
15.Scrum will always be messy – Scrum is not about cleanliness, its about reality – people are insensitive and inconsistent – make mistakes and bad choices – Scrum makes the mess visible – if it feels too clean it may not be working – even the final product is messy – there is no utopia we will arrive at
Biggest problem:
first question: what does it stand for? What is the acronym
propose making it an acronym
Mad About You – Society for the Complete Ruination of Universal Mankind
Screwing Customers Royally with Methodology

How did Yahoo! get bamboozled by waterfall?
Accenture as experts in a time of trouble

Mike Cohn Filling your Backlog with User Stories

Tim Dorsey Wildcard Systems from Florida

SVP of performance improvement @ Wildcard
6 sigma and Lean
Brian Stallings from Citibank IT

change is often compared to a step into the dark
took four weeks to see results were much better – CEO took whole org to scrum immediately
What is the light at the end of the tunnel? Train? End of tunnel?
You need a leadership that will be the light
Vital stats
founded in 1997
move from cash to electronic payments – whitebox of gift cards
prepaid payment card services
2004 revenues 57mil 40-50% growth per yearsglobal

2000 – 700 million in transactions
2004 – 3.45 billion in transactions – 6 second response time

Now have 50 clients

12 million cards issued

Flexible Solutions – Managed for Client Success

Want to do good – but kept tripping over selves

System was a catastrophe waiting to happen – growth faster than expected

No fallback position because of growth

9 months scrumming last july 27 dev 6 qa 160 dev 60 qa now

Client feedback and employee morale – before scrum – not friendly to deal with, products always late, lots of bugs (but still best in business) – 82% of employees said they didn't like coming to work – tonnes of overtime, multiple projects

Speaking executive language is very important to going enterprise wide

Executive support – let go SVP of Sales cause he couldn't get with the program

Scrum:
1.process
2.technology
3.scrum teams (operational) everyone using it
4.people
5.org and infrastructure
6.client involvement
7.culture, behavior, morale
8.competitive advantage

Enterprise -wide implementation of Scrum:
1.Strategic Alignment
2.Organizational development – team building
3.Organizational analysis – metrics what is really going on?
4.Implement for Results
1.Symptom -> leap of faith -> solution

Took a baseline

Strategic Alignment (setting the course)
vision values and mission
process boundaries and accountability
goals indicators and targets
participation, buy-in and ownership
communications: structure and process
Lessos learned:
+strong executive support and review
+professional coaching and guidance
+consistent scrum practices
-WCS Culture: “get it done no matter what”
-recreate what we just threw out
-good is the enemy of great

Organizational Development (preparing the people)
team building and dynamics
roster roles and ground rules
expectations and concerns
interpersonal skills and meeting effectiveness
communications: metrics and alignment
Lessons Learned:
+strong review process
+learning organization (releases) – raising the bar means controlled release of the process improvements
+time boxed meetings
+team selection (teams initially had a team lead with 6months, a totally new scrummaster and 4 contractors)
-PO wanted to “own” the team
-lack of shared accountability (lack of collective knowledge of state of tasks)
-we're different, “our client expects...” - clients are exposed to “dirty laundry” through the daily scrum as chickens and they love it

Organizational Analysis (looking in the mirror)
selection criteria & ROI
process and tools
clients, suppliers, products and services
resources and portfolio management
communications: available and consistent – e.g. Mandate on use of Primavera for communication
Lessons Learned:
+Utilized Primavera for Scrum Template
+Staffing Models Reflect Backlogs
+financial benefits – able to move from $150/hr for dev to $60/hr only ask 2 weeks notice to shut team down
+client involvement
- ROI responsibility
-poor forecasting of Start and Due Dates
-valuable early weeks wasted waiting for client decisions

Implementing for Results (making it happen)
scrum planning and launch (2 weeks)
product backlog and estimates
sprint planning decomposition and review
agile programming tools
communications: daily scrum meetings and burndown charts
Lessons Learned
+introduced launch checklist
+consistent backlog and decomposition format
+application code collisions
+operational bottlenecks exposed
-overall sizing estimates were poor
-didn't require burndown charts immediately
-financial impact of a scrum team

Scrum Assessment: Radar Chart

Two week sprints all ending on the same day across the organization

What happens in two week ramp up after team formation develop backlog, interview clients, interview systems people

Stick to strictly normal working hours – teams are allowed to choose to work on the weekend but if it starts being a regular occurance then look at why

Metrics:
focus on process metrics

Posted by Mishkin Berteig at 10:35 AM | |

May 04, 2005