BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News Structuring Messy Product Teams

Structuring Messy Product Teams

Leia em Português

This item in japanese

Bookmarks

Like many consultants and managers Cory Foy, an Agile Consultant, is dealing with an existing organizational structure that has grown by acquisition and evolution into a bit of a monster. The teams were:

The team makeup is a VP at the top who was one of the original developers. We then have QA, Development, Business Analysts and Support. Support is basically an independent entity - we work closely with them, and get their input, but they are self-sustaining.

We have 18 people in the US, and another 30 in an offshore team (that's in the same timezone). We have 2 BAs (soon to increase to 4), 3 QA, and the rest development. On the offshore team, we have about 20 Devs and 10 QA - although their roles are more fluid. We also have 2 US-based contractors for development.

As it stood, teams were doing little work outside their own project mostly due to lack of time. In addition, the release cycles were a very waterfallish 12-18 months. On the good side, QA and Development already worked well together and there was “no throw it over the wall mentality”. He also noted that there are some challenges in middle management – they’re not used to being part of a product shop.

Robin Dymond, Managing Partner at Innovel, recommended to them “Scaling Agile and Lean Development” (Larman and Vodde), particularly the suggestions for feature teams and product owners. He also identified the release cycle as the largest apparent problem.

Cory explained that problem with shorter release cycles is the number of languages that the product needs to be translated into. Not just French, Spanish and German, but also Russian, Hebrew, etc.

Dave Rooney, Agile Consultant with Mayford Technologies, suggested internal releases every 3 months and public releases as frequently as the business needs.

Hillel Glazer picked up on the potential management issues here noting that Cory was brought in by Senior Management and that he can report his current progress highlighting the risks and roadblocks that remain in the path. Hillel emphasized the importance of making these notes as impersonal as possible. “Don't "blame" middle management.  You might be able to go after "conflicting priorities" or "inconsistent information" or something like that.”

Cory says that the organization will start to implement some these changes in August after the current release cycle finishes.

Rate this Article

Adoption
Style

BT