Beefy Boxes and Bandwidth Generously Provided by pair Networks
more useful options
 
PerlMonks  

Nobody Expects the Agile Imposition (Part IV): Teamwork

by eyepopslikeamosquito (Canon)
on Dec 06, 2010 at 05:08 UTC ( #875550=perlmeditation: print w/ replies, xml ) Need Help??

Motivation is culture bound. Most motivation theories in use today were developed in the United States by Americans and focus on Americans ... American motivation theories -- too often assumed to reflect universal values -- have failed to provide consistently useful explanations for behavior outside the United States.

-- International Dimensions of Organizational Behavior by Nancy Adler (p.199)

I couldn't help but notice that people from different cultural backgrounds seemed to react differently to suddenly finding themselves in a self-organizing Scrum team. My interpretations are subjective though, and my sample size small, so I did a bit of research in an attempt to better understand this delicate topic.

It's worth noting that Agile software development practices originated principally in an American cultural setting, while Lean thinking originated in a Japanese cultural setting.

Organizational sociologist and former IBM researcher Geert Hofstede identified five dimensions of culture in his studies of national work related values:

  • Power Distance. How accepting are people of unequal power distribution?
  • Individualism. Is individual achievement or collective achievement emphasized?
  • Masculinity. How much does the culture accept gender roles?
  • Uncertainty Avoidance. How anxious are folks about uncertainty and risk?
  • Long-term Orientation. Do people take a long-term view of their work?
Hofstede found that these five dimensions varied considerably between countries. The United States, for example, rated highest on Individualism, while Russia and India rated highest on Power Distance. Japan scored the highest on the Masculinity index. Russia and Japan have high Uncertainty Avoidance, while Denmark has a low score. Japan, South Korea and India have a much stronger Long-term Orientation than Canada, the UK and the USA. This interesting topic is discussed in greater detail by the Poppendiecks in Leading Lean Software Development.

The experiences of childhood have a huge influence on the way people frame their world -- what is at the center and what is peripheral. We are unlikely to change the cultural frame that we grew up with, but we can become sensitive to cultural differences and learn to understand and respect other cultures. It turns out that there is no one way to motivate people, no best way to organize teams, and no universal rule governing interactions. In addition to cultural differences, each individual has unique strengths, styles of learning, and values.

-- Leading Lean Software Development by Mary and Tom Poppendieck (p.187)

When it comes to forming effective and harmonious teams, the "cultural frame that we grew up with" is only the tip of the iceberg. Other factors potentially affecting team effectiveness and harmony include:

  • Generational. e.g. differing work ethic of Baby Boomers v Generation Y.
  • Individual personality differences. e.g. Introvert v Extrovert, Early bird v Night owl.
  • Personality profile, e.g. DISC assessment.
  • Gender differences.
  • Political beliefs.
  • Religious beliefs.
  • Individual skill levels.
  • Employment history. e.g. exposure to different company cultures and values.
  • Technology preferences. e.g. Open Source, Windows v Linux, Java v C# v C++, Perl v Python v Ruby.

Teamwork

They're malleable, and you know that's what I like really, you know. I don't like people who come here: 'Ooh, we did it this way, we did it that way'. I just wanna go do it this way. If you like. If you don't... Team playing--I call it team individuality, it's a new, it's like a management style. Again guilty, unorthodox, sue me.

-- David Brent (from The Office UK, Series 2, Episode 3)

Steve McConnell lists some characteristics of high-performing teams:

  • A shared, elevating vision or goal. This goal, for example, is hardly inspiring: "Create the 3rd-best database product and deliver it in an average amount of time with below average quality".
  • A sense of team identity.
  • A results-driven structure.
  • Competent team members.
  • A commitment to the team.
  • Mutual trust.
  • Interdependence among team members.
  • Effective communication.
  • A sense of autonomy.
  • A sense of empowerment.
  • Small team size (less than ten).
  • A high level of enjoyment.

and continues to identify team leadership roles:

  • Driver. Controls team direction at detailed, tactical level.
  • Coordinator. Strategic. Makes best use of human and other resources.
  • Originator. Leadership in ideas, innovation and strategies.
  • Monitor. Practical problem analysis.
  • Implementer. Converts concepts into work procedures.
  • Supporter. Emotional leadership. Builds team spirit. Leverages team member's strengths.
  • Investigator. Explores and reports on ideas and resources outside the team.
  • Finisher. Ensures all necessary work is completed in all details. Maintains group focus and sense of urgency.

De Marco and Lister offer a number of interesting suggestions for improving team harmony:

  • Interview Auditions. When hiring a new team member, the candidate is asked to give a technical presentation to the whole team and the whole team decides whether to hire or not.
  • Allow individuals to form their own teams and "bid" for projects. For example, developers who are friends and get along well together could form their own team and bid for a project.
  • Encourage teams to develop their own distinctive personality. e.g. IBM's "black team" used to wear all black clothing.
  • Give project teams a power of veto over release of a product they feel is not yet ready. Put another way, this is following Philip Crosby's advice of allowing the builder to set the quality standard.

Team Structure

McConnell classifies the different kinds of teams as:

  • Problem-resolution. Solve complex, poorly defined problems. People: trustworthy, intelligent, pragmatic.
  • Creativity. Explore possibilities and alternatives. People: self-motivated, independent, creative, persistent.
  • Tactical-execution. Carry out a well-defined plan. People: sense of urgency, more interested in action than intellectualizing.
and further enumerates various team models you might try:
  • Business team. Peer group headed by a technical lead. Can work on all kinds of projects.
  • Chief-Programmer team (what Brooks calls a "surgical team"). Improves conceptual integrity and avoids "design by committee". Needs a brilliant individual. Can work ok with creativity and tactical-execution.
  • Skunk-works team. Take a group of talented, creative developers and put them in a facility free from the organization's normal bureaucratic restrictions, freeing them to create and innovate. Suitable for creativity.
  • Feature team. Cross-functional, empowered team used to develop product. Commonly used at Microsoft (see Dynamics of Software Development by Jim McCarthy). Well-suited to problem-resolution and creativity. Too much overhead for tactical-execution.
  • Search-and-Rescue team. Focus on solving a specific problem. Best for problem-resolution.
  • SWAT team. High productivity through specialization. Usually permanent teams. Best for tactical-execution.
  • Professional Athletic team. Manager clears obstacles and enables developers to work efficiently. Best for tactical-execution.
  • Theatre team (like making a movie). Director maintains product vision and assigns people responsibility for individual areas. Producer handles non-technical aspects: funding, schedules, ... Developers audition for, then accept a role. Perhaps best suited to teams dominated by strong personalities.
There is a trade-off between productivity and flexibility: permanent, specialist teams tend to be more productive than generalist teams.

I'm interested to hear of your experiences with different team structures.

Team Building

Believing that workers will automatically accept organizational goals is the sign of naive managerial optimism. The mechanism by which individuals involve themselves in the organization's objectives is more complex than that. ... Organizational goals come in for constant scrutiny by the people who work for the organization, and most of these goals are judged to be awfully arbitrary.

-- Peopleware (p.124)

Peopleware, while cautioning that you're never guaranteed of success, prefer to use the term "team growing" rather than "team building", and offer some tips for making your organization more likely to grow healthy teams:

  • Make a cult of quality.
  • Provide lots of satisfying closure.
  • Build a sense of eliteness.
  • Allow and encourage heterogeneity.
  • Preserve and protect successful teams.
  • Provide strategic but not tactical direction.
Conversely, they further provide a list of "teamicide" mistakes, likely to inhibit the formation of effective teams:
  • Defensive management.
  • Bureaucracy.
  • Physical separation.
  • Fragmentation of people's time.
  • Quality reduction of the product.
  • Phony deadlines.
  • Clique control.
  • Those damn posters and plaques.
  • Overtime.

Team Commitment

Fast, Good, Cheap. Pick any two.

Here Fast refers to the time required to deliver the product, Good is the quality of the final product, and Cheap refers to the total cost of designing and building the product.

-- Project Triangle

During my first Scrum planning meeting, the ScrumMaster asked each individual in turn to personally "commit" to achieving the Sprint's goals. I felt embarrassed by this strange, quasi-religious ritual and insulted by being asked what I perceived to be a low trust question. Is the ScrumMaster really implying we are not currently contributing our best efforts and will not do so without making this public display of commitment? Perhaps the word "commitment" frightened me due to my past personal experiences and (male) gender.

Update: I now feel vindicated by a recent "clarification" made in the latest Scrum Update (2011) namely: "Development Teams do not commit to completing the work planned during a Sprint Planning Meeting".

Moreover, the Sprint goals seemed arbitrary and uninspiring to me, and the deadline phony. What will happen if we don't deliver those features by that date? Personally, I'd prefer to be inspired and convinced of the importance of the Sprint's goals by the passion and enthusiasm of someone who truly understands and believes in the product -- not by a bureaucratic (certified) ScrumMaster following rules recently learnt on a two-day course.

As you might expect, our first Sprint hit some unforeseen difficulties and it was becoming increasingly clear that we would not meet our committed goals. What to do? I could work more hours to try to catch up, yet that would break my commitment to sustainable pace and 40 hour work week. I could cut corners on quality, yet that would break my commitment to quality and "Definition of Done". Seeing no way out, I asked the ScrumMaster for advice. He solved the problem simply by removing some features from the Sprint. Well, I couldn't see the point of being ceremoniously asked for commitment if such a commitment could be so easily broken. I might add that the team worked very hard and made good progress, but without meeting their commitments due to unforeseen problems and overly optimistic estimating. Despite that, this episode made us feel sad and humiliated because we'd made a public commitment, then broken it.

A job situation that hurts your self-regard is itself "sick".

-- Peopleware (p.144)

Specialists versus Generalists

This InfoQ article provides a good overview of this frequently debated topic.

My view is that the appropriate "specialist" versus "generalist" versus "generalizing specialist" team balance varies considerably, depending on the specific team and project. For example, if writing a Windows-only in-house accounting system in C# and SQL Server, you may well be able to get away with a team of "interchangeable" generalists, where any member of the team can perform any task. Writing a large and complex product in multiple programming languages, running on multiple operating systems, supporting many different third-party databases and other middleware, is a different kettle of fish, however.

Specialists are required whenever the size and complexity of a system grow to a point where they exceed the capacity of a single cranium.

One Size Fits All Teams

Each project's ecosystem is unique. In principle, it should be impossible to say anything concrete and substantive about all teams' ecosystems. It is. Only the people on the team can deduce and decide what will work in that particular environment and tune the environment to support them.

-- Communicating, cooperating teams by Alistair Cockburn

As outlined above, building effective and harmonious teams is a daunting task, there being many individual, team-specific and cultural subtleties to be considered.

I certainly don't have all the answers, yet I contend that forcing all teams in your organisation to uniformly follow the same process for all projects is a strategic mistake. Curiously, when I expressed this opinion, it was felt I didn't properly understand Scrum and accordingly would benefit from attending another Scrum training course, perhaps even gaining a prized "certification".

Certification

I will be discouraging individuals from taking such courses, and HR people and clueless managers from looking for such certifications, particularly demanding them to be considered for an application. I will continue to work hard with my clients and my fellow contractors to have actual track records be considered, not some test one has managed to pass and pay for.

...what matters to me, as a trainer, is that my students can perform and think differently at the end of the class, to be more effective and useful. No piece of paper makes that better or worse. ... there's no need to balkanize the workforce into those who have taken a particular test vs those who haven't.

-- merlyn on certification, Nov 23 2010

Scrum makes it worse by ignoring important (but hard) agile engineering practices, and the Scrum Alliance makes it worse still with their armies of trainers--some good, some not--issuing dubious "ScrumMaster" certificates to people who demonstrated competence in connecting butt to chair for two days.

Or maybe we need to stop selling Agile. Maybe we need to say, "Agile is hard, and you can't master it by sitting through a two-day course". Maybe we need to be firm and say, "Sorry, if you don't use agile engineering practices, if you don't have high-bandwidth communication, and if you don't include a strong customer voice, you're not going to succeed. Try something else instead."

-- The Decline and Fall of Agile by James Shore

Other Articles in This Series

References

Comment on Nobody Expects the Agile Imposition (Part IV): Teamwork
Re: Nobody Expects the Agile Imposition (Part IV): Teamwork
by McDarren (Abbot) on Dec 06, 2010 at 17:12 UTC

    I recently became aware of Daniel Pink and some of his theories on motivation. His TED talk on The surprising science of motivation, where he introduces the Results Only Work Environment concept is quite thought-provoking, and well worth a watch.

    At my workplace, I have responsibility for a number of small software development teams. Each of these teams tends to work with a different technology. We have a Java team, a Ruby/Rails team, a Python/Django team, and a smattering of C/C#/C++/Perl guys. Over the past 12-18 months, we've been slowly switching our development methodology away from the waterfall model towards a more agile approach.

    One of the catalysts that helped get me started on promoting and adopting agile was the following quote from a Joel Spolsky article:

    Some programming teams adopt a "waterfall" mentality: we will design the program all at once, write a spec, print it, and throw it over the wall at the programmers and go home. All I have to say is: "Ha ha ha ha ha ha ha ha!" This approach is why specs have such a bad reputation. A lot of people have said to me, "specs are useless, because nobody follows them, they're always out of date, and they never reflect the product." Excuse me. Maybe your specs are out of date and don't reflect the product. My specs are updated frequently. The updating continues as the product is developed and new decisions are made. The spec always reflects our best collective understanding of how the product is going to work.

    When I decided that it was time for us to start moving towards agile development, I actually printed the above quote in large letters on an A4 sheet and plastered several copies around our office ;-)

    In general, the results have been pretty good. In particular, I've found that web-based development (of which we do quite a bit of) lends itself particularly well to shorter development iterations with incremental functionality enhancements. Users appreciate that we can turn-around feature requests fairly quickly and provide regular updates, and the developers cope better with smaller "bite-sized" stories.

    Getting back to ROWE, one of my teams (my Rails team) has ended up in a ROWE by accident, rather than design. This came about when we simply couldn't find good Rails developers locally, and ended up hiring some contractors in another country. These guys work their own hours, set their own schedules and mostly work from home. My only criteria is that they keep me informed (we use tools such as PT and Campfire extensively) and keep delivering. Which they do. I've found that they are eminently more motivated and productive than the office-based teams working the conventional 9-6 routine.

    The challenge I face at the moment is convincing some of my fellow PHB's that a ROWE is something worth exploring further - as it's quite a paradigm shift ;-)

