The year was 2001. Seventeen software developers gathered together at the Snowbird ski resort in Utah to ski, network and discuss ways to improve what had been until then, standard processes for software development.
The soon-to-be founding fathers and mothers of agile development were tired of the late deliveries, blown budgets and unsatisfied customers that then defined the state of affairs when delivering large-scale, complex software projects. They knew there had to be a better way to do things, and they were right!
After an intense three-day session, the group laid out what they thought should be the main guidelines of software development. Boiled down to its essence, their document detailed the four core values and twelve principles of agile development. They called the document the Manifesto for Agile Development — and the way we go about the business of ‘making things’ has never been the same since.
However, the transition to agile isn’t always easy. It requires a huge mindshift, and people don’t like changing the way they do things. New processes and tools need to be learned and teams are often restructured to remove siloes and enable cross-functional capabilities. What’s more, some teams fear that the speed and flexibility introduced by agile may not be compatible with the types of projects they work on.
Specifically, deep tech-oriented IT teams that implement mission-critical platforms and maintain essential product availability uptimes may be wary about making any big changes in how they do things. And with good reason — any mistakes on their side expose the company to huge business risks and the costs associated with them.
Yet innovative IT teams are finding success with agile — and are reaping operational benefits like increased speed and employee engagement. Their slow and steady approach to the transition and their willingness to find creative ways to adapt to agile are winning the day.
Remember, at the end of the day agile is just a loose set of values and principles that is open to interpretation. It’s all about instilling a foundation of trust, adaptability, ownership and collaboration in the way you do things.
Let’s take a quick look at the 4 core values of agile and see how they fit in an IT team.
Responding to change over following a plan
Now that’s not to say that a plan is a bad thing — there’s no way an IT team can roll out something like regulation heavy financial IT infrastructure without planning first. It just means that change is constant and that the plan shouldn’t be set in stone. An agile IT team that works in sprints is very responsive to change. New features can be added into the next sprint and priorities can easily be shifted between them.
Deliver working software — not documentation
Standard waterfall management calls for a lot of documentation. It needs technical requirement specs, testing plans, design documents and all the approvals that go along with them. The problem is that too much precious time is spent writing and designing these documents instead of iterating and testing the product. Agile IT teams focus on delivering fast iterations and then testing them so that any bugs or issues are identified and handled immediately.
Focus on individuals and interactions, not tools and processes
Talented people not only build products, they also maintain good relationships with customers. Development should be people-driven, as it is people who respond to business needs, understand the customer pain points and drive the development process. Tools and processes are useful as they help drive efficiencies, but if you don’t have talented, people-oriented individuals, not even the best process or technology in the world can help. An agile IT team strives to ensure that they have employees of the highest caliber, with multiple skills to ensure well-run cross-functioning teams.
Collaborating with customers is in; negotiating with them is out
An agile IT team doesn’t negotiate the details of a delivery with its customers. Rather, agile IT teams collaborate with their customers throughout the entire development process. That way, customers can become a part of the team, and provide feedback on progress as it’s deployed. Negotiating product requirements with customers creates an adversarial relationship — definitely not something an agile IT team desires.
Clarizen’s solutions help you simplify work and accomplish goals. From strategy and planning, to work management and execution, Planview AdaptiveWork’s scalable solutions give teams the tools to drive success.
