Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl: the Markov chain saw

Re: Nobody Expects the Agile Imposition (Part IV): Teamwork

by mr_mischief (Monsignor)
on Dec 07, 2010 at 21:04 UTC ( #875887=note: print w/replies, xml ) Need Help??

in reply to Nobody Expects the Agile Imposition (Part IV): Teamwork

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.

  • Comment on Re: Nobody Expects the Agile Imposition (Part IV): Teamwork

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://875887]
[usemodperl]: perlmonks used to be a safe space for perl coders, now it's like having an annoying girlfriend...
[marto]: I had a feeling I'd regret looking up the definition of 'soyboy'
[Veltro]: usemodperl Maybe it is the way you talk? 'Soy boys', 'old ladies' and what is even a tgimer...
usemodperl is venting, duh?
[usemodperl]: that was a typos, dumbass
[marto]: usemodperl I guess that depends on what you mean by a safe space, since many people seem to have the impression a safe space allows them to do/say whatever they feel like, without question or critque
[marto]: 'typos'->'typo'
[usemodperl]: it's like you guys are retarded or something, no sense of humor? autism?
[usemodperl]: take things too literally, nothing is funny, everyhting must be perfect, or else, SCOLD SCOLD SCOLD, haha
[Veltro]: usemodperl I think you are offensive right now.

How do I use this? | Other CB clients
Other Users?
Others romping around the Monastery: (10)
As of 2018-06-24 15:46 GMT
Find Nodes?
    Voting Booth?
    Should cpanminus be part of the standard Perl release?

    Results (126 votes). Check out past polls.