Introducing an Agile Approach into Your Organization

Introducing the techniques and philosophies described in this chapter will prove difficult in many organizations, particularly those that have an established architecture group that follows a traditional approach. Adoption of agile techniques requires a change in mind-set agile architects are service oriented, realizing that it is their job to help project teams to succeed and to work with senior stakeholders to define and evolve the corporate vision. Agile architects realize that they need to make it as easy as possible for other people to work with them and that they must provide perceived value to the teams they work on. They realize these matters and act accordingly because they know that the people they are supposed to serve will ignore them if they don't. In the end, it's all about people and the way that you interact with them.

Ideally, you'll need to build your architecture team, something that very well could start as a single-person effort, with people who have robust skill sets. If you don't have people like this, which is very often the case, at the very least you need people with open minds who are capable of gaining those skills. These people need the humility to realize that just because architecture is important to them, it doesn't mean that it's important to everyone else. They realize that it will take time to prove themselves and become accepted, and senior management within your organization must allow them that time.

Agile architects must have real-world experience on agile software development projects. They must understand the techniques and philosophies of agile software development, a learning process that could take several years. Simply labeling your existing traditional architects as agile architects isn't going to work they need to live and breathe the agile paradigm before they can effectively support agile software development efforts.

The best way to introduce agile architecture techniques into an organization is to start small and grow your strategy over time. This approach allows you to gain some initial successes, to learn from your experiences (because everything won't go perfectly according to plan), and to evolve your strategy based on those learnings. You need to build a solid foundation from which to work, to build up the proof that the approach actually works.

It is important to have a growth strategy for your architecture team, and the best strategy is to keep an eye out for potential candidates among your development community and then to mentor potential candidates. This is likely the exact same approach you've taken in the past when building traditional architecture teams; the only change is that you have slightly different qualification criteria against which you're judging candidates.