Agile vs Fragile: How to tell which your organization is
Posted on Jan, 2013 by Admin
This is part 2 in a series of 17. To start at the beginning, first read Agile vs Fragile: A Disciplined Approach or an Excuse for Chaos.
As an executive leader of a testing organization of around 750 testers, I had the opportunity to experience many different development methodologies. Our organization supported multiple software development methodologies including everything from Waterfall to Scrum. I found it interesting that each team approached the methodology differently. I found that of the multiple teams that were touting Agile as their methodology, each one operated differently and each one experienced different results. I remember visiting one team in particular in Lancaster, Pennsylvania. They were an agile team that experienced wild success. When I spent time with the entire team, including leadership, I found that they had completely immersed themselves in Agile. They were almost militant in their discipline around following the methodology. Every employee was trained in Scrum processes and all resources were expected to become a Scrum Master. I found it refreshing that all resources in a leadership position, including the testing leader, were expected to take a rotation as the Scrum Master for a set of sprints. This was a team that “got it”, and should have been studied across the enterprise to see how to replicate their success. Sadly, this was not the case.
With this experience fresh in my mind, I began to look at some of the other Agile teams. They seemed to struggle to make deliveries, and their quality suffered. What made them different from the Lancaster team? Why didn’t they experience the same level of success? They had done a lot of the “Agile” things…they had daily stand ups….they had removed all cube walls and had everyone in a bullpen. Why weren’t they successful?
It didn’t take much digging to find that just because a team calls itself Agile, doesn’t mean that they are agile in any way. These teams were Agile in name only. They adopted the parts of Agile that the developers liked, and shunned any Agile concept that they didn’t like. As I began to discuss my finding with my peers and colleagues I found that they too had experienced similar results with their Agile undertakings. What we found was that these teams weren’t agile at all; they were actually fragile.
I decided to start identifying some of the characteristics of the Fragile organization. To do that, I thought I would give my friends, colleagues, and family (yes I come from a family of nerds) the opportunity to share their experiences and views on Agile. I asked them to identify for me the characteristics of an Agile team that might indicate that the team is actually Fragile and not Agile. I was not surprised by the level of passion that many of them had about Agile. Many of them responded with statements not fit for print. Many were comical, and others absolutely hit the nail on the head. I couldn’t put them all in this blog, so I have consolidated just a few in to a top 15.
Top 15 ways you might be able to tell your organization is Fragile not Agile:
- Every request for documentation is met with resistance because “Agile eliminates the need to document”, including requirements
- Two week sprints are achieved, but only by everyone cramming a six week effort into 2 weeks
- User Stories are defined with less detail than a typical tweet and Epic describes the proportions of most project catastrophes
- Retrospectives either are not done or no action is assigned or taken based on them
- Standard testing, such as Unit, System, Integration or Performance is entirely replaced with feature demonstrations or User Acceptance
- End users are forced to accept substandard feature sets and large numbers of issues in production with only a promise of some future improvement
- Your Agile Coach doesn’t coach
- The burn down chart is really a burn out chart
- You attempt to run a virtual agile team that is spread across a large enterprise or geography
- Done-done is defined by a date, clock, build, deployment or any other mechanism other than working software in production
- Self-directed Teams have degraded into bands of thugs imposing their wills upon the rest of the team
- You attempt to redefine what testing actually is, such as declaring unit testing and system testing equivalent activities
- Your Enterprise PMO and Funding (Tollgate) models are geared for a Waterfall project but you force fit them to Agile anyway
- The “team” is not willing to work on other things that are not in their “job description” (e.g. developers testing, testers developing)
- You recognize the positive behaviors and outcomes as the direct result of your agile process and dismiss all of the bad behaviors and outcomes as failures of individuals
Many of you may recognize one or more of these characteristics in your Agile team. Others may be in tears because all fifteen are evidenced in your team. Still others can create a whole new list of Fragile characteristics for your team. When you look at most failing Agile teams, you will find one or more of these characteristics in play.
In a recent survey of Agile organizations, Voke Research found (Source: Market Snapshot Report: Agile Realities July, 2012, Voke Research):
- Only 28% of those implementing Agile report success
- 19% report that sprints occur as planned with all work completed by the specified sprint date
- 44% report they have no idea about the level of rework in their Agile projects
- 67% of defects are fixed after 4th sprint through release
- 59% of Agile projects proceed without proper business participation
What this research tells us is that most Agile teams are not effective, or are not as effective as they could be. Agile can be done well, as evidenced by the disciplined team in Lancaster, but it can also be just a smoke screen for poor development practices and chaos. Voke found that most Agile undertakings are the result of the “Agile Dilemma”:
“The inherent risk and confusion created when the business desire for speed and flexibility is misinterpreted as a mandate to participate in the developer-centric Agile movement when such participation may not be appropriate for all organizations or projects” Source: Market Snapshot Report: Agile Realities July, 2012, Voke Research
Fragile teams will tout the Agile Manifesto as their guiding principles. They will claim to meet their customer needs, and claim to be more effective than traditional waterfall models. But what you will often find is that these organizations have added a fifth principle to the manifesto:
speed of the delivery over quality of the delivered
This characteristic of Fragile organizations highlights the fact that the focus changes from being on the customer and delivering value to the customer as quickly as possible to focusing on the project timelines and ensuring that something, anything is delivered to production in short sprints. Quality takes a back seat to the pressure to deliver. This is the key to identifying a Fragile organization. When the primary focus of project leadership, project managers, scrum masters, and development leaders is meeting timelines at all cost, then the organization has lost its agile way. They have lost the focus of agility, which is focusing on the customer and delivering value in the quickest way possible, and value can’t be separated from quality. You can’t deliver poor quality value! Agile is speed to value…Fragile is speed to crap.
In the next installment of the blog series, we will begin discussing each of the 12 principles of Agile and the characteristics that both Agile and Fragile teams demonstrate for each principle.
12 Agile Principles
In the meantime…Keep on testing!
