Winter has definitely arrived -- for the moment -- along the northern Front Range. Before the wind came up, there was a solid 16 inches of snow on the ground here. Now there are bare patches interspersed with deep drifts. Unlike a true winter storm, however, the follow-on was not a deep, bone-chilling cold. It's already just above freezing and the forecast calls for rapidly increasing temperatures beginning tomorrow. By next week it should be downright fall-like again. Wintry weather is so much easier to take when it is doled out in discrete parcels.
But now back to Scrum teams....
Last time I wrote about Scrum teams operating as organisms within an ecosystem. Some teams find their environmental niche very cozy, so much so that they specialize to a degree that makes them vulnerable to changes in the broader ecosystem. Software companies and software operations within other types of companies both operate in notoriously changeable business and technological environments. If a Scrum team becomes comfortable, complacent even, with its current skill levels and dispersion of knowledge, disaster can be lurking just around the corner.
In my experience, there are two problem areas that revolve around specialization. The first involves teams that know their domain and technology inside and out, but have stopped learning. Some teams have even stopped learning about how to improve their processes and interactions, making them stagnant and vulnerable to any changes, whether internal to the team or in the external ecosystem.
The other problem area is internal to the team: individuals have specialized skills, as we expect, but there is very little cross-functionality. The team does not practice pair programming, does not engage in code reviews, does not engage in collective design or shared refactoring -- in short, lacks the generalizing specialists that are key to keeping teams alive and growing. Teams in this state are also highly vulnerable to changes in their ecosystem, but they are even more exposed to changes in team composition. If any member of the team leaves the company or simply moves to a different team, the overly specialized team will suffer as a result. If they have been complacent for a long time, they may not remember how to adapt to changed internal or external circumstances.
So, what's a coach to do? For the first type of specialization, that of stagnant domain and technology knowledge, a good coaching technique is to plan a small amount of slack, say five to ten percent of the team's Velocity, into every Sprint which team members can use to broaden their knowledge. A good tactic is to use Spikes to keep research projects time-boxed and to encourage team members who take a Spike task to provide a report to the team that lays out their findings. As formal tasks, Spikes are also more likely to be taken on during a Sprint. Another way to help a team broaden its knowledge is to place stories or tasks on the team's improvement backlog, which the team plans out during Sprint planning and updates at every Sprint retrospective.
For the second type of specialization, use each Sprint retrospective to encourage team members to set pair-programming rules or goals, schedule shared code reviews, and perhaps also lunch-and-learn sessions taught by each team member on a rotating basis. These ideas for improvement should also be added to the team's improvement backlog, prioritized, and planned out during Sprint planning. Teams that lack adequate cross functionality generally have difficulty meeting their Sprint commitments, making these types of improvements even more vital.
What happens to teams that continue along their path of excessive specialization? As organisms occupying a specific environmental niche, they may suffer irreparable damage if anything about their ecosystem changes, including internal team modifications. In the natural world, organisms that are unable to adapt to a changing ecosystem become extinct. Teams can suffer a similar fate, metaphorically speaking, if they lack the versatility, skills, and tool sets needed to adapt to an ever-changing business, corporate, and technological environment.
All for now.
...-.-
Thursday, October 29, 2009
Monday, October 26, 2009
The Agile Team as Organism
In his brilliant book Agile Software Development (2002), Alistair Cockburn describes Agile teams as ecosystems (pp. 109-110). He talks about how teams create their own internal ecosystem, with certain team members frequently having a disproportionate influence on how the team develops and, more importantly, how the team learns to work in its broader environment.
While co-teaching a CSM course recently -- and in the middle of presenting a section about team development -- the thought struck me that Agile teams are actually much more like an organism living in a broader ecosystem, rather than the ecosystem itself. The ecosystem in which Agile teams live exists at several levels, the most immediate being the project on which the team is working, either alone or in parallel with one or more other teams. A team must adapt its behavior and possibly also its composition to the immediate environment if it is to survive, let alone prosper.
Beyond the project environment there are various levels of the corporation, more in larger companies, of course. Beyond the corporate environment, there is the larger system that encompasses the particular market in which a the corporation competes, the regional economy, and finally the global economy. Each of these levels within the broader "ecosystem" affect and influence Agile teams, forming the various threads of a complex web of interactions that play out on a daily basis. At the macro level, an Agile team is subject to the broader trends in the global, national, and regional economies in which that team lives. Any given team's ability to influence its ecosystem on this scale is extremely limited.
Closer to home, however, at the project and corporate (or more immediate corporate division) levels, Agile teams have a much greater influence both on what happens within those ecosystems and how the team adapts as a living, breathing 0rganism within its environmental niche. In the natural world, all organisms make behavioral changes at some level and undergo sometimes startling physical changes driven by natural selection to adapt to their environments. The motivating factor is survival, both of the individual and the species.
Agile teams operate in surprisingly similar ways. First, teams want to survive, or at least the individuals that comprise the collective organism we call an Agile team want to survive. Successful teams, those that survive, adapt to their environment in ways that allow them to occupy a niche in their ecosystem successfully. How do Agile teams adapt? First, they need to be properly constructed organisms, with the ability (and the authority) to change their composition as needed to be effective. Agile teams need to be able to invite new members to join -- and existing members to leave -- in order to adapt to the requirements of surviving and thriving in their ecosystem.
Secondly, Agile teams must use the feedback loops built into Scrum to understand both their environment and what is required to survive in it. The daily Scrum and the Sprint Retrospective are the two primary means teams have of gathering information and acting upon it. Successful Agile teams use these opportunities to adapt to their ecosystem by adjusting their behaviors and composition appropriately.
The definition of a successful Agile team-as-organism is a team that not only survives, but thrives in its ecosystem. As in the natural world, the relationship is symbiotic: when a team thrives, it affects its ecosystem positively as well, that is, the team produces top-quality software, on time and within budget, that satisfies the company's customers, leading to more sales and therefore a better, richer environment for the team. Another similarity with the natural world is that Agile teams are not engaged in a zero-sum game. By improving the environment for itself, an Agile team is enhancing the broader ecosystem as well, making it more likely that other organisms -- Agile teams -- will be able to survive and thrive.
Highly specialized organisms, however, often do less well when the ecosystem changes around them. More on that in a later post.
All for now.
...-.-
While co-teaching a CSM course recently -- and in the middle of presenting a section about team development -- the thought struck me that Agile teams are actually much more like an organism living in a broader ecosystem, rather than the ecosystem itself. The ecosystem in which Agile teams live exists at several levels, the most immediate being the project on which the team is working, either alone or in parallel with one or more other teams. A team must adapt its behavior and possibly also its composition to the immediate environment if it is to survive, let alone prosper.
Beyond the project environment there are various levels of the corporation, more in larger companies, of course. Beyond the corporate environment, there is the larger system that encompasses the particular market in which a the corporation competes, the regional economy, and finally the global economy. Each of these levels within the broader "ecosystem" affect and influence Agile teams, forming the various threads of a complex web of interactions that play out on a daily basis. At the macro level, an Agile team is subject to the broader trends in the global, national, and regional economies in which that team lives. Any given team's ability to influence its ecosystem on this scale is extremely limited.
Closer to home, however, at the project and corporate (or more immediate corporate division) levels, Agile teams have a much greater influence both on what happens within those ecosystems and how the team adapts as a living, breathing 0rganism within its environmental niche. In the natural world, all organisms make behavioral changes at some level and undergo sometimes startling physical changes driven by natural selection to adapt to their environments. The motivating factor is survival, both of the individual and the species.
Agile teams operate in surprisingly similar ways. First, teams want to survive, or at least the individuals that comprise the collective organism we call an Agile team want to survive. Successful teams, those that survive, adapt to their environment in ways that allow them to occupy a niche in their ecosystem successfully. How do Agile teams adapt? First, they need to be properly constructed organisms, with the ability (and the authority) to change their composition as needed to be effective. Agile teams need to be able to invite new members to join -- and existing members to leave -- in order to adapt to the requirements of surviving and thriving in their ecosystem.
Secondly, Agile teams must use the feedback loops built into Scrum to understand both their environment and what is required to survive in it. The daily Scrum and the Sprint Retrospective are the two primary means teams have of gathering information and acting upon it. Successful Agile teams use these opportunities to adapt to their ecosystem by adjusting their behaviors and composition appropriately.
The definition of a successful Agile team-as-organism is a team that not only survives, but thrives in its ecosystem. As in the natural world, the relationship is symbiotic: when a team thrives, it affects its ecosystem positively as well, that is, the team produces top-quality software, on time and within budget, that satisfies the company's customers, leading to more sales and therefore a better, richer environment for the team. Another similarity with the natural world is that Agile teams are not engaged in a zero-sum game. By improving the environment for itself, an Agile team is enhancing the broader ecosystem as well, making it more likely that other organisms -- Agile teams -- will be able to survive and thrive.
Highly specialized organisms, however, often do less well when the ecosystem changes around them. More on that in a later post.
All for now.
...-.-
Tuesday, October 13, 2009
Learning to coach while training
Winter has put in an early appearance on the Front Range of the Rocky Mountains this year. After almost two decades of very late arriving winters, this year is shaping up to be much more like those I remember growing up, with winter firmly ensconced by Halloween. The weather pattern could certainly change, but this has been a nice reminder that Colorado's weather is, if nothing else, highly variable.
The low overcast today seems to have put me in a contemplative mood. A thought that has been rolling around in my head for some time now concerns the nature of communication in the Agile training sessions I conduct. We tend to think of training as a one-way street, with the instructor delivering the curriculum and answering questions along the way and the participants in the class absorbing the information presented. I have noticed, however, that by the end of a two- or three-day training course, I know far more about the working lives of the people taking the course than I would ever have expected. For example, I know if they constitute a working team, regardless of whether they claim to be such. I also know a great deal about their frustrations, impediments, and constraints. I have a solid grasp of the role each participant plays on the team or pseudo-team* and even some sense of how they work together -- if indeed they do.
Given that in any training session, during the presentation portion (as opposed to labs and workshops), I am the one doing the talking at least 80% of the time, I am always surprised to realize just how much I have learned about the participants in the room. I try to answer all questions in-line and make full use of the Parking Lot to capture topics that are either tangential, more advanced than we can discuss as a class at a given moment, or simply beyond the scope of the current course. The Parking Lot then becomes the basis for a moderated discussion at the end of the formal presentation. But even before that point, I have learned much of what I need to know about a particular group of people to begin coaching them in their use of Agile or Scrum.
My employer typically uses various workshops or other discovery sessions to prepare for hands-on team coaching. While I find these types of activities useful for filling in the blanks, I also find, to my great surprise, that most of the information I gather using such tools simply reinforces the picture I was able to construct essentially unconsciously during the initial training. Given the often challenging and difficult nature of coaching agile teams, having learned so much during the initial training is a welcome head start.
All for now.
...-.-
* A pseudo-team is a group of individuals who just happen to be working on the same project at the same time, but without engaging in any actual teamwork.
The low overcast today seems to have put me in a contemplative mood. A thought that has been rolling around in my head for some time now concerns the nature of communication in the Agile training sessions I conduct. We tend to think of training as a one-way street, with the instructor delivering the curriculum and answering questions along the way and the participants in the class absorbing the information presented. I have noticed, however, that by the end of a two- or three-day training course, I know far more about the working lives of the people taking the course than I would ever have expected. For example, I know if they constitute a working team, regardless of whether they claim to be such. I also know a great deal about their frustrations, impediments, and constraints. I have a solid grasp of the role each participant plays on the team or pseudo-team* and even some sense of how they work together -- if indeed they do.
Given that in any training session, during the presentation portion (as opposed to labs and workshops), I am the one doing the talking at least 80% of the time, I am always surprised to realize just how much I have learned about the participants in the room. I try to answer all questions in-line and make full use of the Parking Lot to capture topics that are either tangential, more advanced than we can discuss as a class at a given moment, or simply beyond the scope of the current course. The Parking Lot then becomes the basis for a moderated discussion at the end of the formal presentation. But even before that point, I have learned much of what I need to know about a particular group of people to begin coaching them in their use of Agile or Scrum.
My employer typically uses various workshops or other discovery sessions to prepare for hands-on team coaching. While I find these types of activities useful for filling in the blanks, I also find, to my great surprise, that most of the information I gather using such tools simply reinforces the picture I was able to construct essentially unconsciously during the initial training. Given the often challenging and difficult nature of coaching agile teams, having learned so much during the initial training is a welcome head start.
All for now.
...-.-
* A pseudo-team is a group of individuals who just happen to be working on the same project at the same time, but without engaging in any actual teamwork.
Subscribe to:
Posts (Atom)
