As an IT manager, you have probably been asked to support the agile development process. Buckle up. This means you need to be reactive and proactive at the same time.

Being reactive takes adequate planning, enough so that IT will resolve support issues in a timely fashion. That means you need clear team roles and well-defined workflow.

Your team also needs to be proactive. And you need to understand the agile process and development lifecycle, its needs, and its pain points. That way, you can position your team to anticipate the needs of the agile development teams, with respect to choosing and supporting tools and software, as they come and go in the market.

On top of that, one of the challenges IT will face is that the fit between the fast-moving agile development teams and an established enterprise architecture may be not well defined. At its worst, the two will clash, creating unnecessary bottlenecks and inefficiencies.

Here’s how to keep balance:

Establish a Service Level Agreement

Normally, SLAs define the formal understanding between the developer and the client, which reduces the risk of failure and establishes and maintains trust. In this case, the agile development teams are the clients. IT can create its own SLA between its support teams and the agile teams they are working with. Establish what IT support can and cannot do for agile developers with respect to hardware, software, and applications at all levels.

Make it clear who in the support organization is responsible for what kind of service, what average and guaranteed response times will be, how calls will be tracked, and when and how issues will be escalated.

Establish your support workflow

Have you mapped out your workflow for support? Doing so can be a real surprise – and a real help to your group. Referring back to your SLA, map out all of your support processes. How is a call for support managed from beginning to end? Who needs to know? Who is responsible and accountable? How is the ticket closed? When is it escalated? And what is your timetable? The more detailed you get, the more useful this step will be.

Once you establish the workflow, do a reality check to see how well it works for several recent IT support calls you’ve received. Ask and answer these questions with your IT support team:

  • Are there are any patterns that can be resolved by different technology choices or teams? Could IT service costs be reduced with a different workflow?
  • Are requests getting hung up somewhere?
  • Do you have a quality review/control process? If so, when and where is it implemented?
  • How efficient is your tool organization, call process, and call resolution?

Establish standards

Establish and maintain standards both internally for the support team, and if appropriate, for the agile teams. These standards should include everything from tracking and closing-out requests (for the IT support teams) to file naming conventions and code documentation.

What are the internal and external standards you need to implement? How will you communicate them to your agile teams? Standards may create pushback in the beginning, but the more your team uses them, the more second nature they become.

Be proactive about technology evaluation

IT support shouldn’t just happen at the “back end.” Helping teams select and evaluate tools that support the business mission can be a critical dimension of the role of IT.

If a team has preferred choices, IT needs to know why. Is it for security? Ease of use? Scalability? IT can present questions and evaluate responses through trials and research. For example:

  • Is the technology “mature?” That is, are the tools secure, reliable, maintained, and have a large user community? Or are the tools an innovative and untested technology? Different teams may need or expect different levels of maturity. New project management and collaboration tools are always on the market, but investing and relying on them can be an expensive gamble if they don’t support your processes…or just plain fade away.
  • Does the technology support the team’s goals? Again, different teams will evaluate usability differently. Providing honest assessments of core and optional functionality–file sharing, metrics, versioning, security, communications, usability, recording milestones and handoffs–are all part of the evaluation process that IT can provide.

In short, the principles that have made agile development work so well in so many design applications can be implemented into the support of those agile processes. Focus your support resources and energies on individuals and teams and their interactions with each other – not on hardware, software, and systems – and the right tech solutions will follow.