Agile methods have come a long way, shaking off their one-time upstart status to move into the software development mainstream. As a result, these methods are now not only accepted but expected by many organizations. Teams that have not yet implemented them risk being seen as dinosaurs struggling to adapt to modern times.
To avoid feelings of inadequacy and uncomfortable scrutiny, such teams may cover themselves in agile camouflage, borrowing the ceremonies and lexicon of agile methods without fundamentally changing their underlying work habits.
Camouflaged teams meet briefly each morning for a stand-up. They refer to their requirements as user stories, although the actual requirements look little different than when these were called something else. They pull their Gantt chart out of Microsoft Project, divide it up into two-week chunks, called sprints, and enter it into some web-based planning tool that can draw the same kinds of charts that other agile teams are using. At the end of each sprint, they gather to discuss what they have done, and what they hope to do better.
Superficially, these teams appear to be using agile methods, and may honestly believe that they are doing so. But a team using agile camouflage won't reap the benefits of agile practices, any more than someone using a duck call will suddenly be able to fly. So are you draping yourself in agile camouflage, or are you dressed for agile success? If your team exhibits the behaviors described below, you're at least partially camouflaged, and need to embrace agile practices more substantially.
You have hand-offs between sub-teams
An effective agile team operates as a unit, rather than as a collection of discrete sub-teams. Each person may have one or more specialties in which they are expert, but they also have other abilities as well, resulting in a skills profile shaped something like a T, or paint drip. This combination of deep and broad skills allows them to swarm on work with their peers, either taking the lead or lending a hand as circumstances dictate. Their pairings and purviews are fluid, which serves to accelerate learning and concentrate attention in the places where it is most needed at any given moment.
When a supposedly agile team comprises discrete sub-teams, the situation looks different. Architects design, developers code, testers test, and operators implement. People start to ask whether something is "finished design" or "in QA" rather than just "done." Capacity gets bottled up in inelastic reservoirs, reducing efficiency. Iterations inevitably take on a waterfall character, as work passes from one person to another. Design, coding, and testing can't be part of a single, continuous feedback loop, as each is phased, rather than intertwined. Perhaps worst of all, sub-teams make every person's ownership of their work seem temporary and incomplete.
You go all clairvoyant on future iteration planning
Agile methods are largely about humility: They represent an admission that software practitioners generally can't see as far or clearly into the future as they once thought. Detailed agile planning happens one iteration at a time, in a just-in-time fashion, because people can readily plan on such a scale with a reasonable expectation of fidelity. This doesn't mean that agile teams don't plan beyond the current iteration, but rather that the level of detail in their plans is directly related to the immediacy of their work.
For iterations taking place weeks or months into the future, detailed iteration backlogs tend to give way to general features and high-level themes. Strong agile teams recognize that the future is hard to see, and likely to change multiple times before we get there, so trying to map it out in minute detail is a waste of time.
Nonetheless, teams in agile camouflage will slot user stories and specific milestones for iterations occurring far into the future. If a team has the same level of planning for both its next iteration and an iteration that won't happen for months, they are creating a waterfall-style plan. Breaking that plan up into two-week chunks and calling those chunks "sprints" doesn't change its fundamental character as an exercise in clairvoyance.
Such long-range planning does not countenance the assumptions of discovery and adaptation upon which agile methods are built. A team that is not anticipating transformative learning will be unlikely to experience it.
You offer testimonials in lieu of demos
Agile methods generally require that the product owner accept user stories before these are considered fully finished. The product owner accepts the stories after seeing a working demo of the software. An emphasis on working software is critical because user stories are supposed to represent delivered business value, not mere technical activity.
Camouflaged agile teams have technical tasks masquerading as user stories. They decompose their work in terms of software configuration items, rather than user capabilities. When the iteration ends, they may have nothing they can show to a non-technical product owner, so they have to testify that they made progress, rather than showing that they did.
The product owner must take the team at its word, and because there was nothing to see, can't offer feedback on whether they built what was needed. Instead of testifying that the technical constructs were well-built, teams should be demonstrating thin slices of capability that go through all layers of the application and that users can actually evaluate.
Your stories are too big for your own good
High performing agile teams employ a comprehensive definition of done as a way to ensure that a completed story is truly complete This typically includes production caliber testing. They avoid "yeah but" acceptance in which they take credit for finishing a story that is only partially done. This prevents them from fooling themselves about their velocity, and from misrepresenting the current state of the product. It also lets them avoid the context switches that occur when a body of work is left undone and must be revisited again later, sometimes after considerable delay.
Camouflaged teams take on stories that are too large to fit into a single sprint. They know they need to break these down, but rather than pare the stories by functional scope, they break the work into discrete phases (usually development and testing) and author separate stories for each phase. These separate stories are then scheduled across multiple iterations, leaving the product owner to sometimes accept development-only stories that don't represent fully qualified software.
If subsequent testing reveals problems with these stories, the original developers experience thrash as they abandon their work from the current iteration in order to dive back into code they wrote weeks before. Disruptive rework would be substantially reduced if they could instead drive a story to completion in a single iteration with the benefit of thorough and timely testing feedback.
Your retrospectives never lead to change
Agile retrospectives aim at the evolution of processes and practices in response to observed outcomes. When the team reflects immediately on a just-completed iteration, it can identify needed improvements and implement these in time for the next iteration. Constructive reflection and follow-through on identified deficiencies are the hallmarks of healthy retrospectives.
Camouflaged teams hold retrospectives because, like stand-ups, retrospectives are one of the obligatory ceremonies. They discuss what went well and what they would like to improve. However, they end up discussing the same problem in the same way across multiple retrospectives, because they aren't doing anything about it.
Retrospectives exist to catalyze action. Unfortunately, in a camouflaged team the retrospective has mostly therapeutic value, as it provides a forum in which the team can vent frustrations and make tritely nebulous points about "better communication" without actually fixing anything. A team that does not spend part of each retrospective reviewing the changes made since the last retrospective is just going through the motions because it is cataloging problems without actually attacking them.
Dress for agile team success
If your team exhibits one or more of the signs of agile camouflage, then bring up your concerns at your next retrospective, and make sure something gets done about them before the next one rolls around. A team that acts agile will benefit from agile practices, while a team that merely talks the talk will establish expectations that it can't meet.
Keep learning
Take a deep dive into the state of quality with TechBeacon's Guide. Plus: Download the free World Quality Report 2022-23.
Put performance engineering into practice with these top 10 performance engineering techniques that work.
Find to tools you need with TechBeacon's Buyer's Guide for Selecting Software Test Automation Tools.
Discover best practices for reducing software defects with TechBeacon's Guide.
- Take your testing career to the next level. TechBeacon's Careers Topic Center provides expert advice to prepare you for your next move.
