How Enterprise-Level IT Professionals Can Be Agile

Many people mistakenly assume that enterprise-level activities, such as enterprise architecture or reuse engineering, need to be performed in a traditional and even bureaucratic manner. As we’ve shown with the Disciplined Agile (DA) Framework, nothing could be further from the truth.

The way that enterprise professionals organize themselves and work with their customers, which include both software development teams as well as business stakeholders, can be agile.

My experience is that there are several strategies which enterprise professionals, such as enterprise architects or enterprise data administrators, can adopt to become more agile.

–

Agile strategies for enterprise professionals include:

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 do 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, development 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 project, a program of projects, 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 business stakeholders. To do this effectively, enterprise architects must be customer-oriented, and that implies that they must find ways to work in a manner that reflects their customer base. It is important to recognize that a business modeling team will very likely work in a different manner than a seven-person, co-located agile development who in turn will take a different approach than a forty-person team spread across five time zones. 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 the DA framework is that everyone, including enterprise professionals, should be responsible for sharing their skills with others. Figure 1, which depicts the Enterprise Architecture goal diagram, shows that there are several ways that enterprise architects can support delivery teams. This includes the creation and support of architectural guidance as well as the training and coaching of people in enterprise architectural concepts and the architecture itself. 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.
   

   Figure 1. Enterprise architects should support development teams.

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 IT governance strategy based on close collaboration and enablement that 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 of these practices is that reviews are effectively held in parallel. Context counts – reviews are best practices on traditional projects that don’t promote collaborative work, but they often prove to be ineffective practices on agile projects 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 people 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 Manifesto. There’s some great advice there, I suggest you heed it.