Agile Enterprise Administrators: Supporting Agile Teams in Practice

What Agile Enterprise Administrators Do

It is possible for enterprise administrators to take an evolutionary/agile approach to their work, if they choose to work this way (many unfortunately don’t, see below). Agile enterprise administrators:

1. Work in a collaborative manner. They work side by side with people on development teams as needed. Agile enterprise administrators don’t dictate or try to enforce standards or procedures nor do they try to control the team. They realize that their primary goal is to enable teams to effectively work within the bounds of their organization, and that the most effective way to do this is through collaboration.
2. Work in an evolutionary manner. Agile enterprise administrators will need to support agile software development teams, and because these teams work in an evolutionary manner the enterprise administrators must also work this way. The implication is that they won’t have complete artifacts to work with, e.g you can’t insist that a development team puts a logical data model in place before you’ll help them to identify potential data sources. Agile teams take an agile approach to data modeling and will refactor their database schemas as needed.
3. Communicate their role. Agile software development does not take a command-and-control approach to management. Agile developers won’t jump through the hoops of enterprise administrators just because that’s the way things are done. Instead they’ll work with the enterprise administrators when the administrators actually have value to add to the overall effort. Therefore not only should agile enterprise administrators be able to add value they also need to ensure that their customers perceive that they’re able to do so. Trying to impose your will through onerous processes or management edicts won’t work very well, instead people will find ways to either ignore you or go around you. In fact, there is a technique called blocking which works incredibly well in practice.
4. Mentor agile software developers in corporate standards and guidelines. The goal is to support the standards and guidelines, not enforce them. A good rule of thumb is that if you need to act as the “standards police” then you have lost the battle. Furthermore this failure is very likely your fault because you didn’t communicate the standards well, didn’t gain support, or tried to enforce unrealistic guidelines. If the standards and guidelines make sense, if they’re written well, if they’re easy to conform to then data and application developers will be willing to follow them. However, when the standards and guidelines aren’t appropriate or place an inordinate burden on initiatives then enterprise administrators should expect pushback. Yes, some individuals may chaff at following standards and guidelines but that’s something that team coaches/leaders will need to deal with. In fact, agile methods such as XP include a practice called Coding Standards which insists that XPers agree and adhere to common coding guidelines, and Agile Modeling (AM) includes a practice similarly called Apply Modeling Standards which insists that modelers agree and adhere to common modeling guidelines.
5. Be willing to actively address issues. When pushback occurs an enterprise administrator works with the development team(s) explore and address the problem. Perhaps a standard isn’t appropriate for a new technology. Or perhaps existing logical data definitions need to be updated to reflect new usage. Finally, perhaps the network needs to be upgraded to support a new application. Enterprise administrators must be willing to actively work with team members to resolve issues such as this.
6. Work with the enterprise architects. Agile enterprise administrators work closely with enterprise architects to communicate the constraints imposed by the current environment to the architects. More importantly the agile enterprise administrators need to understand the future direction envisioned by the enterprise architects to ensure that their efforts support the long-term direction of your organization.
7. Adopt a lean approach to governance. Traditional, command-and-control approaches to governance appear to work very poorly in practice. It is possible to take a lean/agile approach to data governance.

A specific activity that an agile enterprise data administator may do is take an agile approach to Master Data Management (MDM). The goals of MDM are to promote a shared foundation of common data definitions within your organization, to reduce data inconsistency within your organization, and to improve overall return on your IT investment. There is nothing inherently special about MDM — it doesn’t need to be complex nor bureaucratic — you can in fact take an agile approach to MDM if you choose to. The critical concepts to accept are that MDM is both an enterprise-level issue and a team-level issue, and that the only way for MDM to succeed is for it to enhance data-oriented efforts on development teams and not hamper their overall progress. Traditional approaches to MDM typically do the exact opposite, and as a result struggle to provide value.

Agile Enterprise Administrators in Practice

Although enterprise administration should be straightforward, and it can be, many evolutionary/agile development teams find existing enterprise administration groups difficult to work with. Some of that difficulty lies in a weak appreciation within agile methods of enterprise issues (hence the importance of Agile Data’s way of thinking (WoT)), be enterprise aware. But most of the challenge lies with the inflexible, often bureaucratic, and often serial approaches preferred by the administration groups. Much of the problem lies in the administration-oriented frameworks such as Control Objectives for Information and Related Technology (COBIT) and Information Technology Infrastructure Library (ITIL) which are invariably implemented in a command-and-control, instead of a collaborative, manner. COBiT and ITIL each have some good ideas in them (ITIL seems to have more, IMHO), but like development processes based on the Capability Maturity Model (CMM) Integrated (CMMI) the final implementation often proves to be less than effective. Many organizations are attracted to these frameworks because they’re seen as the first step towards outsourcing portions of your IT organization: get a well defined process in place, get good at following it, then start outsourcing to lower-cost companies who have also adopted those frameworks.