Tag Archives: Culture

Using Agile Work Practices to Develop a Seminar

Posted on by
Reply

I’ve been working on developing a Agile Work Seminar to introduce teams to agile work. I’m using some Agile Work practices to develop it.

Iterative Delivery and Adaptive Planning

The seminar is going through drafts. Each draft will actually be delivered to a team. The first time through all the material was done at a small software consulting company five days ago. As a result of feedback from the people who participated, a revision will be made to the seminar… and then it will be delivered again (probably the next time will be in early September). This process allows me to refine the contents and presentation of the material.

Over time, I will be able to use Adaptive Planning to modify the contents and qualities of the seminar as circumstances change.

Test-Driven Work

I have set up criteria for the presentation in the form of an outline and learning objectives. The outline describes the major topics that must be directly covered such as the Agile Axioms or Corporate Culture. I have also set up “soft goals” such as that the seminar must include theory, history, practice and criticism of Agile Work. My first iteration met the outline tests, but did not meet the soft tests explicitly. The next version will.

Appropriate Metrics

This is an easy one: the success of this project will be its acceptance in the marketplace by having teams willing to pay the price for this seminar and then recommending it to others.

The Other Practices

Because this is essentially a one-man job, the other practices such as Self-Organizing Team and Maximize Communication are not as applicable.

The Viable Systems Model

Posted on by
Reply

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.

Trust and Small Groups

Posted on by
Reply

A while ago I posted the story of a student film project using agile practices to create a documentary. One interesting observation made by the instructor is that trust among the group developed in an interesting fashion.

At first, the group self-organized by try to work in groups of three. However, when plans were made to get together (for example to film an interview), often, one of the three people would cancel. Probably, that person considered two people to be enough to do the work.

After noticing this pattern, the group decided to perform work in pairs. This made the commitment to working much stronger and eventually led to a more trusting work relationship.

I have also observed this pattern in other situations. Pair programming, pair writing, pair designing, pair problem-solving… all of these behaviors seem to arise naturally in a self-organizing team.

The Transparent Society

Posted on by
Reply

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.

Generalizing Specialists

Posted on by
Reply

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

Broadcast Mode Communication

Posted on by
Reply

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.

A Simple Rule of Thumb

Posted on by
Reply

Make your product/service development lifecycle shorter than your horizon of predictability. For example, if you can’t predict your competitive environment or your own capabilities outside of 4 months, then any new product/service should be initially launched at most 4 months from the time it is conceived. Once initial launch has occured, it is possible to examine the environment and make adjustments for an additional launch. One might call this experimental marketing. Ideas that just can’t be accomplished inside of one’s horizon of predictability should be considered very risky. In order to reduce this risk, these larger projects can either be broken up into smaller pieces, or efforts can be made to extend the horizon of predictability out further (this second task is extremely difficult).

Applicability Matrix Tool for Iterative Delivery

Posted on by
Reply

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.

Book Review – “The Tipping Point”

Posted on by
Reply

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:
  • 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.

Applicability Matrix Tool for Self-Steering Team

Posted on by
Reply

AMT-Self-SteeringTeam.png

Notes:

1. Self-Steering may be difficult to implement in some cultural circumstances. An organization that is very comfortable with a command-and-control system can benefit from self-steering teams, but the effort to shift the culture should be realistically assessed. An excellent reference for corporate culture change is “The Corporate Culture Survival Guide” by Edgar H. Schein.

2. Self-Steering in a rote work environment boils down to teams empowered to learn how to do the rote work as effectively as possible. This learning process must include the power to change the process with the goal of doing the work faster or with fewer defects. For example, in a manufacturing environment, this means people being able to identify problems and make improvements to the manufacturing process. In a rote work environment, not all changes the team makes will be improvements, but they must be accepted. A mechanism for measuring the result of changes must be in place so that the team can assess the effect of their changes, and make corrections as appropriate.

Applicability Matrix Tool for Adaptive Planning

Posted on by
Reply

AMT-AdaptivePlanning.png

Notes:

1. For rote work, it is rare to need an Adaptive Planning style prioritized backlog. Rather, simple queues tend to be sufficient. The adaptive backlog is designed to allow for reprioritization of work as more is learned about the work itself. With rote work most of the learning is involved with improving the process of creating the work and reducing defects rather than changing the work product itself.

2. Individuals can benefit from using a backlog to organize their work, keep a history, and track progress. However, it may be sufficient to keep a simpler to-do list. The adaptive planning practice allows an individual to gain the benefit of explicit collaboration points with stakeholders.

Applicability Matrix Tool for Information Radiators

Posted on by
Reply

AMT for Information Radiators

Notes:

For individuals, the use of Information Radiators is usually not applicable in rote work since the individual can keep track of status of such work easily. However, for adaptive and creative work, an information radiator can be quite useful as a constant reminder of what is happening or for organizing work to be done. A cork board for the status of tasks or for categorizing ideas can be a simple information radiator used by an individual. A whiteboard can be used for free-form notes.

For teams, information radiators are ideal for easily maintaining broadcast communication with team members. A team is usually small enough that an information radiator can be maintained by individuals making updates as appropriate. Project status of tasks, issues parking lots, and group calendars are examples of information radiators used by teams.

For a community, the difficulty of using an information radiator comes in the logistics. With a large number of people performing work, possibly never all coming together at the same time, the broadcast nature of information radiators can be severly curtailed. It is difficult to efficiently represent information that is relevent to the whole communit in a way that can be easily accessed and easily understood at a glance. As well, it is difficult to have community members directly and (relatively) equally participate. That said, there are some exceptions. The most obvious one is the various wikis that are maintained by communities… and the largest of these is Wikipedia.

Considering the Agile Manifesto and the Axioms of Agile Work

Posted on by
2

The Agile Manifesto, aimed squarely at software development, is inaccurate when considered against the more general target of Agile Work. The Agile Software Manifesto reads in part:

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.

Continue reading →