Re: Nobody Expects the Agile Imposition (Part IV): Teamwork
by ack (Deacon) on Dec 06, 2010 at 17:32 UTC

    Interesting post. Thanks for the perspective and for garnering my interest.

    I have only recently been thinking about this and, hence, this comes at an auspicious time for me. My thinking, admitttedly, relates more to a purely American perspective and regards the challenges that I face frequently in putting together teams on new projects; but recently and unexpectedly it took on a slightly global perspective from an unexpected source: my daughter.

    My daughter, age 12, began attending a private secondary school this year and there are two twin boys from the UK that are in her group. The boys have been here in the US for a couple of years and expect to be here for many more (perhaps permanently).

    There are, of course, the usual interesting and differing language differences that amuse and intrigue the kids. But my daughter noted a more profound challenge that prompted a long discussion between her and myself regarding the cultural differences.

    The essence of the discussion related to the challenges the two boys face when trying to be a part of the young kids' culture and to good-naturedly "fit in" with the gentle teasing that goes on. My daughter's comment was that sometimes the boys "over do it" and their teasing takes on too strong or offensive a note.

    That led to a discussion of how much one's culture framework guides our behavior and can, in unexpected (and even undesired) ways cause us to err when it doesn't fit with a different culture.

    She was intrigued and had some truly impressive insights and ideas about how to help them and was surprisingly sensitive to how hard it would be for her to fit into what their cultural framework might be.

    She noted that a lot of folks think that just learning the language and dialects is enough; but she correctly surmised that such is only the beginnig and that tolerance and allowance for the effects of the cultural framework is even more important.

    That made me think of my own challenges of team formation. Your comments on the "other dimensions" beyond just the ones that Geert Hofstede, IBM, posed, were especially enlightening; they added a lot of important and good thoughts to my own ruminations. The cultural framework (whether from multi-national cultures or even multi-regional cultures within just one country), in my experience, even reaches beyond just team interactions; it also has a surprisingly (at least to me) strong effect on the technical work such as the approaches and paradigms that each programmer utilizes in their individual contributions to the team effort. That difference makes it especially challenging for us to integrate the works of the team memebers into a harmonious "common voice" result.

    Thanks for the post and for giving me a lot more focus and voice to my own wonderings.

    ack Albuquerque, NM
