By: Michael ‘Monty’ Montgomery
Recently, we noticed a common emerging theme, that of the Agilist Rebuke. What seems to raise the ire of Agile practitioners with whom we come in contact (those some affectionately call Agile Priests) is IDesign’s somewhat traditional yet structured and engineered approach to software development. The mere mention of the word, process, inspires them to shout “Blasphemy!” as they spit in disgust. To that we reply simply: “How well is what you’re currently doing today working for you?” The long, pregnant pauses and the sound of crickets that follow are a precious telling truth. Rarely can a dev shop honestly answer this question without wincing, regardless of the process methodology to which they subscribe.
What Voodoo do you do?
There are, of course, a plethora of reasons for these failures. The lack of adoption, advocacy or stakeholder support can certainly contribute, but these are separate issues from the superstitions that often surround Agile implementations. Concepts like task prioritization by voting, self-organizing teams, auto-emergent architecture, storyboard saviors and no docs or design necessary often give the sense that a well formed system will somehow simply be “conjured from the ether…”
But it ain’t all bad…
The Agile Manifesto  was chartered in 2001, by a collection of very senior developers and software gurus. The idea was to shed the glacial pace of corporate software development of the previous decade and reinstate the end user as one of the chief stakeholders in the process.
The central goal was (and is) an honest attempt at mastering the bane of our endeavor, change. How can we as software developers be more responsive to change? How can we be more agile? All of which makes perfect sense. As we’re all now familiar with, the Agile operating model promotes an iterative approach to the construction aspects  of software development.
Out of this comes many practical ideas like daily standups (aka Scrums), small teams, direct stakeholder involvement, breaking large problems into consumable tasks, backlogs, prioritization, iteration, pair programming, testing and a desire for transparency at all levels into the state of software development as it’s unfolding.
But as Agile adoption broadened, issues started to emerge.
Agile at 10
As can be witnessed in a variety of contemporary thought on the problem, the Agile community now acknowledges that the original Agile operating model failed to deliver in real world, enterprise size initiatives. Out of this change in mindset come articles like Scott Ambler’s Agile at 10: What We Believe , concepts like Disciplined Agile Delivery [4, 5] from IBM and a new, much broader Agile SDLC .
Much, but not all, of this new Agile thought is in line with IDesign’s longstanding recommendations on process and architecture. Though in the midst of this sea of change in Agile methodology, one fundamental facet central to the original operating model still persists, that of team composition.
The Generalizing Specialist?!?
The intent of the original Agile operating model was meant not only for small teams, but small teams of experts with broad skill sets. These technicians with ‘mad’ programming skills are now often referred to as ‘generalizing specialists’. In a nutshell, a generalizing specialist  is a developer with multiple areas of deep expertise, along with a general knowledge of nearly everything else.
This definition sounds much like what the industry at large would consider the Architect role of today. A clear thought leader on process, design and technology. With this in mind, it’s evident that only a very senior person will possess such an array of highly desirable talents. Add to this the reality that most modern technologies are what I consider ‘expert technologies’ (i.e. take significant time and skill to truly master), it is nearly impossible to be a ‘deep expert’ in more than one or two tops. How many people do you know who are actually ‘deep masters’ of both Silverlight and WCF? (IDesign Chief Architect, Brian Noyes, may be the lone exception) But you get my point. Does it really take a team of Brians to make Agile effective?
A crack team of seniors is ideal perhaps, but hardly realistic, particularly in today’s arid climate of severe talent drought. Orgs simply can’t afford it, nor does a sufficient quantity of these stars even exist.
Original Agile Manifesto  signatory Andy Hunt, upon observing how the majority of dev shops operate today has been quoted as saying , “…they could have been a poster child for Agile methods...But these weren’t productive developers freed from mindless process dogma. They were Agile slaves.”
He goes on to say, “…they weren’t thinking, they weren’t reacting, they weren’t being agile. When problems came up, they addressed them with all the grace and elegance of a deer caught in the terrifying blaze of alien headlights...”
He concludes the thought with the insightful observation “…they knew how to do Agile; they didn’t know how to be agile…”
I think these observations sum up the industry’s challenges beautifully. The essence of the Agile movement had nothing to do with following yet another form of orthodoxy; it had to do with delivering software agilely. This perspective is also in line with my observation in the industry at large that in the future, business agility will reign supreme. Those organizations that can display a higher degree of business agility will win in the marketplace. And when the pundits, regardless of inclination, speak of business agility it is unilaterally implied that these gains in agility will come directly from information systems that are better designed to absorb, contain and promote change over time.
Hunt’s ‘state of the industry’ assessment coupled with concerns over practical team composition represent two core reasons why I believe the industry has had challenges being effective with Agile initiatives.
The approach that has helped me deliver effectively across a number of different environments of varying maturity is two pronged. The first is a lightweight development process that represents a pragmatic blend of traditional and Agile methodologies. The second is designing for change by leveraging the power of the IDesign Method.
The lightweight development process I often recommend is a simple life cycle laid over top of day-to-day Agile activities and is very similar in spirit to the Disciplined Agile Delivery concepts described earlier. The format consists of four phases; Gather, Design, Build and Validate. And the central ideas that drive the process are the Agile minded concepts of “we iterate on everything” and “just enough…”
Taken literally, this means that iteration occurs within each phase as just enough input is refined, in stages, into just enough output to feed the next phase. Finding the right balance of ‘just enough’ is yet another responsibility of the modern architect and depends largely on recognizing an organization’s culture and capabilities and playing toward its strengths. Unfortunately, one size does not fit all as many pundits would like us to believe, so the hard work of attaining the right balance for a specific circumstance again falls squarely on the shoulders of the architect.
On one end of the just enough spectrum is the reality of an organization lacking even basic development maturity. Here just enough leans much more toward traditional rigor in the form of stringent standards, heavier documentation, deeper design handoffs, frequent reviews and more rigorous process governance. All of which means a much heavier burden for the architect.
On the opposite end of the spectrum lies the hallowed ground of the crack team of seniors. This team can run at a very high velocity, self-organize, self-facilitate and change direction on a dime. Here just enough means very little need be formalized and the original Agile vision is nearly fully realized.
In the middle, of course, are the majority of organizations that possess some level of development maturity, but lack enough experts to reach escape velocity and move completely unencumbered. In these scenarios the architect role is pivotal, as they provide the ‘glue’ that holds the initiative together by delivering consistent expertise and leadership between teams and team members.
As many of you are familiar, the IDesign Method defines a prescriptive approach to designing service oriented applications that better absorb change over time. Designing for change inherently affords a team greater agility, as unforeseen requirement shifts can be better managed through less costly refactoring. Time and again I have seen the net effect of solid design produce a greater degree of agility for a team than all of the Agile techniques combined.
As architects, confronted with the Brave New World in which we find ourselves, perhaps the best thing we can do to be agile is to design systems that are more agile. And if the systems we design are better equipped to adapt to change, then so too might the organizations that we help to build them.
- The Agile Manifesto
a. The charter that started it all circa 2001, Et al
- The Agile System Development Life Cycle (SDLC)
a. Scott Ambler, Chief Methodologist for Agile and Lean, IBM
- Agile at 10: What We Believe
a. Dr. Dobb’s Journal, Scott Ambler, 3/11/2011
- Disciplined Agile Delivery (DAD)
- Disciplined Agile Delivery (DAD) Lifecycle
- Generalizing Specialists: Improving Your IT Career Skills
a. Scott Ambler
- Agile Slaves
a. SDTimes, J.D. Hildebrand, 11/11/2011