Certifications are only one of the drivers that are hardening the boundaries between Agile techniques, frameworks and the outside world. Brand ecosystems, made up of proprietary methods, tools, and/or tool suites also tend to contribute to hardening of boundaries, which slows innovation and the evolution of how teams and organizations work. The slowing of innovation and evolution of how work is done is a marker of the beginning of the end of all of the great movements of the past. In this case, specifically the hardening of brand ecosystems marks the turning point of Agile as a movement and perhaps a hint that the dawn of the post-agile age is nigh.
Brand-driven ecosystems carry many of the same upsides and downsides that were discussed for certifications. Most Agile brands are based on or implemented by a tool or suite of tools. Three most critical selling points for brand-driven ecosystems are:
- Structure helps teams and organizations to behave.
- Standard methods are a mechanism to document structure.
- Tools implement standard methods and approaches.
The three critical selling points support the two sets of goals all Agile brands have. The customer-centric goals of brand-driven ecosystems are to make work and communication easier. However, the internal business goals generally are to capture and lock customers into an ecosystem to support the economic needs to the organization(s) selling the brand ecosystem.
While there are positives to brand-driven ecosystems, there are also problems caused by embracing these ecosystems. The problems stem from the unintended consequences caused mostly by the by the second set of goals, which lock in specific points of view and slow or stop the evolution of ideas. Four consequences bear deeper exploration:
- Change becomes difficult. The first unintended consequence of locking into an ecosystem is that change becomes difficult. This a is a common issue seen with nearly all software packages. Brand ecosystems make any change that is outside the boundary more difficult due to the investment in the tool, locking in business processes, and the collection of specific data and history. Just ask any programmer how much fun upgrading a package is if they have made changes to the base code. While configurable tools make change within the boundary of what is perceived as normal practice easy; any deviation outside that boundary is generally difficult. For example, I have observed multiple organizations that have allowed teams (or departments) to define their own data structures for Agile tools. Data structures are used to define what the data that is tracked and reported. Allowing teams to operate without guidance often leads to teams using “user defined” fields differently (each with different usage and validation rules) across the organization making both sharing people between teams and implementing upgrades a horror story.
- Tools define the methods and frameworks. Tools which are typically a part of most brand ecosystems carry their own implied methodology or set of techniques. The methods embedded in the tools are generally proprietary making change difficult if not impossible. I use several Agile tools (and often recommend those tools to others); however, each tool represents a different instantiation of Agile or kanban. Early in the life cycle of a movement competing brand ecosystems are very healthy. The competition acts as a powerful marketing tool to expand the market. As time progresses and market growth slows, brands shift from expanding the market to locking in customers and revenue streams (an excellent example of capitalistic behavior). This change in perspective shifts the intellectual underpinnings of the movement toward the brands and their economic needs from the needs of practitioners.
- Tools are put before the processes. This consequence is a close cousin to the issue with brand defining the method and is a common occurrence in software development (broad definition) environments. Organizations adopt tools in a vain attempt to define how they work without really addressing how Agile (or any other method) is really supposed to work. For example, I recently talked with a SPaMCAST listener whose company had purchased and adopted a very popular tool suite (one that I would have recommended). Once they had the “tool” training, they used that training to define how they would do Agile, rather than learning Agile and then defining how they would use the tool. They used the steps built into the tool to define how they work. They put tool deliverables ahead of customer deliverables. The organization was struggling with the value of using Agile. One example that of this issue shared by another reader of the blog was an implementation of user stories without involving, talking or reference to . . . users.
- Messing with a stable process. In a very similar vein, one of the classic brand ecosystem mistake occurs when organizations try to retrofit stable processes to a tool or brand suite even though they are delivering value and have good customer satisfaction. This is sometimes a reflection of the “grass is always greener in your neighbor’s yard” factor, or sometimes a reflection of letting someone with a checkbook and organizational ADD go to a conference. If how work is done isn’t broken, think really hard about messing with it.
Brand ecosystems do not have to impede the Agile movement; they can actually make life easier. However, as the competition for users becomes more heated, stronger boundaries develop all sort of potential issues can arise. To paraphrase Philip Lew on an upcoming Software Process and Measurement Cast, brands and tools won’t kill agile, people will kill agile with tools. We can buy into and use brand ecosystems, but we need to be very careful that we avoid getting locked. Software development is not easy, once more than one team is involved the degree of complexity increases. Brand ecosystems become almost a requirement to deliver value. Unfortunately, they come with a cost that is often more than just money, part of the cost is the need to ensure flexibility.
Planned essays in Post Agile Age Arc include:
- Post Agile Age: The Movement Is Dead
- Post Agile Age: Drivers of the End of the Agile Movement and Method Lemmings
- Proscriptive Norms
- A Brand Driven Ecosystems (Current)
- A Lack of Systems Thinking/Management
- The Age of Aquarius (Something Better is Beginning)