Re: Nobody Expects the Agile Imposition (Part IV): Teamwork
by raybies (Chaplain) on Dec 06, 2010 at 20:50 UTC

    Cool article... very dense... A lot of info you've been studying.

    I'm huge into making my team the best. I find that I consistently end up being the team's cheerleader. People are not machines, and I think they need a lot more encouragement than most managers are willing to give.

    Sometimes I think when management wants to put teammates into a spreadsheet, assigning roles according to some formula that they've studied, rather than focusing on the hurdles of a project, and then they want to press a button and start asking "When you gonna be done?"

    Understanding roles is important, but only if that role and those expectations are clearly communicated to those who are supposed to take up the role--and then the teammates actually step up and take them on. Otherwise it's just going to be one more assignment that's as poorly defined as the project itself.

    When that happens I find my loyalty to a project wanes.

    Another trouble to defining team roles too rigidly is that people change over time--especially as the project becomes better defined. Even I've felt times when my enthusiasm is numbed, especially when my ideas are not given validation.

Re: Nobody Expects the Agile Imposition (Part IV): Teamwork
by sundialsvc4 (Monsignor) on Dec 06, 2010 at 20:55 UTC

    What I find to be a very consistent failure of nearly all “motivational” techniques is ... they expect you to take work, or at least the workplace, personally.   In the USA at least, I think that this notion began to die in the mid-1990’s, and it has plunged irretrievably off of a cliff in the past three.

    By “personal involvement,” I mean that you equate your identity, your feelings and self-image, indeed your life, to the work and to the work that you do there.   You can usually get a good finger on this pulse just by observing the number of personal nick-nacks that a person has in his or her workspace.   If you feel that you can get to know both the person and their children and their neighbors just by looking at the decorations of a cube-wall, you know you’re looking at a person who doesn’t have a life has strongly identified himself or herself with the workplace.

    So, what happened?   Topsy turvy.   Massive layoffs.   Yes, hiring people from foreign lands (“We Work For Less! Always!”) and giving local jobs away to them.   (It happens, by the way, all over the world ... the grass is always greener.)   Giving people only the ability to be “contractors,” sans benefits, where they once could have expected full-time employment and a retirement account.   The message could not have been more clear:   “you need us, and we don’t need you, and the only value to anything that you do can be measured in money.   You are an Expense.”

    Kind of a dumb thing to do, but it was all-the-rage in business books of the time.   Employees went on the defensive, and for very obvious reasons.   Dilbert became a best-selling comic that never ran out of raw material.   And, the game changed.

    Abruptly, employers found themselves competing for resources who were now playing the same game that they once did.   Loyalty could not be obtained at any price.   When one party does not invest in the relationship, he cannot expect any “investment” from the other.   I suspect that it will be many decades (if ever) before anyone again feels that “years of service to The Company” will ever be rewarded – or even that it is safe to do such a thing.

    One of my cousins, who was reasonably happy in his job for about eleven(!) years, found himself displaced ... and, although he is very savvy and landed quickly ... was absolutely shocked to be asked in an interview, “why didn’t you get another job in the last eleven years?”   He might have been making a wry joke, but he actually said to me, “I think the guy suspected I might have been in prison or something.”

    If you are managing a project, I would frankly say that if you want to attract and keep the talent that you need, you’d better spend little time trying to “motivate your people” or second-guessing their psychology (and the culture of their inevitably-far-away country of origin) and a lot of time trying to make your project the best-run project you have ever seen.   If you observe that the people seem to be “un-motivated,” then the brain-drain has already begun and it is happening from the top.   If you lose ’em, you probably can never get ’em back.   Go look into a nearby mirror until you see where the problem is.

