A colleague of mine at VersionOne, Dan Naden who works to support the agile community, delivered several open questions from a recent Agilepalooza and asked for help answering. The one that jumped out at me and my experiences was, “How do we change from individuals in workgroups to effective, self-organizing agile teams?”

When I first started looking at this question, I was keying in on the word “individuals” and how individual team members impact our ability to come together and self-organize. The more ideas I got down on paper, the more I came to the conclusion that it is generally not the individual team members who prevent teams from self-organizing and becoming effective. It is usually everything but the individuals that prevent teams from self-organizing. Based on my experience where I’ve lived through an inability to self-organize to efficient self-organization — the individuals are usually never the primary blockers. The things that I’ve seen prevent teams from becoming effective and self-organized are:

  • Agile Teams Are Too Large. Teams that are too big will not self-organize; the team members are made insignificant because their contributions may or may not impact the overall product delivery… not to mention that when teams are too large you will usually see the Alpha team members overpower and control the non-Alpha team members. This is why the recommended team size is in the single digits (I’ve seen the range of 5-8) thrown out there. Not only does right-sizing the team make planning more efficient, but it also reduces the discussion circle, thus making it easier to share information and shorten the time to make and react to decisions that impact the team and the projects.
  • Workspace Challenges. Studies have shown that the right workspace leads to highly productive teams. In talking with many agile teams, it’s obvious that the wrong workspace fosters silos, as well as the perception of meetings purgatory. Ideally teams are co-located and share a workspace that is conducive to easy chair-spinning conversation. A workspace with plenty of whiteboards, private zones, and an information radiator will ensure a well informed, collaborative team. When this cannot be achieved, the use of rapid and personal communication tools can help teams. IRC chat, video chat and online collaboration tools are good ways for team members to collaborate.
  • No Vision. There are multiple layers of vision: company, product, project and team. Obviously a team can control their vision; however, it’s usually a product of the upstream visions. So if the leadership and stakeholders are not sharing the vision – and more specifically, if the team does not have a shared vision of what they are working toward – then there is nothing to bring the team together to achieve. A clearly communicated and shared provision gives a group of individuals a common goal to achieve; this improves focus on decision-making and a clear definition of what it means to be done.
  • The 3 Cs. And I’m not talking about Ron Jeffries’ Card, Conversation and Confirmation. I’m referring to a Command-and-Control Culture. It seems that even once a leadership team decides to adopt agile and they genuinely buy into agile values and principles, the individuals on the teams are still reluctant to take ownership for how to win (a.k.a. achieve). It’s not until the the team is forced to make decisions do they actually make decisions. Team members who have worked in a culture that’s historically command-and-control tend to have either a victim mentality in that they simply don’t believe change is happening, or they are simply scared to put their necks out there in fear of reprisal, even when there has never been a history of this kind of action. The only way that I’ve experienced changing this culture is to have the leadership share the vision and then leave the room (a.k.a. get out of the way). When the team has success, leadership shouts it from the rooftops. And when failure occurs, leadership should ensure that learning and accountability ensues — however, doing so from a distance.
  • Lack of Shared Trust. A core challenge that organizations (the whole organization) have is the inability to trust others to make decisions. This usually stems from two factors: (1) a command-and-control culture that is a result of traditional project/product failures, and/or (2) management team members who have been key to the organization over a period of years and have lived the battles — thus, they feel that because of their experiences they must be a part of the decision. Remember that trust can go both ways; if the teams don’t have that shared vision, then trust of those making decisions is surely lacking.

So how do we change from individuals in workgroups to effective, self-organizing agile teams? We give our teams the environment they need to be productive, provide a clear and shared vision, have leadership get out of the way (yet be there when needed) and finally, we celebrate our small wins and ensure that we learn from our failures. I’ll assume that this stuff sounds familiar; however, if it doesn’t, give the Agile Manifesto a read: www.agilemanifesto.org. I’m sure there are more organizational behaviors, and I’m certain that individuals impact our ability to self-organize. But I firmly believe that everyone has the ability to work as a self-organized team, and if they are empowered to do so, they will do it effectively.

Please let me know what you think. What are some organizational challenges you’ve experienced which have prevented teams of individuals from becoming effective, self-organizing teams? Or do you think the organization has nothing to do with it; it’s the individual team members?

Join the Discussion

    • Josh Gough

      Matt, great article.

      The things you highlight are spot on.

      There are many things to add on from them, but I want to focus on a major issue I have seen recently.

      We know that agile pushes “working software” over comprehensive documentation, and this is good when it means moving from “speculative, overly precise predictive documents” — the kind we see in the worst of sequential, single-pass “waterfall” processes.

      But, I’ve seen a too eager adoption of “just get it on the screen”ism creep into many teams.

      This means teams throwing together prototype level software and doing demos to customers, hiding defects, and leaving features out.

      • Matt Badgley

        Great point Josh, I like you put the “just get it on the screen”ism. One of the points that all teams should take away from this discussion is ultimately it’s about transparency and teams should not be afraid to admit they didn’t finish something or they flat out failed. They should be held accountable, but not to the failure but instead what they do after they fail.

        Thanks for adding on to this topic — it’s not obvious as to how to get teams to self-organize.

    • Josh Gough

      Oops, I had more to say:

      The problem with just cowboy agiling is that these kinds of demos to NOT represent potentially shippable product increments.

      Now, I do not necessarily believe that all features presented to users or customers *should* be shippable. But, those kind of “demos” need to take place during development sprints or otherwise. They should not be presented as shippable increments in a formal sprint review.

      At the end of the day, there is also the human psychology factor at play in many of the points you raised, and it relates to our senses as a whole.

      No sane human being would like to buy a house from a home builder and expect, upon moving in, to find dozens and dozens of defective construction, broken appliances, faulty wiring, etc.

      And, few home builders can get away with kind of thing because most of these features are directly observable and visible.

      Yet, we often hear software developers or managers say a product need “not be perfect” and that the testers or the End Users will find the defects for us, therefore just shovel more code on the fire.

      This situation persists in software because quality is deeper than visible screens, and it cuts right into the heart of maintainability as well. So, if the user cannot see a problem just by viewing the screen, then the problem does not exist, right?

      This is a ridiculous attitude that, sadly, many in our industry continuw to hold. They say that if the customer finds an issue, then it will be a change request, or simply a “bug fix”.

      So, people who follow this mentality, and have survived this way for years, cannot hack their way out of a truly agile, transparent environment alive. Secrecy and power-clutching are very important to them, because it preserves their special usefulness.

      Well, that’s the cyncical view. The apologist view is that these people mistake visibile screens for *completed work* not out of bad intent, but because they are simply *unaware* of what else must be complete from top to bottom in order for a feature to be truly shippable or ready for deployment.

      We can forgive the latter, and must continue the agile emphasis on whole team participation in planning and estimating.

      Yet, some of those same people view whole team participation as either, cyncically, *their job*, or forgivingly, as “not productive”.

      Yet, we know that clear communication is a requirement for success, so this lesson must be taught over and over.

      • Matt Badgley

        Again, great points Josh. As I read this, I was reminded of recent experiences where I’ve seen dev leads take all the issues upon themselves because they think (1) they are shielding the team and (2) only they can do it right. The only result is a continued behavior of defects going out the door. It is a flavor of information hoarding, but the result is that the teams don’t learn and properly retrospect to adjust their own processes and behaviors to improve their output.

    88 − = 79