In the coming weeks, we’re going to explore how the principles of Agile can be applied to IT service. In this first article, we’ll provide a basic overview of the concept of Agile itself, particularly because this simple concept often is made overcomplicated by some who adhere to it.
The general precepts of Agile are available for interpretation by anyone and applicable to anyone. At its simplest, Agile simply means continuous incremental improvement through small and frequent releases.
The term Agile is most commonly associated with software development as a project management methodology. To make it crystal clear, I’m going to use an example of Agile in action with the development of a smartphone.
Here's how it works:
Someone comes up with the idea for a new phone and decides to put a hefty computer chip into this new device. They need an operating system, so a project begins to build the new software. The team lists all the basics they need to make this thing work; along the way, they collec lots of ideas for cool features, and these are formally called issues. This list of issues is formally labeled a project backlog.
Next, the team has what is called a sprint planning meeting. In the sprint planning, they sort through and prioritize all these issues. The Issues are grouped together into what are known as sprints (a short run) that focus on a specific group of tasks.
One sprint contains all the tasks that must be completed just for this new phone to be able to make and receive a call. Another contains all the cool features that will drive potential customers to want to own one of these phones. And still another sprint contains features that will be a little harder to implement, but certainly should be included someday soon. The initial sprint planning produces the first few sprints that, when complete, will allow the release of a working phone with cool new features that make users want to own one.
Once the sprint order is set, the team begins working through the first sprint backlog that has all of the things required to get this phone to work. They have a reasonable deadline and they have daily or weekly scrum meetings to make sure they are on task and on time. At or near the deadline, hopefully, they release the Cool Phone Version 0.9. Yea - Beta!
Now they start to work on the next sprint backlog that adds all those cool features which will make potential customers want one of these phones. Our heroic team works through the sprint backlog to complete the list of features by the determined deadline, and now they reveal the Cool Phone Version 1.0. Woohoo! We are taking this thing to market!
Once available to the public, the customer buys the Cool Phone Version 1.0 because they must own one now! They turn on the Cool Phone and start using it. All is well until they find an issue with how the phone auto dials random people when they put it into their pockets. So the customer logs onto the manufacturer’s website (or uses the Report a Bug function on the phone) and reports a bug about how this phone is misbehaving.
The project team adds this new Issue (bug) to the project backlog and they rate it as important. During the next Sprint Planning, the team decides it would be good for the end user (and the manufacturer’s reputation) to make sure this issue (Bug) gets fixed soon, so they put it into the upcoming sprint backlog.
The whole Agile Project Lifecycle repeats as the team goes to work on the newly planned sprint. When the new sprint is completed, the latest version of the Cool Phone Version 1.1 is released. The customer gets a message on their phone saying, “There is an update to your phone. It will add these cool features and it will fix these bugs. Please tap here to update now.” The customer taps to receive the update, the new version is installed, the phone reboots, and the phone no longer experiences problems with pocket dialing. As time goes on, more updates are built and released in the same manner.
This, then, is Agile in a nutshell.
The great thing about Agile is that since its conception, it has found new ways to help people develop and release not just software, but the actual products themselves, the services around those products, and even business strategy.
In the next article I will explain how Agile supercharges service delivery, and we’ll look at some of the key concepts and components that make it all work.
Manuel Palachuk is the author of the book Getting To The Next Level: A Blueprint For Taking You And Your Business To The Top, and he is working on his next book, Agile Service Delivery – The Ultimate Secret To Making Work Flow. He has over 30 years of business, management, and training experience in the computer and electronics industries. He has owned several successful businesses, managed several successful IT and MSP service companies, and coached or mentored many more around the world. Manuel is a thought leader on Agile as applied to Business Strategy and as applied to Service Delivery processes. Manuel is a well-known author, speaker, and trainer on these subjects at industry conferences and in the IT consulting community for Small and Medium-sized Businesses. He holds degrees in Electrical Engineering Technology and Automated Manufacturing Technology.