In my last blog entry, I wrote about an agile review that I was preparing to conduct with one of my teams. This team began using the agile software development methodology in earnest in late July after receiving training. At that time, several experienced agile scrum masters and independent coaches were inserted to help guide the transition. I noted specifically that the team has some characteristics that make an agile implementation challenging and success uncertain: the team's overall size is greater than 80 individuals and growing; there are inter-organizational and leadership dynamics in play that could derail the implementation; and the technical environment (SAP), with its functional orientation, poses a unique technical challenge.
The data-gathering portion of the review ended on October 8. As hoped, the number and variety of input sources and forums for leaders, coaches, mentors, practitioners, and customers proved to be quite robust. Indeed, this review approach yielded more data than one could hope to analyze in a short period of time—particularly when other responsibilities begin to intrude. Despite my initial worries, gathering input is the easier part of the review. What remains is much more difficult: fully understanding the data that was gathered, deriving major themes, identifying recommendations, and implementing those recommendations, as appropriate.
Emerging Themes
While the review is still incomplete, some themes have begun to emerge that suggest the characteristics of this team's working and technical environment are not driving a significant number of unique challenges and problems. That is, many of the concerns raised by the team and their leadership are reminiscent of earlier agile implementation experiences: difficulty breaking down epic user stores, an initial inability to size in story points, general role confusion, problematic team communications, and getting good quality user stories and acceptance criteria. Nonetheless, there are some themes that do appear to be unique or, perhaps, this team has a different spin on an otherwise generic theme.
Iteration planning is of particular concern in part due to the functional orientation of the team and the underlying product. The functional orientation of the product makes planning an iteration challenging in that the stories selected need to match the team's composition or the work contour will be uneven. This implies that a potentially higher priority story might have to take a back seat to a slightly lower one because resources may not be available to complete it during the iteration. This is not wholly unique—other agile teams also run out of resources—but it is more acute because the functional breakdown of the team is so granular. To smooth out the work contour means you need to know more than just the team's velocity. As one colleague aptly put it: you need to identify and understand the micro-velocity by functional orientation to be successful. In addition, the team does not have a rigorous planning background to fall back on: they are learning it as they learn agile.
The technical infrastructure surrounding the application and the functional orientation of the product presents unique challenges. The inter-dependencies between modules (which also effect planning) are somewhat mind-boggling. Too, the ability to keep various environments synchronized has become an issue, though not one due to the implementation of agile. Regardless of the source, it is clear these items will need to be addressed as they are a systemic source for blockers during and after an iteration.
Meeting overload. One of the things that came through loud and clear was that practitioners and leaders felt that they were attending too many meetings. The team itself is distributed, so some "meeting creep" is expected, since in-person communications are not always possible. But, the prevalence of the sentiment shows that it is a larger issue than just adding a 15-minute scrum and another 15-minute scrum-of-scrums call during the day. While there are instances of people who do not need to attend certain meetings being expected to attend—much of which has already been rectified—we failed to consider the impact of these additional meetings on an apparently already busy meeting schedule. In fact, existing meetings have grown to encompass much of the same material covered in the scrum of scrums meaning we now have some redundancy.
More to Come
Preliminary insights are just that: preliminary. They only give a hint of the direction you may eventually need to follow. Assuming I can wade through all the data with my review team in a timely manner I am sure we can figure this out. I am also sure we will find a lot more.
Friday, October 22, 2010
Sunday, September 19, 2010
Reviewing an Agile Implementation
In a couple of weeks, I am going to be performing a formal review of our progress implementing agile software development practices for one of our sub-teams. While agile is a deeply ingrained methodology for most of our team, this one area has some unique characteristics that make adoption both interesting and challenging. Indeed, the team's size (greater than 80 individuals and growing), the inter-organizational and leadership dynamics in play, and the technical environment (SAP) mean that success is not assured. Nevertheless, there does not appear to be anything in this environment that would rule out the implementation of some form of agile software development. While all environments are not created equal, higher productivity, higher quality, and increased developer and customer satisfaction have accrued from past implementations.
Selecting What to Review and How to Review It
Preparing for a review of this magnitude can be stressful. Each decision made in preparation has the potential to expose useful information and provide a deeper understanding of the team and the environment in which they are now working. Unfortunately, those same decisions may inadvertently suppress useful information, resulting in a faulty analysis that generates incorrect conclusions and follow-on actions. A deep understanding is necessary to determine what is truly working well and what is just not working at all—it has ramifications on what happens next.
Multifaceted Approach. Gathering the correct information is essential for any successful review. Since information can be lurking in unexpected places, the best approach would seem to be a multifaceted one. That is, using several different techniques may be the best way to reduce the possibility of missing something important. To best understand what the team is experiencing on a daily basis, staying away from using the review period to question people about performance metrics would also seem prudent. Those types of questions tend to make people uncomfortable and, more importantly, a team that has just begun using agile is not going to fully understand what those metrics mean or how they are influenced. Instead, all of the review techniques selected thus far are intended to pull meaning from each of the interpersonal interactions. They are also intended to help the team better understand their own performance and allow them to think through what they might need to do to make this successful: a tall order.
The Mini Retrospective. Those familiar with agile have most likely heard of the project retrospective. Nevertheless, most have never actually participated in one—at least not along the lines proposed by Norm Kerth [1]. A full-blown review is time consuming, but rewarding. On the other hand, this review is not about a single successful or troubled project (not yet, anyway). Instead, its focus is on gathering enough information about the new methodology surrounding many the projects in this area and to understand where things are going well or poorly. Variations of two exercises that Kerth proposes are well suited to enable the type of breakthrough thinking that will allow the team to explore what they are experiencing: the "develop a time line" exercise [1 pp. 121-126] and the "emotions seismograph" exercise [1 pp. 127-130]. For good or ill, this part of the review is being called a "mini retrospective." While the name may be a bit generous, the goal of deeply understanding what the team is experiencing is the same. Because only a couple of hours are allocated for each scrum team, there there will need to be some work done by the team prior to the discussion so that the entire time is not spent creating the time line.
Talk to the Individuals. You can learn a lot from a conversation if you ask open-ended questions and listen carefully. When your attention is on more than a person's words you become aware of their underlying mood, energy level, and attitude. You can also develop a better understanding of the person you are listening to. This is called Global Listening—it is sometimes also referred to as level three listening. It seems reasonable to conclude that the ability to listen will determine whether these sessions are ultimately successful. (As an aside, I learned about the three types of listening from a class I took earlier this year. I found a pretty good summary of the three levels themselves, if you are interested [2]).
Getting the Team Together. As important as individual conversations with selected team members are, it is just as important to schedule time with the various sub-teams within the wider team to gain insight into the entire group—insight that might not otherwise appear in a one-on-one setting. This group has a complex matrix management structure. That means that there are several different types of groups from which to gather information: the scrums themselves, the management team, the functional leadership team, and the business team, to name a few. These types of gatherings are often called round tables after the table used by King Arthur and his knights: such a table does not inherently grant precedence to any one person. That description seems appropriate for this part of the team review. By maintaining equanimity, individuals are given a forum and the freedom to discuss collective matters of importance about the team, the methodology, or any other pertinent topic.
Let the Leader Present Their Findings. It always seems best to have the people leading a team take responsibility and ownership for conveying the major themes discussed during the early part of the review with their local management team. This may be somewhat counter-intuitive, but the theory is that by having the team's leader present the findings that they and their team worked so hard to identify will help ensure that the information is complete and accurate. This has the added benefit of giving them visibility to their local management team and giving an overall insight into their dedication and competence.
Concluding Thoughts
The aforementioned techniques are intended to cover an array of individual and group meetings during the review. Missing is how we intend to conduct an analysis of the information gathered and how conclusions will be drawn. While these rather important topics remain partially open as of this writing, one thing seems clear: a tentative summary of findings should be available to the team quickly -- before the on-site review period concludes. This will give the review team additional feedback and serve as a further assurance that something important was not missed.
In a few weeks, I will know whether any of this was effective. Either way, I am sure I will learn something.
References
[1] N. L. Kerth, Project Retrospectives: A Handbook for Team Reviews. New York: Dorset House Publishing, 2001.
[2] S. Smith, “The Three Levels of Listening”, http://careersintheory.wordpress.com/2009/09/08/three-levels-of-listening/, 2009, Accessed September 19, 2010.
Selecting What to Review and How to Review It
Preparing for a review of this magnitude can be stressful. Each decision made in preparation has the potential to expose useful information and provide a deeper understanding of the team and the environment in which they are now working. Unfortunately, those same decisions may inadvertently suppress useful information, resulting in a faulty analysis that generates incorrect conclusions and follow-on actions. A deep understanding is necessary to determine what is truly working well and what is just not working at all—it has ramifications on what happens next.
Multifaceted Approach. Gathering the correct information is essential for any successful review. Since information can be lurking in unexpected places, the best approach would seem to be a multifaceted one. That is, using several different techniques may be the best way to reduce the possibility of missing something important. To best understand what the team is experiencing on a daily basis, staying away from using the review period to question people about performance metrics would also seem prudent. Those types of questions tend to make people uncomfortable and, more importantly, a team that has just begun using agile is not going to fully understand what those metrics mean or how they are influenced. Instead, all of the review techniques selected thus far are intended to pull meaning from each of the interpersonal interactions. They are also intended to help the team better understand their own performance and allow them to think through what they might need to do to make this successful: a tall order.
The Mini Retrospective. Those familiar with agile have most likely heard of the project retrospective. Nevertheless, most have never actually participated in one—at least not along the lines proposed by Norm Kerth [1]. A full-blown review is time consuming, but rewarding. On the other hand, this review is not about a single successful or troubled project (not yet, anyway). Instead, its focus is on gathering enough information about the new methodology surrounding many the projects in this area and to understand where things are going well or poorly. Variations of two exercises that Kerth proposes are well suited to enable the type of breakthrough thinking that will allow the team to explore what they are experiencing: the "develop a time line" exercise [1 pp. 121-126] and the "emotions seismograph" exercise [1 pp. 127-130]. For good or ill, this part of the review is being called a "mini retrospective." While the name may be a bit generous, the goal of deeply understanding what the team is experiencing is the same. Because only a couple of hours are allocated for each scrum team, there there will need to be some work done by the team prior to the discussion so that the entire time is not spent creating the time line.
Talk to the Individuals. You can learn a lot from a conversation if you ask open-ended questions and listen carefully. When your attention is on more than a person's words you become aware of their underlying mood, energy level, and attitude. You can also develop a better understanding of the person you are listening to. This is called Global Listening—it is sometimes also referred to as level three listening. It seems reasonable to conclude that the ability to listen will determine whether these sessions are ultimately successful. (As an aside, I learned about the three types of listening from a class I took earlier this year. I found a pretty good summary of the three levels themselves, if you are interested [2]).
Getting the Team Together. As important as individual conversations with selected team members are, it is just as important to schedule time with the various sub-teams within the wider team to gain insight into the entire group—insight that might not otherwise appear in a one-on-one setting. This group has a complex matrix management structure. That means that there are several different types of groups from which to gather information: the scrums themselves, the management team, the functional leadership team, and the business team, to name a few. These types of gatherings are often called round tables after the table used by King Arthur and his knights: such a table does not inherently grant precedence to any one person. That description seems appropriate for this part of the team review. By maintaining equanimity, individuals are given a forum and the freedom to discuss collective matters of importance about the team, the methodology, or any other pertinent topic.
Let the Leader Present Their Findings. It always seems best to have the people leading a team take responsibility and ownership for conveying the major themes discussed during the early part of the review with their local management team. This may be somewhat counter-intuitive, but the theory is that by having the team's leader present the findings that they and their team worked so hard to identify will help ensure that the information is complete and accurate. This has the added benefit of giving them visibility to their local management team and giving an overall insight into their dedication and competence.
Concluding Thoughts
The aforementioned techniques are intended to cover an array of individual and group meetings during the review. Missing is how we intend to conduct an analysis of the information gathered and how conclusions will be drawn. While these rather important topics remain partially open as of this writing, one thing seems clear: a tentative summary of findings should be available to the team quickly -- before the on-site review period concludes. This will give the review team additional feedback and serve as a further assurance that something important was not missed.
In a few weeks, I will know whether any of this was effective. Either way, I am sure I will learn something.
References
[1] N. L. Kerth, Project Retrospectives: A Handbook for Team Reviews. New York: Dorset House Publishing, 2001.
[2] S. Smith, “The Three Levels of Listening”, http://careersintheory.wordpress.com/2009/09/08/three-levels-of-listening/, 2009, Accessed September 19, 2010.
Saturday, August 21, 2010
The Decline of Creativity?
Last month, I read an article in Newsweek that put into words a fear I have been having about creativity in America. The article, "The Creativity Crisis" by Po Bronson and Ashely Merryman [2], appeared in the July 19, 2010 issue of Newsweek and can still be found online.
A little background: The article refers to scores on a creativity test originally developed by Ellis Paul Torrance in the late 1950s and formalized in 1966 as the Torrance Tests of Creative Thinking [1]. The test is similar to an intelligence test in that a psychologist administers it and it requires the performance of discrete tasks over a fixed duration. Instead of deriving an Intelligence Quotient (IQ), it derives a Creativity Quotient (CQ). The article briefly explains the difference between the two tests noting that while the IQ test is subject to the Flynn effect [3]—"each generation, scores go up about ten points," which requires the test to be re-normalized periodically to maintain an average score of 100—while the CQ test, apparently, is not. The implication is that scores on an IQ test may be inflated between re-normalizations. It is unclear to me whether CQ tests can suffer from a similar phenomenon and whether any comparison to past results is truly valid: the article assumes they are. Nevertheless, up until 1990, CQ scores were steadily rising. Since 1990, they have been consistently falling with the decrease in younger children between kindergarten and sixth grade being regarded as the most significant.
While it is unclear whether the premise of the problem presented within the article is completely factual—popular magazines tend to skew information to their audience, do not provide peer reviewed references, and are not themselves peer reviewed—I believe the issue itself is real. The vast information we now have available to us via the Internet and the latest trend toward social networking and online communities would seem to be positive development. Indeed, the recession-induced workplace of 2010 with its "always on, always available" philosophy would also seem to be a boon to businesses, albeit somewhat temporary. The negative, in my opinion, is that these advancements in information availability, trends toward hyper-connectivity, and workplace expectations are systematically eliminating the time available to assimilate and process information: to allow people to think through what they have seen and learned and come up with new ways of solving problems or doing things better.
The need for assimilation time does not mean I think that we should never have deadlines or that we should not attempt to complete our various projects (personal or professional) in a timely manner. Indeed, I have found that in some cases these pressures can help me find new ways of doing things (out of necessity). Yet, these solutions are often not of the same quality as when I have a chance to think them through. While they tend to get the job done in the short-term they may be one-time solutions that cannot be easily repeated or transformed into longer-term success. For me, those ideas that have lasted are those that I had the time to think through, try with some willing participants, and modify upon some reflection and with the input of those same participants. The process is not linear and certainly not easily scheduled against an arbitrary time line. I suspect this is also true of others.
Unfortunately, time is often seen as something that needs to be consumed efficiently and completely. Thinking about new things or reflecting on your experiences does not give the appearance of being productive—at least in the short-term. Nevertheless, I believe this is an essential part of living a full and complete life and is an integral part of determining whether a business ultimately survives or withers away. Most disturbing to me is that I have also come to believe that this is equally applicable to a country that depends on its innovation and creativity.
We ignore creativity and its potential decline at our own peril. As the cartoonist Walt Kelly wrote in 1952 and later modified and attributed to his Pogo Possum character for the first Earth Day in 1971: "We have met the enemy and he is us."
What will we do to ensure we keep our creative and innovative edge? Our future depends on how we answer this question.
References / Links
[1] "Ellis Paul Torrance", http://en.wikipedia.org/wiki/Ellis_Paul_Torrance, Accessed August 21, 2010.
[2] P. Bronson and A. Merryman, “The Creativity Crisis”, Newsweek, vol. CLVI, no. 4, pp. 44-50, July 10, 2010, http://www.newsweek.com/2010/07/10/the-creativity-crisis.html.
[3] C. Graham and J. Plucker, “The Flynn Effect”, http://www.indiana.edu/~intell/flynneffect.shtml, 2001, Accessed August 21, 2010.
A little background: The article refers to scores on a creativity test originally developed by Ellis Paul Torrance in the late 1950s and formalized in 1966 as the Torrance Tests of Creative Thinking [1]. The test is similar to an intelligence test in that a psychologist administers it and it requires the performance of discrete tasks over a fixed duration. Instead of deriving an Intelligence Quotient (IQ), it derives a Creativity Quotient (CQ). The article briefly explains the difference between the two tests noting that while the IQ test is subject to the Flynn effect [3]—"each generation, scores go up about ten points," which requires the test to be re-normalized periodically to maintain an average score of 100—while the CQ test, apparently, is not. The implication is that scores on an IQ test may be inflated between re-normalizations. It is unclear to me whether CQ tests can suffer from a similar phenomenon and whether any comparison to past results is truly valid: the article assumes they are. Nevertheless, up until 1990, CQ scores were steadily rising. Since 1990, they have been consistently falling with the decrease in younger children between kindergarten and sixth grade being regarded as the most significant.
While it is unclear whether the premise of the problem presented within the article is completely factual—popular magazines tend to skew information to their audience, do not provide peer reviewed references, and are not themselves peer reviewed—I believe the issue itself is real. The vast information we now have available to us via the Internet and the latest trend toward social networking and online communities would seem to be positive development. Indeed, the recession-induced workplace of 2010 with its "always on, always available" philosophy would also seem to be a boon to businesses, albeit somewhat temporary. The negative, in my opinion, is that these advancements in information availability, trends toward hyper-connectivity, and workplace expectations are systematically eliminating the time available to assimilate and process information: to allow people to think through what they have seen and learned and come up with new ways of solving problems or doing things better.
The need for assimilation time does not mean I think that we should never have deadlines or that we should not attempt to complete our various projects (personal or professional) in a timely manner. Indeed, I have found that in some cases these pressures can help me find new ways of doing things (out of necessity). Yet, these solutions are often not of the same quality as when I have a chance to think them through. While they tend to get the job done in the short-term they may be one-time solutions that cannot be easily repeated or transformed into longer-term success. For me, those ideas that have lasted are those that I had the time to think through, try with some willing participants, and modify upon some reflection and with the input of those same participants. The process is not linear and certainly not easily scheduled against an arbitrary time line. I suspect this is also true of others.
Unfortunately, time is often seen as something that needs to be consumed efficiently and completely. Thinking about new things or reflecting on your experiences does not give the appearance of being productive—at least in the short-term. Nevertheless, I believe this is an essential part of living a full and complete life and is an integral part of determining whether a business ultimately survives or withers away. Most disturbing to me is that I have also come to believe that this is equally applicable to a country that depends on its innovation and creativity.
We ignore creativity and its potential decline at our own peril. As the cartoonist Walt Kelly wrote in 1952 and later modified and attributed to his Pogo Possum character for the first Earth Day in 1971: "We have met the enemy and he is us."
What will we do to ensure we keep our creative and innovative edge? Our future depends on how we answer this question.
References / Links
[1] "Ellis Paul Torrance", http://en.wikipedia.org/wiki/Ellis_Paul_Torrance, Accessed August 21, 2010.
[2] P. Bronson and A. Merryman, “The Creativity Crisis”, Newsweek, vol. CLVI, no. 4, pp. 44-50, July 10, 2010, http://www.newsweek.com/2010/07/10/the-creativity-crisis.html.
[3] C. Graham and J. Plucker, “The Flynn Effect”, http://www.indiana.edu/~intell/flynneffect.shtml, 2001, Accessed August 21, 2010.
Saturday, November 14, 2009
Combatting Irrational Behavior and your Fear of Correcting it
There are times that we all have to work with other people or organizations —sometimes our own—that seem (to us, anyway) to be irrational. Merriam-Webster defines irrational as follows:
Yesterday, I was contacted by someone who was looking for help. Specifically, they were looking to see if I could help them get a product group to focus on an issue they were having with one of their applications. This issue was happening on two client machines and it was causing them to not be able to complete some testing. The problem had surfaced a few weeks ago and I even recall this same individual mentioning it. At the time, I asked for more details and assigned one of my experienced managers to help, but never got any response. Now, the situation was critical in their mind: if it wasn't resolved, it would go into some nasty sort of escalation that would end in a flurry of accusatory emails deriding our poor support (even though my organization is being asked to help and do not have responsibility for their project—you have to love corporations).
My first thought was that maybe I should get them to answer my original questions. Now that it was critical, I got my answers. The answers were interesting, though, because they indicated that they had found a solution to their problem on the product's web site. They were even kind enough to provide me with a link. Essentially, these two clients had a corrupt install of the base software upon which their application was running. The solution offered? Re-install the software.
Apparently, this re-installation had worked in every other case where they had encountered the same problem. So, what about these two clients? Did they follow this procedure and are they still having a problem? I was getting myself ready to do battle with the product group on their behalf. Alas, you can probably guess the response: No, they did not follow the procedure. These two individuals did not want to take the time to re-install the software.
As I sat dumbfounded looking at the email on my screen, I realized something profound: this type of behavior had to have been encouraged by someone or some cultural factor within that team. Why wouldn't anyone who came across this problem just tell them to re-install the software and move on? The only thing I could come up with is that they were afraid to tell them to do so. (Fortunately, I did not have the same fear and I was pretty blunt: follow the advice of the product's web site and reinstall the software. If you still have a problem, then I will find someone that can help.)
Fear. Being afraid. They are powerful emotions even within the confines of a corporate culture. While I have seen the emotion used as a motivator, it is rare and necessarily short lived. More commonly, it seems that this type of fear prevents people from acting as they should while it obscures real and simple solutions to problems.
I am sure most of us (including me) are victim to this type of thinking from time-to-time. While hierarchy and customer relationships can make it hard to have the courage to tell someone that they are not acting in the best interest of themselves or the company, it is something we ignore at our own peril. The cost of irrational behavior in the case I described is not calculable yet. Nevertheless, the costs are real.
How much will you let irrational behavior cost you?
References
[1] "irrational." Merriam-Webster Online Dictionary. 2009. Merriam-Webster Online. 14 November 2009 <http://www.merriam-webster.com/dictionary/irrational>
(1) : not endowed with reason or understanding (2) : lacking usual or normal mental clarity or coherence b : not governed by or according to reason. [1]As always, a real world example is probably in order—the one that prompted me to write this will do nicely.
Yesterday, I was contacted by someone who was looking for help. Specifically, they were looking to see if I could help them get a product group to focus on an issue they were having with one of their applications. This issue was happening on two client machines and it was causing them to not be able to complete some testing. The problem had surfaced a few weeks ago and I even recall this same individual mentioning it. At the time, I asked for more details and assigned one of my experienced managers to help, but never got any response. Now, the situation was critical in their mind: if it wasn't resolved, it would go into some nasty sort of escalation that would end in a flurry of accusatory emails deriding our poor support (even though my organization is being asked to help and do not have responsibility for their project—you have to love corporations).
My first thought was that maybe I should get them to answer my original questions. Now that it was critical, I got my answers. The answers were interesting, though, because they indicated that they had found a solution to their problem on the product's web site. They were even kind enough to provide me with a link. Essentially, these two clients had a corrupt install of the base software upon which their application was running. The solution offered? Re-install the software.
Apparently, this re-installation had worked in every other case where they had encountered the same problem. So, what about these two clients? Did they follow this procedure and are they still having a problem? I was getting myself ready to do battle with the product group on their behalf. Alas, you can probably guess the response: No, they did not follow the procedure. These two individuals did not want to take the time to re-install the software.
As I sat dumbfounded looking at the email on my screen, I realized something profound: this type of behavior had to have been encouraged by someone or some cultural factor within that team. Why wouldn't anyone who came across this problem just tell them to re-install the software and move on? The only thing I could come up with is that they were afraid to tell them to do so. (Fortunately, I did not have the same fear and I was pretty blunt: follow the advice of the product's web site and reinstall the software. If you still have a problem, then I will find someone that can help.)
Fear. Being afraid. They are powerful emotions even within the confines of a corporate culture. While I have seen the emotion used as a motivator, it is rare and necessarily short lived. More commonly, it seems that this type of fear prevents people from acting as they should while it obscures real and simple solutions to problems.
I am sure most of us (including me) are victim to this type of thinking from time-to-time. While hierarchy and customer relationships can make it hard to have the courage to tell someone that they are not acting in the best interest of themselves or the company, it is something we ignore at our own peril. The cost of irrational behavior in the case I described is not calculable yet. Nevertheless, the costs are real.
How much will you let irrational behavior cost you?
References
[1] "irrational." Merriam-Webster Online Dictionary. 2009. Merriam-Webster Online. 14 November 2009 <http://www.merriam-webster.com/dictionary/irrational>
Tuesday, October 7, 2008
Experience and Enthusiasm - Making Younger Teams Work
When (and how) does a new, inexperienced team become that trustworthy stalwart that you can depend upon to get the job done—competently and efficiently? The question is a difficult one to answer. In large part, it seems to depend on the complexity of what they are doing; the personalities of the team members; the length of time the team is together; and the culture that the team develops as a whole.
Many of us have been witness to teams that come together quickly, do their job, and disband. Those teams are not the norm, though. Usually, a brand new team needs some time to acclimate to its environment and its individual members. This acclimation time can be lengthened when the members of a new team are distant from each other, the team itself is distant from its leadership structure, or the team has a high number of inexperienced members.
To explore this a little further, it seems necessary to define what a team is in this context before discussing the three areas that can impact its acclimation.
What is a Team?
Perhaps the best definition of what a team is comes from Katzenbach and Smith:
Distributed Teams
Distributed, or highly distributed, teams have several unique issues that tend to impact their ability to acclimate quickly. These include: temporal latency, unexposed (hidden) messages, noise, and difficulty establishing trust. There are others (like national and corporate culture) that will not be discussed in this short blog. A short description of how these impact a team's ability to acclimate to their environment follows:
Distant Leadership Structures
Perhaps one of the greatest impacts to a team's cohesiveness and their ability to acclimate to their environment is the proximity of their leadership and the structure overall. While the latter is important to all teams, the former is of particular interest in this context, as it seems to have more of an impact when the team is in its forming stage. Additionally, leadership within a team can take many forms: The formal structure surrounding the team is only one such form. Indeed, it is this informal leadership that seems to increase their capability over time.
Nevertheless, creating a team that begins with a formal leadership structure that is distant from the remainder of the team tends to impede their ability to acclimate to their social environment, in my opinion. It seems unwise to do this. I have seen teams overcome this, but it takes a lot of dedication and work to make it so.
Ratio of Inexperienced Team Members
Having a high ratio of inexperienced team members can to be a double-edged sword: While it can foster a learning environment and be the source of much enthusiasm, it can also generate a lowest common denominator productivity sink that can run a project into the ground—particularly if there are only one or two experienced members and the team is rather large. I have never found a percentage that is perfect, but I think a good rule of thumb is to use 80-20 where possible: 80% of the team should be experienced in some way and in varying degrees while 20% of the team may be inexperienced. Nevertheless, as with most things related to team theory, success is highly dependent upon the individuals on the team. No one would be happy with highly experienced low performers, for example.
Conclusions
The ability for a team to become cohesive and trusted to "get the job done" relies on multiple factors. These include the size of the team (and whether it can be effectively sub-divided, if necessary); the physical and temporal distance between team members; the physical and temporal distance between tem the team and its leadership; and the ratio of inexperienced to experienced members. While each of these factors affect the team's performance, the final determinant is the amount of time invested in making them a high performance unit. Unfortunately, these additional factors make the amount of time necessary variable.
References
Many of us have been witness to teams that come together quickly, do their job, and disband. Those teams are not the norm, though. Usually, a brand new team needs some time to acclimate to its environment and its individual members. This acclimation time can be lengthened when the members of a new team are distant from each other, the team itself is distant from its leadership structure, or the team has a high number of inexperienced members.
To explore this a little further, it seems necessary to define what a team is in this context before discussing the three areas that can impact its acclimation.
What is a Team?
Perhaps the best definition of what a team is comes from Katzenbach and Smith:
"A team is a small number of people with complementary skills who are committed to a common purpose, performance goals, and approach for which they hold themselves mutually accountable [1]."Two parts of this definition lend themselves to further interpretation. First is their use of the term small. While the five other aspects of the definition are "absolute necessities," the addition of the word small is of a more pragmatic value: large numbers of people have difficulty cooperating and working as a single unit and tend to organize themselves into smaller sub-teams. The second part of the definition is not specifically stated, but is implied: team members must be able to easily communicate. Note that the definition does not specifically state that the team must sit together to be effective.
Distributed Teams
Distributed, or highly distributed, teams have several unique issues that tend to impact their ability to acclimate quickly. These include: temporal latency, unexposed (hidden) messages, noise, and difficulty establishing trust. There are others (like national and corporate culture) that will not be discussed in this short blog. A short description of how these impact a team's ability to acclimate to their environment follows:
- Temporal Latency. When individuals are not collocated, communication delays are inevitable. Distance can even encourage additional. While the amount of time and energy it takes to transfer ideas from one individual to another increases, the quality of the communication simultaneously tends to suffer.
- Unexposed (hidden) Messages. Certain communications between individuals would benefit the entire team. Collocated teams more easily disseminate these types of communications due to their physical proximity. For example, if the individuals having a discussion do not realize that the information they are discussing would benefit the entire team, others in the room can bring its significance to their attention. In general, it is difficult to expose surreptitious communications between individuals because the individuals themselves must recognize its importance and expose it. The correction for this is usually communication formality (e.g. documentation), which is the least effective format.
- Noise. Any interruptive influence that can lead to communications misunderstandings or delay is called noise. This can happen in any team environment, but is particularly problematic for distributed teams because of the number of channels a message must pass through and the inherent delay in time between when a message is sent and when it is received.
- Establishing Trust. Lack of trust and cooperation can be fatal to a team. For distributed teams, trust is easy to establish, but is more difficult to maintain over time unless there is continuous interaction. Research suggests that any physical distance can affect the amount of trust and cooperation even if the distance is simulated and regardless of the magnitude.
Distant Leadership Structures
Perhaps one of the greatest impacts to a team's cohesiveness and their ability to acclimate to their environment is the proximity of their leadership and the structure overall. While the latter is important to all teams, the former is of particular interest in this context, as it seems to have more of an impact when the team is in its forming stage. Additionally, leadership within a team can take many forms: The formal structure surrounding the team is only one such form. Indeed, it is this informal leadership that seems to increase their capability over time.
Nevertheless, creating a team that begins with a formal leadership structure that is distant from the remainder of the team tends to impede their ability to acclimate to their social environment, in my opinion. It seems unwise to do this. I have seen teams overcome this, but it takes a lot of dedication and work to make it so.
Ratio of Inexperienced Team Members
Having a high ratio of inexperienced team members can to be a double-edged sword: While it can foster a learning environment and be the source of much enthusiasm, it can also generate a lowest common denominator productivity sink that can run a project into the ground—particularly if there are only one or two experienced members and the team is rather large. I have never found a percentage that is perfect, but I think a good rule of thumb is to use 80-20 where possible: 80% of the team should be experienced in some way and in varying degrees while 20% of the team may be inexperienced. Nevertheless, as with most things related to team theory, success is highly dependent upon the individuals on the team. No one would be happy with highly experienced low performers, for example.
Conclusions
The ability for a team to become cohesive and trusted to "get the job done" relies on multiple factors. These include the size of the team (and whether it can be effectively sub-divided, if necessary); the physical and temporal distance between team members; the physical and temporal distance between tem the team and its leadership; and the ratio of inexperienced to experienced members. While each of these factors affect the team's performance, the final determinant is the amount of time invested in making them a high performance unit. Unfortunately, these additional factors make the amount of time necessary variable.
References
- J. R. Katzenbach and D. K. Smith, The Wisdom of Teams: Creating the High Performance Organization, 1993.
Subscribe to:
Posts (Atom)