big

NOOP.NL | The Creative Networker

“Teams” (The Same Mistake All Over)

19/04/2012

When the students in my classes play the Meddlers game, they often organize teams around projects. Because they have learned, from various Agile sources, that you should “create cross-functional teams around projects”. This means, with small projects, they sometimes group together 3 “cross-functional” people to deliver a piece of software in 2 months, and they call them a “team”.

I think they’re wrong.

Goal-Oriented Social Units

Teams are goal-oriented social units (Esther Derby’s definition). Their goal is not just to deliver a project.

In an environment with continuous delivery and continuous improvement, it is very unclear what a “project” is! The concept of a “project” seems to me a convenient fiction that enables managers to spend budgets. That’s all.

I don’t know what the real goal of a team is. It depends on the team. But I do know that 3 people working together for only 2 months are probably not a team. They are just 3 people working together.

For teams to become social units, they have to be stable and they should have an identity. That takes probably longer than 3 months.

And for them to be goal-oriented, they must have a purpose. That takes more than delivering just one small project.

Organizing “cross-functional teams” around projects is just as short-sighted as organizing “functional teams” around job titles.

It’s the same mistake all over.

Linkedin-32  Facebook-32  Twitter-32  Googleplus-32

This article is written by on in Communication & Relations. Jurgen Appelo is at Happy Melly. Connect with Jurgen Appelo on .

