Environment Management in an Agile World

As Agile goes into a full court press, many seem to downplay the importance of environmental management, which is also sometimes known as configuration management. This is usually to the detriment of all concerned.

The focus of Agile is generally on the various aspects of development: Defining what to develop, how to develop, when to develop. But ask yourself this: How many times has anyone talked about environmental management? Automated testing? Production support? I heard nothing about these until my co-worker Keron and I started asking very sharp questions about migration times, data refreshes, and build verifications. Even the instructors for the SCRUM class we attended were befuddled by our questions. It was like it never occurred to anyone that configuration management was important to a successful Agile implementation.

So why is it important? Any derivative of an Agile methodology must include a framework of continuous integration into target environments. This puts the product (process, code, intellectual property, etc.) into a place where you get the most benefit from it in the least amount of time. From a graphical point of view, our ideal SCRUM process flow looks something like this….

Bob Johnson called this diagram the Left Brain/Right Brain Scrum explanation. The actual start and end points are not important; what is important is the understanding of the two very different functions that promote fast turn-around times for any development process. Also, that the ‘team’ goes beyond those in the SCRUM.

The Right Brain is responsible for creativity and pattern recognition: This is the domain of the Development Team. They work the backlog at the discretion of the Product Owner. They get feedback from the Production Support team and make changes as assigned.

The Left Brain is responsible for process and sequencing: This is the domain of the Environment Team. They manage the output from the SCRUM team(s) in a proven, repeatable manner that is easily automated. They gather data about the process to:

  • Implement continuous process improvement.
  • Provide feedback to the Production Owner and SCRUM team(s).

Case in point, one of the repeating tasks that occurred in the environment was a data refresh. The refresh was problematic on several fronts:

  1. Data had to drop down from the PROD environment to the lower environment.
  2. Code had to be promoted up an environment.
  3. The environment specific metadata had to stay in the same environment.

Sounds easy enough, but when you’re talking about 5 databases, >1000 tables, and a ~1.5TB footprint nothing is easy. And, ohh, by the way…you have to do it between Sprints and not slow down development. Without getting in the weeds, we set out a plan (which I’ll write about later in detail) that allowed continuous process improvement to evolve the process naturally and incrementally. The outcome?

A little planning, a little automation and, BAM!, a process that takes a couple of hours. Don’t know about you, but could you imagine the savings of time and resources if you did this with just 10% of your company’s IT processes? (Sniff, sniff) I smell shareholder value!

Leave a Reply