Last December I spoke at the YOW Conferences in Australia on Why We Need Architects (and Architecture) on Agile Projects.
I wanted convince agile developers that emergent design doesn’t guarantee good software architecture. And often, you need to pay extra attention to architecture, especially if you are working on a large project.
There can be many reasons for paying attention to architecture: Meaningful progress may be blocked by architectural flaws. Some intricate tricky technical stuff may need to be worked out before you can implement functionality that relies on it. Critical components outside your control may need to be integrated. Achieving performance targets may be difficult and you need to explore what you can do before choosing among expensive or hard to reverse alternatives. Many other developers may depend on some new technical bit working well (whether it be infrastructure, that particular NoSQL database, or that unproven framework). Some design conventions need to be established before a large number of developers start whacking away at gobs of user stories.
I characterized the role of an agile architect as being hands-on; a steward of sustainable development, and someone who balances technical concerns with other perspectives. One difference between large agile and small agile projects is that you often need to do more significant wayfinding and architectural risk mitigation on larger projects.
I hoped to inspire agile developers to care more about sustainable architecture and to consider picking up some more architecture practices.
Unfortunately, my talk sorely disappointed a thoughtful architect who faces an entirely different dilemma: He needs to convince non-agile architects to adapt agile architectural practices. And my talk didn’t give him any arguments that would persuade them.
My first reaction to his rant was to want to shout: Give up! It is impossible to convince anyone to adopt new way of working that conflict with his or her deeply held values.
But then again, how do new ways of working ever take hold in an organization? By having some buzz around them. By being brought in (naively or conscientiously) by leaders and instigators who know how to build organizational support for new ideas. By being new and sexy instead of dull and boring. By demonstrating results. By capturing people’s imagination or assuaging their fears. Surreptitiously, quietly replacing older practices when reasons for doing them are no longer remembered. When the old guard dies out or gives up.
Attitudes rarely change through compelling discussions or persuasive argumentation. I look to Mary Lynn Manns and Linda Rising’s Fearless Change: Patterns for Introducing New Ideas for inspiration.
I take stock of how much energy I want to invest in changing attitudes and how much investment people have in the way they are doing things now. I don’t think of myself as a professional change agent. Yet, as a consultant I am often brought in when organizations (not necessarily every person, mind you) want to do things differently.
People generally aren’t receptive to new ideas or practices or technologies when they feel threatened, dismissed, disrespected, underappreciated, or misunderstood. I am successful at introducing new techniques when they are presented as ways to reduce or manage risks or increase productivity or reliability or improve performance or whatever hot button the people who I am exposing these new ways of working are receptive to. Labeling techniques as “agile” or “lean” may create a buzz in those that already receptive. But the reaction can be almost allergic in those who are not. The last thing I want do is to foster divisiveness. Labels do that. If I get people comfortable taking just that next small step, that is often enough for them to carry on and make even more significant changes. Changing practices takes patience and persistence. At the end of the day I can only convince, demonstrate and empathize; I cannot compel people to make changes.
I like “Let’s try an experiment.” It’s not a guarantee that people will try it, but for many pieces of change, people will try.
I agree. Experimentation is a good way to see if a new practice or or approach fits/works/has expected benefits. As long as you feel comfortable giving it a shot, and comfortable with absorbing the cost of an experiment (which may or may not yield the expected results), it is a good way try out something new.
Experimentation may work for some slight iterations in architecture but won’t work for an entirely new application stack. For example, I worked on a proof-of-concept project that used XMPP as a replacement for AJAX and I believe that it would have been difficult to realize any benefit if you replaced just one or two AJAX calls with XMPP. The benefit comes in an all or nothing way.
In theory, Agile is orthogonal to architecture. So, evangelizing a new architecture should meet no additional resistence in an Agile shope. In my experience, Agile shops discourage design. The net effect over time is that Agile shops attract developers who do not value architecture and have no time to spend on evaluating new architectures.
Glenn… I agree that I prefer to vet new technology before I made a major investment to use it. A replacement for AJAX doesn’t sound like a small decision. So the amount of time spent investigating/experimenting depends on risks, potential payoffs, and development rhythms (indeed, those doing agile development like to make decisions – including architectural decisions, at the last responsible moment).
However, I personally haven’t experienced that agile shops over time attract developers who do not value architecture. I think they do value architecture, but sometimes they are pushed into poor architecture choices/not enough time to vet significant ideas because managers don’t appreciate the risks (and have swallowed the line that it is always better to deliver something than it is to waste time investigating). And so, architecture experiments that agile devs may make are often grounded in needed to directly support delivering features. Evaluating new architectures may be interspersed with pushing out working code or forced into an arbitrarily short “sprint 0”.