How Can Enterprise IT Professionals Be Agile?

1. Collaborate, don’t control. Agilists collaborate with others to achieve their goals. They inherently know that communication is critical to their success and they do everything possible to break down any barriers to communication which may exist. They realize that the best use of their time is to actively work with others, that trying to control others from afar via defined procedures or decrees is a futile effort at best.
2. Focus on delivering working software on a regular basis. Software development teams are an important customer of enterprise groups, and the primary goal of software development teams should be to develop software. If you are able to help them to this then you will be perceived as a valuable resource to work with, otherwise you will be perceived as an impediment to success and they will find ways to go around you. Yes, teams are often narrowly focused on their own goals and are usually under tight time constraints, but that doesn’t mean you can’t help them to take enterprise concerns into account without impeding their progress. But it’s up to you to find a way to be an effective member of that team.
3. Focus on working closely with business stakeholders. Active stakeholder participation is a critical success factor for any IT endeavor, be it a single development team, a team of teams, or some sort of enterprise modeling effort. It is easy to forget this, or to convince yourself that you know best and therefore can take on the role of stakeholder, or to give up when your stakeholders claim that they’re too busy to be actively involved. The risk of building something which doesn’t meet the true needs of the business far outweigh the cost of obtaining active stakeholder participation.
4. Embrace change, don’t fight it. Change – truly new requirements, an improved understanding of existing requirements, or new/improved technologies – is a cold, hard reality that we all face. Agilists accept that change happens and find ways to become efficient at responding to change. This can be very difficult at first, particularly because it involves the adoption of a new mindset and new ways of working. In the end, isn’t it better to follow an agile approach which reflects your environment rather than a traditional approach which doesn’t, even though you may not yet be comfortable or familiar with this new approach?
5. Be customer oriented. A primary goal of enterprise architects should be to support and hopefully guide both software development teams and even the business. To do this effectively enterprise architects must be customer-oriented and that implies that they must find ways to work in a manner which reflects their customer base. It is important to recognize that a business modeling team will very likely work in a different manner than a team of seven developers taking an Extreme Programming (XP) approach who in turn will take a different approach than a forty-person Feature Driven Development (FDD) team. Therefore, customer-oriented enterprise architects will find ways to work with each of these groups in a manner which reflects their unique situation. The implication is that an enterprise group must be flexible and prepared to work in ways which may not be ideal for them.
6. Share your skills. An important agile philosophy from Disciplined Agile (DA) is that enterprise professionals should be responsible for sharing their skills with others. Creation and support of development guidance, training of people in enterprise architectural concepts and the architecture itself, and mentoring people in those topics is an important aspect of the overall enterprise architecture approach. Creating development standards and enterprise architectural models is important, but it’s unlikely that they’ll be followed without direct support from the people responsible for them.
7. Adopt a governance approach based on collaboration and enablement. Traditional governance approaches often take a command-and-control approach, which is exactly opposite of the way you should work with intellectual workers. A better strategy is to adopt a lean development governance approach strategy based on close collaboration and enablement which reflects the way that intellectual workers behave in practice.
8. Focus on value. Agilists are constantly asking the question what is the value of doing something, and if there isn’t value then they rethink their approach.
9. Constantly ask if there’s a better way. Agilists will also ask themselves if there is a better way to achieve the same sorts of goals. For example, the fundamental goal of holding a review is to ensure that several people have examined an artifact to ensure that it meets the needs for which it was created and that it was of sufficient quality. There are more effective ways to achieve the same goal: the adoption of practices such as collective ownership, pair programming, and modeling with others ensures that several people will work with the code or models respectively. The point is that you need to question your assumptions, many traditionalists will assume that you need to do reviews because you can’t trust the work of development teams whereas the real problem is that people on the teams worked in relative seclusion from one another and therefore were in a position to create poor quality work that wouldn’t be detected without a review. A side effect these practices is that reviews are effectively held in parallel. Context counts – reviews are “best practices” on traditional teams that don’t promote collaborative work, but they often prove to be ineffective practices on agile initiatives which take a highly collaborative approach.
10. Optimize the whole, not the parts. Many enterprise-level efforts fail when they attempt to sub-optimize one or more disciplines, such as operational database administration or human resource management, instead of optimizing the whole IT lifecycle. The end result is that although your data management processes may be effective on their own, when taken into the overall context of the rest of IT they’re not only out of synch with everything else but they’re actually hampering your organization’s ability to be effective. Optimizing the whole is one of the lean principles.

I hope that you have noticed that my first four strategies are basically rewordings of the four values of the Agile Alliance (AA). The AA has some pretty good advice to share with you, I highly suggest visiting this site on a regular basis.