As an experienced Agile leader and coach, I often run into the following situation. In my opinion, it represents the largest Agile anti-pattern in the product development world. Many teams focus on progress over the product increment.
Progress and Component Teams
Team A says, “We are agile. We are making good PROGRESS on our system.” Upon further investigation, Team A is comprised of team members all specializing in a single domain such as database, UI, middleware, etc. This is what is commonly known as a Component team. Component teams were popular during the Waterfall days, and sadly are still prevalent in today’s Agile world.
Agile is all about creating a small, valuable product increment every iteration that could be released to your customer for feedback or immediate use in a production environment. That’s right – every iteration!
Because of their single-skill teaming approach, Component teams find it near impossible to create a product increment of value every iteration. Most don’t even try. They are making good “progress” in their expertise area by building more and more components using an output-driven mentality. But it’s not about output, it’s about outcomes. The best outcome is a small product increment that could be released!
Component teams typically delay integration and final QA testing until some scheduled point in the future. Deferred integration is a tremendously risky proposition and will likely lead to a schedule slip.
Team A is confusing iterative for Agile. Agile is BOTH iterative AND incremental. To be both iterative and incremental, Agile teams are required to be cross-functional. Cross-functional means that an Agile team has every expertise needed to create a thin vertical slice of meaningful functionality within the system being built. Team A should be reorganized to align around value with a UI person, a database person, a middleware person, an API person, a security person, a QA tester, etc. All Component teams should be reorganized in this fashion.
If your team is not producing a potentially releasable product increment every iteration, then your team is NOT Agile. Sorry, but that is the truth! For reference, re-read the official Scrum guide and see how many times the phrase “cross-functional team” is used.
Does this also apply when scaling Agile? Absolutely.
In the diagram below, the “team of teams” (also known as Agile Release Train in SAFe) is made up of all Component teams. These teams are all making good “progress” while effectively ignoring what truly matters: integration of their parts into a working system increment! In effect, they are executing iterations which add more and more components into the long queue of unvalidated code buffer to be integrated and tested at some later date. The longer this queue gets, the more likely integration will fail. Sorry, but this is not Agile!
For more information on SAFe, visit here.
Product Increment and Cross-Functional Teams
A much more Agile view of multi-team development is shown in the following diagram. Teams are cross-functional and able to produce a small product increment each iteration. System-wide integration and final QA testing is occurring within the iteration allowing the “team of teams” to produce a potentially releasable system increment every iteration. This is the essence of Agile!
Convincing Leadership
Convincing leaders that they are not really Agile can be a tough proposition. Chances are an Agile Coach will have to convince executives, middle management, and organizational leaders of the need to reorganize into cross-functional teams. Organization leaders will be reluctant at first for fear of losing their hierarchy and influence.
Be gentle, be kind. Tell them a story of when you thought the same exact way (guilty as charged). Show empathy and establish trust. Then help them see the tremendous advantages of cross-functional teams and the need for reorganizing around value instead of expertise. Then propose a small trial within their organization, with specific migration steps to full cross-functionality if the trial is successful. It will be.
Good luck, and reach out if you need help!
For more information on what all is involved in an Agile transformation, go here.