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:

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

AMT-IterativeDelivery.png

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.

Contents:

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

Agile Practices Applied to Architecture

I have just run across a web site about applying agile practices, specifically from Extreme Programming (XP) to architecture. This site, called "Architectural Practices - Extreme Project Management for Architects" has a great deal of information.

This site represents a set of ideas that have come full-circle. Christopher Alexander wrote a book called "A Pattern Language: Towns, Buildings, Construction (Center for Environmental Structure Series)" about a different way of looking at architecture, interior design, landscape design and city planning. This book made a big impression on some people in the software industry. In particular, it inspired the book "Design Patterns" by Erich Gamma et. al. This book became required reading in the software industry. Many participants in the Agile Software Development movement consider it foundational. And now we see agile practices being adapted back to architecture. Cool.

Posted by Mishkin Berteig at 04:15 PM | |

April 24, 2005

Agile HR - Sort Of

An article called Are You Ready for the Agile Future presents a brief discussion about the role of HR in an agile organization. There are several very good ideas. The basic idea is that the HR function must adapt to the nature of agility. This in turn means, for example, hiring people that are agile, nimble, adaptable etc.

There are however some mis-steps in the article.

One is an ommission: the HR organization must itself become agile. In one organization that I worked, it took at a minimum 4 weeks and typically 12 weeks to get a contractor onto a project. Three months lead time!!! Now admittedly, it is not easy to bring an individual on-board quickly. However, it is possible. Some organizations I have worked at have lead times for getting new people into the organization that are on the order of 2 weeks including search, selection, administration and orientation. In these organizations, the HR organization maintains an attitude to their own work as service to the larger organzation... and the faster the service (without sacrificing quality), the better.

The article also misses the mark on employee performance. Employees should be measured on their sphere of influence, not their sphere of responsibility. In other words, if a person is a member of a team, their own performance should be judged by the performance of the team as a whole. This mitigates people's competitive habits and positively reinforces collaboration. People should not be measured against their role discription.

One of the recommendations in the article is to "Create selection, testing and hiring criteria that identify diverse, resilient, nimble people." Unfortunately, there is no guidance on how to do this. Here are some ideas: look for people who have moved between projects, roles, employers and even locations frequently, look for people whose resumes contain lots of work that doesn't fit their job titles, look for people who have hobbies and interests that are outside their field of specialization, look for people who have diverse volunteer experience, look for people who ask lots of questions.

(Thanks to Deb Hartmann for the link.)

Posted by Mishkin Berteig at 09:48 PM | |

April 18, 2005

Book Review: "Good to Great" by Jim Collins

Good to Great book cover

Summary: In this well-written, engaging book, author Jim Collins describes six critical factors that he and his research team found common in companies that transformed themselves from a long period of mediocre or bad results to a long period of great financial results. Although focused on publicly-traded companies in the United States, the results of this research can easily be extended to apply to other types of organizations.

Good to Great describes the following six concepts:

  1. Level 5 Leadership: personal humilty and professional discipline in an organization's leader are the starting point for the transformation.
  2. First Who... Then What: don't worry about what to do until the right people are in the right positions in an organization.
  3. Confront the Brutal Facts (Yet Never Lose Faith): careful and honest examination of an organization's current situation is the foundation for finding a path forward.
  4. The Hedgehog Concept (Simplicity within the Three Circles): discover a simple business concept that people can be passionate about, that works with a single key economic driver and that the organization can be the best in the world.
  5. A Culture of Discipline: disciplined people removes the need for heirarchy, disciplined thought removes the need for bureaucracy and disciplined action removes the need for excessive controls.
  6. Technology Accelerators: pioneer the application of carefully selected technologies without relying on technology for transformation.

Some of these concepts are very close to the underlying prinicples of agile work. For example, in the Scrum methodology, the first five principles are all represented. The Scrum Master embodies some of the attributes of level 5 leadership. A self-organizing team gets the right people in the right position. The daily scrum and the sprint planning meetings are designed to help the team confront the brutal facts. The sprint goal embodies at a local level the simplicity of the hedgehog concept. And the practices in general are a manifestation of a culture of discipline.

Who Should Read this Book? Anyone interested in creating a lasting positive transformation in an organization should read this book. In particular, individuals who are coaching teams or organizations should read this book since the concepts also appear to apply at a sub-organizational level.

Posted by Mishkin Berteig at 07:29 PM | |

April 09, 2005

Article on CIO Insight

The online CIO Insight has a great article/interview about a forthcoming book: "The World Is Flat: A Brief History of the Twenty-First Century". Choice quote:

What I am trying to do is say that something important really is happening. The value-creation model is moving away from a vertical silo model to an increasingly collaborative horizontal model, from command and control to collaborate and connect, and that's going to change everything.

This comment alone is a fairly close hit at the essense of Agile Work. The rest of the article is very interesting and touches on many topics of interest relating to globalization, business, information technology, outsourcing and politics.

There is an interesting article at The Economist also about this book. It is very critical.

Posted by Mishkin Berteig at 11:49 PM | |