This article was posted in:

  • http://profile.typepad.com/yveshanoulle YvesHanoulle

    Yes with team goal ( or vision)
    Yes with social unit
    No on the time frame.
    Among all the things I do, I am a McCarthy bootcamp trainer.
    These bootcamps, are save environments to learn about teams.
    Jim & Michele have dedicated the last 15 years only to this.
    They have gathered great practices to build teams.
    ( and when they find a new one they try that the next week and they refined it week after week, for 15 years) in other words you won’t find many people who have created more teams then they have.
    They predicatable create teams in less then a week. With people that know eachother for years, or never met.
    I witnessed the creation of a dozen of these teams. Some of them -now more then 5 years later- still have a higher bound then some couples I know.
    And yes these teams deliver a product at the end of the week.
    Y

  • http://boosianspace.posterous.com Paul Boos

    Wow, another supportive argument for teams over projects; Tobias Mayer just posted a couple of days ago a http://agileanarchy.tumblr.com/post/21283149600/team-culture-project-culture
    I followed up with a post that I think that teams need to be grouped around products; they have longer term goals that seem to align well with not organizing around projects.
    For Yves, I don’t think Jurgen is talking about how long it takes to get a team up and running, but rather the lifespan of a team.
    Cheers!
    Paul

  • http://www.benlinders.com Ben Linders

    Setting up real teams (not just for the project as you already mentioned), and keeping the teams stable can bring significant benefits. One organization that I worked with defined fixed teams, based on product lines (http://www.benlinders.com/2011/establishing-and-maintaining-stable-teams/). In stead of managing work in projects, they defined chuncks that the teams could develop and deliver. People in the teams continuously improved how they worked together, resulting in more output. It took some time, but really paid off.

  • Yves Stalgies

    I do not understand the discussion about teams vs. projects. I do agree that the most important thing to establish is a team as defined above with all those ingredients we’ve read about in the books. The team get’s better and better and develops into a real unit.
    But what is the problem about projects in that pictures? Those teams tackle UserStories, tickets, Pizzas and projects. Those teams are similar to the “company-in-a-company” approach and so its dangerous but also not necessary to group teams _around_ things because after a pivot you don’t want to build new teams but perhabs a new product.
    So it’s not about team culture vs. project culture but organic teams vs. hirarchical management structures.

  • http://profile.typepad.com/eaa1 Eaa

    Actually in exercises like this I observe people often making things up to have at least something elaborated to present to the others and actually DO something – which may be a bad idea when doing means changing teams. As our group stayed lean and tried to keep changes at a minimum I am very proud not having sucked as much as the others ;-) – but is it really that simple? As always, context is crucial and as you don’t give much details in the meddler exercise it’s hard to tell what is right or wrong. I have worked with Romanian off-shore teams that evolved into an extraordinary group together with their German product owner and tester just for one project. During an open course at the Potsdam HPI School of Design Thinking our teams changed for each design challenge, which actually was great fun. And not to mention all the open spaces and workshops where some groups go off within minutes showing attributes of extraordinary groups many long lived teams never achieve. All these stories have in common that the environment is Agile so it is actually fun to try to work with different people. I have no data but just observed that firms where people are ‘put together’ to work on projects often come with an command control culture, amplified when projects are sold as services where money and contracts are just rasing the tensions. So having stable teams in such an environment is surely preferable and my rule of thumb would be the more unfriendly command controlish the environment the more robust the teams should be. In cases where the kind of work simply impedes stable teams I would rather focus an agile environment where changing teams becomes easier. It’s really tricky and meddlers is a nice exercise to do, fail and think about this stuff.

  • http://profile.typepad.com/johngoodpasture John Goodpasture

    Jurgen: you are wrong on all points:
    Esther’s definition is wrong: that’s the definition of a group, not a team
    A team is a higher order than a group, elevated by the collective and individual commitment to the goal. In a team, different from a group, there is no personal success unless there is a collective success.
    Yes, three months is quite enough time for a group to form into a team; what is required is intra-group trust to form, and for all three to be all in…one for all; all for one
    Yes, a simple project is a project. What’s a project? something with a specific start and end that delivers something of value to the customer. Yes, in the IT space, the transition to go-live and operations with follow-on bug fixes sometimes makes the “end” look a little murky, but that’s management, not project definition.
    For more on teams, read my book that you rated highly on your list of top 100: “Project Management the Agile Way,making it work in the enterprise.”

  • http://profile.typepad.com/jurgenappelo Jurgen Appelo

    John, you’re wrong. Esther’s definition is not the definition of a group. Because a group is not goal-oriented. Only a team is.
    If people are on another “team” every few months, then those are not real teams in my interpretation of the word. In theory it may be possible to form as a team, in practice I don’t see it happen.
    Finally, I did not rate your book highly on the top 100 of books. First of all, it was on the list because _other_ people rated it. Not me. I haven’t read it. Second, why is it relevant to this discussion that your book was “rated highly”? Does that give your comment more credibility? Please understand that my book was rated much higher, and I’m not using that as an excuse to lend credibility to this comment.

  • http://www.niwotridge.com Glen B. Alleman

    Paul, if you’re spending your own money, no one really cares how you do it. If it’s someone else’s money than a governance processes is needed to assure it’s being spend in the manner agreed to in the “contract” be it formal or informal.
    The referenced Agile Anarchy post is pure speculation, since there is no suggested mechanism for managing other peoples money – especially when that “person” is a sovereign or a near-sovereign (corporation contracting to you for work).
    No where in this types of conversations is the domain and context established. Just conjecture that the suggested process is better than some other process.
    Statements like “The project culture undermines a key principle of effective workmanship: that of focus. While individuals are pushed from project to project a massive overhead of context switching and thus loss of productivity is incurred.” are pure conjecture. No credible supplier of products or services in the project domains I work act in this way. These include software intensive manned space flight, weapon systems, and enterprise ERP for those same firms.
    Jurgen seems to be using the “team” in the absence of a domain and context. We have teams that last a few years to a few hours. They come together to perform work on a shared outcome and hold each accountable for that outcome. As the teams progress other attributes emerge, one of which is trust and another is the social aspect.
    Would Jurgen consider a “pick up basketball team” NOT a team if we only played for a few hours at the Y? Hopefully not. But without a domain and context in that domain, must discussions of this sort provide little in the way of value to the outsider.

  • http://www.niwotridge.com Glen B. Alleman

    John,
    3 months to form a “team” can be very long. I can
    form a team” in 1/2 a hour for our volleyball club season competition. I know some of the team members, we have a short discussion of past experiences – most have played collegiate VB and all have played competitive VB in some way. A quick round of strengths and weaknesses, some discussion of who likes what positions, and we’re off.
    A few matches into the season and those strengths and weaknesses are confirmed. The “team” rules are simple on paper, very complex and emergent in practice.
    I never want to speak for Jurgen – learned that the hard way long ago – but I suspect his definitions of teams, groups, emergence and likely in life experience inform his conversation in a much different manner that yours and mine in our shared domain.
    This is not uncommon, but for the “teams” discussion, you and I both share experiences that Jurgen may not be familiar with in enterprise, defense, space, and mission critical domains.
    Looking forward to our new book as well.

  • http://herdingcats.typepad.com/ Glen B. Alleman

    John,
    I learned here that when there is a definition, it is many times a personal definition, much like Esther’s. It’s rare to see a reference to a glossary of terms, NDIA, AACEI, ACM, IEEE, FAC-P/PM, NDIA, or other professional organization the works on things like definitions, terms, glossary’s and syllabubs’ that can be useful when having conversations with people on the other ends of the wire.
    These are personal definitions, essentially created to suite the needs of the author. So don’t be disappointed when you hear back that a broad, generally accepted definition doesn’t fit the need of the author.

  • http://herdingcats.typepad.com Glen B. Alleman

    Yves,
    Delivering product at the end of the week is not only possible it is common with many teams. We just completed a CFSR (Contract Funds Status Report), where 5 people flew into the customer site, from 4 corners of the US, some had worked together, some were complete strangers.
    A 2 hours kick off meeting, to go over the “goal” – get the CFSR out the door in 3 weeks or less for $150M worth of work to the government.
    Everyone knew their strengths and weaknesses, they roles, their skills and capabilities.
    With a “plan of the day,” and identified participants, lots of Starbucks and good food, the “team” came together and produced the report on time and without any errors. The works requires touching every work activity, producing a bottoms up Basis of Estimate for the work, risk adjusting the duration and cost, and time phasing this information to ask for funds for the next quarter.
    The notion of a small groups of specialist, who hold each other mutually accountable for a shared outcome is the basis of success for any time. From a 3 week team or a 3 year (in this case the science and engineering people doing the work).
    The McCarthy books inform our work as well as other from Katzenbach to Making the Impossible Possible.

  • http://herdingcats.typepad.com Glen B. Alleman

    Yves,
    If you had a team without a project or a project like activity, they’d be production or operations teams. That makes sense.
    But without grouping the teams around “something,” what is the purpose?

  • http://www.niwotridge.com Glen B. Alleman

    Jurgen,
    Really, only teams have goals. Our book club has clear and concise goals, our garden club as well, the “men’s club at the golf course has very clear and concise goals.”
    I seriously doubt any of these “groups” would consider themselves “teams” in the dictionary definition.
    But using that definition (Webster), – of a group – “a number of individuals assembled together or having some unifying relationship” – where is the goal? There are relationships, reading books, planting flowers, trying to lower my handicap, with the help of my paying partners.
    Your conjecture that teams can’t form in less than some time, is of course not supported in fact – at the local Y, basketball and volleyball teams are formed for the night, the weekend, the season – 6 weeks for outdoor VB. We can form “teams” for the summer picnic tennis tournament, or the kids can form “teams” for the softball tournament.
    If it’s your interpretation, OK, but look around in the use of the term to see possibly, that you definition is not the operable one.
    Have you ever joined a pick-up sport with a ball and played for the afternoon? If so, what did you call that collection of players – “Oh I was playing on a basketball group today at the park?” I’d suspect you’d say to anyone who asked “I played on a pick-up team this afternoon.” If you didn’t refer to those men and possibly women, as the basketball “team,” then your definitions are truly different.

  • http://profile.typepad.com/jurgenappelo Jurgen Appelo

    Glen, you’re correct. Different contexts, different interpretations.
    You have read my blog for a while now. You should have known that, in general, I write very little about sports, book clubs, garden clubs, or knitting clubs.
    I write about organizations producing software for customers. The activity of creating software, in general, requires teams that are not formed in just 30 minutes, and only for a few weeks.
    Contrary (I assume) to your book club and garden club activities the work in a software team is highly creative, knowledge intensive, very interdependent, and highly prone to failures. Really, you shouldn’t do that with people being re-allocated to different “teams” every few weeks.

  • Glen B. Alleman

    Jurgen,
    I’m quite familiar with software teams, since 3 out of the 4 programs our “team” works are software intensive products – space flight, satellite communications, ground systems, and embedded weapons control systems, the 4th is a bio-antivirus.
    Reallocating people to different teams in the software intensive world every two weeks or so is simply nonsense, I’ve never seen it. If you have, run away from that firm as fast as you can.
    Arguing against what is clearly seriously bad management, does challenge the credibility of the proposed alternatives.

  • http://herdingcats.typepad.com Glen B. Alleman

    John,
    I came across this. It provides some insight into Jurgen’s “world view,” http://bit.ly/IkopZe
    The team building – social aspects – are very attractive to many in the agile development world. Possibly because they live and work in dis functional organizations. Read down to the paragraph that starts with “we invite you to deepen …”
    The large question is – does this approach improve the performance of projects or programs over some other approach? Without field evidence, it’s hard to say.
    And that’s the rub here, there is no simple means to make that assertion and back it up with evidence, it’s just anecdotal experience. Where in the CMMI world, the IMP/IMS world, the world of A&D Program Performance Management, there is tangible evidence that specific processes, steps, mechanism improve the performance of programs.

  • http://herdingcats.typepad.com Glen B. Alleman

    Jurgen, I’m simply shocked that you of all people would object to an analog to try and connect two worlds…? Something about Goose’s and Gander’s

  • http://profile.typepad.com/jurgenappelo Jurgen Appelo

    Glen, I’m shocked that you’re using my blog as your daily personal diary.