Re: Nobody Expects the Agile Imposition (Part IV): Teamwork
by mr_mischief (Monsignor) on Dec 07, 2010 at 21:04 UTC

    There's a problem with the whole term "team". There is especially a problem the way it is used, with multiple "teams" in a company. I'm not sure exactly how to replace it, but it is worth investigation.

    A "team", you see, is a group of people each assigned a position working toward a common goal with definable victory conditions. A fire team wants to accomplish a military mission and preferably lose no team members. A sports team wants to have a winning season and preferably do well in some post-season playoffs. A team of doctors wants to help as many patients as possible as fully as possible without causing harm to any.

    What is your victory condition when you put together different software development "teams"? Is it shipping one project on time? Is it getting the best behavior out of every line in terms of the spec? Is it shipping projects for the most money with the lowest cost to the company regardless of bugs and misfeatures? Unless there's a goal the group shares, it's not a team.

    Furthermore, unless an organization fields multiple products with different goals, the whole organization should really be considered one team. One owner may have multiple racing teams in a circuit, and one baseball club may have teams in the MLB and several levels of minor leagues. Each has a separate individual goal, but usually there's one overriding goal. A baseball club will not hesitate to bring a start player out of the minors for the sake of the major-league team. Winning the games in the majors is more important to the organization overall. A NASCAR owner will want the best finishes for all his cars up until one driver's team needs points toward the season championship and the other is out of the points race. Then, one driver will often willingly and readily slow the pack behind the other "team"'s driver from the same owner, even if it means a worse personal finish. If you truly have different teams reaching for different goals, make sure they know what the overall organization's goals are when their team goals intersect at odd angles. Friendly rivalry probably isn't a problem, but when you cast people as separate "teams", be careful the rivalries stay friendly.

    Teams in different pursuits are managed differently. A professional sports team needs some experienced players, but some youth is helpful both for athleticism and for keeping salaries below caps (in leagues that have such things, like the NFL). Some players can stay physically competitive for fifteen or twenty years, but not many. Many companies manage their intellectual workers like professional sports teams, though, and to ill effect. If a company (at least in a Western mostly capitalist economy like the US) is making money from selling its products and services, then any cap on salaries is not set by a league but is arbitrarily set by management. The productivity of the workers is not necessarily hurt by age, especially in an intellectual rather than physical type of work. In fact, it often increases with experience. Yet skimming the pool to remove the cream is an alarmingly common practice. A cheaper younger worker is not necessarily interchangeable with a more experienced one. Two cheaper, younger workers will fill a department faster than one more experienced worker, but will not necessarily produce any more useful work (or, truly, as much).

    If you're making money, be willing to spend money on the resources that are making it for you. Creative and engineering talent are not overhead in a company producing software as a product or consulting as a service. They are the bread and butter of the organization. Cutting expenses by cutting productivity is not really cutting expenses at all. It is dumping valuable primary assets, which is something only moribund companies should be doing.

    If your employees know that their jobs are secure so long as they contribute to the company goals, then you have the very start of what could be called a team. If you treat your employees as arbitrarily replaceable, you will never have a team at all. That's what professional sports organizations that have a history of competitiveness know. In a well-managed league no team can win every championship, and it is not likely even to have a winning season every season. Some teams, though, have a history of being sad-sack losers and some a history of being at least a factor season after season. Some go through a rough patch and don't come back as teams that matter by recruiting new players until the coaching staff is also replaced. If you have no caps, despite shareholder pressure, then pay as much as you must in salaries to make sure you make a successful product. Keep the key players and recruit only to enhance your team. Never recruit new, cheaper blood just to meet some arbitrary cap unless you're actually trying to limit your competitiveness in your league... umm, I mean "market".

    Some markets are just competitive. They have not just a high cost of entry, but also a high cost of continued access. If you deny your company the cost of access to the market, you deny yourself the market. No amount of managing a team that is limited in talent, resources, and training by arbitrary cost figures will make up for that. Your group must have talent, training, and resources enough to compete or they simply will not compete.

    Speaking of training, there's one thing a team has that many so-called "teams" in industry are denied. If you're recruiting people based on talent and training they already have but deny them any further coaching and training, you will lose. Oh, you might get a star player trained by some other team as a free agent, but he'll be gone again when he's offered more money elsewhere. For continued excellence, sports teams condition and coach their healthy athletes to be healthier and more skilled. They heal their injured players whenever possible. They provide facilities and personnel to improve even their best players. They have training during their off-season and continued training during their seasons. Some train three or four times as often as they play. In high school, an American football team might train five or six times as often as they play.

    Yet in the IT industry, it is often expected that a person's training is over at the point of hire or that the employee is responsible for all of their own training on their own time. That's not how teams are built. Teams are trained together. Coaches may use individual strengths from previous training, but they also try to train away deficits. They also learn to play as a team by practicing as a team. A team that doesn't practice well together doesn't play well together. I'm not talking about an annual rope ladder and mud puddle "team building" exercise. I'm talking about teammates building useful projects together that are used internally before and between building projects to ship. A team knows how to perform together when under competitive pressure because they perform together when they aren't.

    The team members know as individuals that so long as their contributions to costs ratio outweigh those of other prospects that their positions are safe. This is in teams with a maximum number of fielded players and a maximum number of rostered players. Yet what many in IT call a "team" has no such guarantee to its members. The single most valuable player may be removed from a team not because of retirement, free agency (the player seeking a better deal), injury, or a trade to fit under a mandatory salary cap. He or she may just be gone. Maybe he or she performed 60% of the really useful work out of a team of ten. Maybe the quality of work produced by others around him or her was improved by example. But perhaps that information was lost in management who doesn't know how to coach. Perhaps the business school taught about managing projects, time tables, and "teams". Maybe they didn't teach coaching and training of valuable personnel and actual living, breathing, interdependent teams.

