IT infrastructure work is certainly not the same as software development, but the Agile methodologies offer some good advice to us system and network administrators. In general, Agile has grown from a Manifesto about software development to a full-blown project management methodology. Powerful tools are available to help manage projects according to its tenants. Although Agile is based on lessons learned implementing complex software projects, its principles apply equally well to IT infrastructure projects and operations. Agile's concept of "self-organizing teams" is particularly appealing to me, since Applied Trust is managed as a "company of peers".
I've picked five of the Principles behind the Agile Manifesto that are particularly applicable to our field - read on to see how they look from an IT infrastructure perspective:
1) Our highest priority is to satisfy the customer through early and continuous delivery of valuable infrastructure.
2) Welcome changing requirements, even late in deployment. Agile processes harness change for the customer's competitive advantage.
3) Business people and developers must work together daily throughout the project.
4) Simplicity--the art of maximizing the amount of work not done--is essential.
5) Continuous attention to technical excellence and good design enhances agility.
1) "Our highest priority is to satisfy the customer through early and continuous delivery of valuable infrastructure. "
The technical and business requirements documented at the beginning of a project are never perfect, and sometimes not even close to what the end user really needs. Agile emphasizes a focus on gathering customer feedback early and often. Pilot new technologies before making a commitment. I have been part of many IT projects that have met every defined requirement and deadline, but completely failed in the end because users hated the technology. Deploy new technology in phases - find a small group of smart, friendly users who are willing to help test your project as you get new pieces of functionality working. Don't get married to a hardware/software vendor too early. Wireless, two-factor, remote access, and mobile solutions are all hot candidates for an iterative, phased deployment where frequent user feedback is essential for the project to succeed.
2) "Welcome changing requirements, even late in deployment. Agile processes harness change for the customer's competitive advantage."
Agile software development is all about responding to change gracefully, and many system and network administrators could learn a lesson from this attitude. Activities like gathering requirements, documenting use cases, and project planning are essential, but they should never get in the way of "doing what's right" for the end user. Processes should enable agility, not be used as a roadblock by administrators who don't to deal with something new. The Visible Ops Handbook has a great quote on this topic: "Like brakes in a car, IT controls let you go faster!"
3) "Business people and engineers must work together daily throughout the project."
As computer people, we get stereotyped as geeks who are bad at communicating. Let's prove them wrong! Agile encourages the use of crossfunctional teams - this is our opportunity to help the business people and developers "get it right" before we end up supporting a mess of an application in production. Many IT departments suffer from "silo'd operations", where the network folks don't talk to the Windows folks, who in turn don't talk to the Unix folks or the developers. As infrastructure engineers, we build and run the networks and servers - the "glue" that allows our organizations to function. We are in the position to help the diverse teams surrounding us work together.
4) "Simplicity--the art of maximizing the amount of work not done--is essential."
Engineered complexity is the drug of choice for many network and system architects. It's fun to play with bleeding-edge, challenging technologies, but those aren't always the best use of time and money. It's cool to build a system that can support millions of users, but not even worth thiking scalability about for a typical in-house app. Like the Mr. Miyagi said, "Go, find balance." -- balance complexity with manageability, monitoritability, and testability. Although this principle was written by people focused on development/implementation, it applies equally well to operations. Responsible change planning, testing, and documentation reduces unplanned work.
5) "Continuous attention to technical excellence and good design enhances agility."
Agile focuses on customer interaction and working solutions over "comprehensive documentation", but that doesn't eliminate the need for professional behavior. Solutions that are hacked-together without planning and rigorous testing will fail miserably. I can't tell you how many times I have seen a "temporary fix" ignored for months until it blew up in some sysadmin's face! Ward Cunningham describes this issue as "Technical Debt," and if you are an IT person who has not heard the term, you should read about it here. You accumulate financial debt by spending beyond your means - technical debt builds up when you deploy networks, servers, and services without an appropriate investment in solid architecture, testing, monitoring, backups, and reasonable amount of documentation. If you must take on a technical debt, every effort should be made to "pay it off" as soon as possible!
Bonus: "At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly."
Agile encourages picking and choosing individual processes and tools to best fit the team. Is this a cheap hedge? Maybe, but it works for us! For example, we don't actually "stand up" in our various status/operations meetings, and we sure don't use notecards or peer programming. Still, the principles above are useful to help set a "tone" of customer-collaboration, iterative release, and general "agility". Take the "Agile Principles" with a grain of salt, but don't be afraid to steal an idea or two from those programmers!!
Image credit to hickoryhollow113 via Flickr (Creative Commons).
Comments
Ned,
It's interesting to see such strong parts of the Agile Methodology applied to IT infrastructure work. It is amazing to me how much I see that these points fit very well into both IT (at least based on my small amount of work experience in the area), as well as web development (my current job).
It seems that embracing the Agile Methodology can play a large part in the success of a company, even if some parts of it can be frustrating and hard to accept ("Welcome changing requirements, even late in deployment.").
Thanks for giving me a new outlook on the Agile Methodology, and great post!