, ,

Last December, I eagerly attended Rebecca Wirfs-Brock’s presentation on Agile Architecture at YOW in Australia (see the presentation here, thanks to the great folk at Eventer).

I sat close to the front and listened very intently.

I left disappointed.

This isn’t really any reflection on Rebecca’s presentation style or it’s content.  I agreed with pretty much everything she said.

I was disappointed because… Rebecca didn’t help me solve my problem.

The problem: how do you convince/influence architects (especially in corporates) to make an open-minded attempt to work in an Agile way?

This is a problem I have quite a lot.  I have a lot of these conversations with architects.  Usually the forum is an “Introduction to Agile” thing.  I rarely get a chance to work with these people afterwards to help embed some of the ideas.  I also rarely leave these conversations feeling confident that I’ve done much in the way of changing perceptions or opening eyes.

I was hoping Rebecca’s presentation might have some new approaches or killer perspectives or insight into these sorts of conversations – unfortunately, it didn’t.

I can see why some architects are sceptical of Agile.  Unfortunately many organisations make software architecture a non-practicing role, so much of the practical advice for delivery teams doesn’t resonate with people where document review, individual research and low/no contact with delivery teams is business-as-usual.  Delivery teams can quickly validate/trial agile through the practices that have a very real, very observable impact on the vast majority of their worklife.  This is not the case for the architecture function in many organisations.

During these conversations with architects (most often architecture groups), I speak of the fundamental problems with BDUF and separation of architecture from delivery.

I speak of the emphasis on the Last Responsible Moment and it’s association with decision making.

I speak of the importance of automation/scriptability and testability when it comes to criteria for product selection.

I speak of the role of the coding architect, with responses ranging from instant (mental) dismissal to open hostility.

I speak of the popularity of lightweight frameworks (e.g., Spring versus EJB) and protocols (REST versus SOAP).

I speak of the logic behind adaptive planning and points-based estimation.

Rarely do I sense that there is a real willingness to embrace these concepts or eagerly try to apply them within their organisations.

I’d hoped Rebecca would give me another approach to these conversations.