Self-organizing teams produce the best architectures, requirements, and designs.

self-organized team

The above statement is one of the principles behind the Agile Manifesto. Too many “Agile” teams struggle to get this concept.  They have the Agile ceremonies down, and they may even sit together, but they still work in silos based on waterfall principles.

The following statements are all signs that a team is struggling to adopt the Agile self-organizing team behavior:

  • “I can’t work on the design because the requirements aren’t complete yet.”
  • “I can’t create any test scenarios yet because the design is not complete.”
  • “I can’t start development, I have to complete a design document first. “

In Waterfall, the requirements and design process looks like this:

In Agile, it looks more like this:

It’s a cluster of work that happens together. The process gets messy and entangled, in a good way. There are no long drawn out separate phases of development or QA. All the work is happening together, and cross functional team members collaborate through the whole process.

When the team is self organized, that’s when great ideas and valuable products emerge. Why wait for a long period of time for requirements to be completed by a BA, only to be reviewed by the team at a later date? Or wait for a design or dev to be completed, only to be reviewed later?

As Deming used to say, you don’t inspect quality into a product, quality is built-in up front.  Why not use that same principle for how we treat requirements/stories, designs and tests? Instead of inspect quality into them, let’s build the quality in up front by having all team members contribute to the work.

About the Author: Mike MacIsaac is the owner and principal consultant for MacIsaac Consulting. Mike provides leadership as an IT Project and Program Manager as well as an Agile Scrum Master. Follow Mike on Twitter @MikeMacIsaac or subscribe to Mike’s blog.