Re: Nobody Expects the Agile Imposition (Part IV): Teamwork
by talexb (Canon) on Dec 11, 2010 at 16:09 UTC

    This whole investigation into agile programming is fascinating, and having been exposed to it at my current job, I'm beginning to wonder about what the overarching goal is. Certainly, one of the goals is to make sure the required productivity objectives are met -- bugs are squashed, and features are implemented. But that happens in a normal development process. So how is agile different?

    I think the answer is that it allows management one level above the teams to keep a very close eye on what's happening at the ground level. The problem, of course, is that reality intervenes, with its expected delays on the carefully planned schedule. A production emergency arises, a high level feature must be implemented right away; someone is sick -- and the carefully drawn out schedule gets re-written.

    What I don't think is covered by the agile process is what happens when the developers are done their due diligence, and the software needs to be staged and then deployed. You might do a small fix (less than a day of development) that needs days of testing. If the developer had to be on hand for the testing, whose budget does that come out of?

    However, I agree with some of the agile ideas -- I think the daily stand-up meeting (where everyone on the team talks about their first three priorities of the day, and any possible roadblocks) is an excellent idea. I also think it's important that team members keep the team lead informed throughout the day, if their rate of progress changes dramatically (either "I got this done early" or "I'm having a problem with Vince again").

    But I'm not so sure that making up estimates for each individual task is such a great idea, since estimating how long writing a piece of code is tough to do. Certainly, we can guess it will take 4-8 hours, but from a scientific point of view, that's hilariously imprecise (6 +/- 2 is an uncertainty of 33%).

    I think I have a Meditation brewing. Great post, thanks so much!

    Alex / talexb / Toronto

    "Groklaw is the open-source mentality applied to legal research" ~ Linus Torvalds

      I also think it's important that team members keep the team lead informed throughout the day
      Agreed. However, that is not Scrum, as prescribed by the (recently updated) Official Scrum Guide: "Scrum recognizes no titles for Development Team members other than Developer". So, if you have a "team lead" title, you are not practicing Scrum.

      I further noticed that the Scrum Update (July 2011) clarifies that "Development Teams do not commit to completing the work planned during a Sprint Planning Meeting" ... which agrees with my opinion, expressed (strongly) above in the "Team Commitment" section! :) Maybe our (certified) Scrum Master back then didn't know the Scrum rules as well as he claimed. However, after comparing to the official Scrum Guide of February 2010, my reading is that he was accurately applying the 2010 Scrum rules and that this July 2011 "clarification" is actually a rule change.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://875550]
Approved by planetscape
Front-paged by planetscape
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others pondering the Monastery: (10)
As of 2014-08-22 21:22 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    The best computer themed movie is:











    Results (165 votes), past polls