The very first project I worked on in IT was “Agile”. As a new-to-IT project manager (my background was in Business Strategy and Operations) I wasn’t quite sure what this meant so I poked around, did a little research and came to the (very wrong) conclusion that it was no different than what I was doing today… Except now everything the team was working on would be on a board and we would only have to a have a 15 minute meeting everyday to discuss it. Bless my heart.
For many reasons, the project was NOT Agile. The team worked an insane amount of overtime with requirements and NFRs changing at a break-neck pace. Two weeks before launch everything was ready. It was defect free (as far as we knew), environments were working (as far as we knew), the performance testing was successful (as far as we knew) and we were only waiting for “Go Live”. About a week or so before launch the Business Customer walked into the room, congratulated the team on a job well done (10 months) and let us know we would not be launching into production. Why? The financial collapse happened and the products that would be offered would not be available to customers any longer. The company could not take the risk.
This is one story I use to demonstrate the risk reducing benefits of Agile. Had the team been running Agile, truly Agile, we would not launch EVERYTHING into production on one day. We also wouldn’t have wasted – yes wasted – money for new Infrastructure, resources and consulting. We would not, at the end of the project, only have a “good job” to show for all the team had accomplished.
- Small, incremental releases would have told us environments were working as expected and minimized the risk of identifying problems too late
- The developers, who had very different styles and approaches, would have HAD to align on working agreements and standards to ensure smaller releases would be successful and easier to maintain and build on. I shudder to think of how challenging the application would have been to manage…
- The business could have tested whether or not they could drive customers to the application, if it was useful to the customers, WHAT the customers really wanted and make informed decisions regarding their investment and their strategy.
- The team could have worked in a thoughtful, sustainable way rather than the reactive death march way they were forced to operate in making for a happier team and, ultimately, a more productive team.
- The application may have not been kept alive following the collapse but, the learning would have been there. There would have been SOME value to the business and the customers generated.
Really, the list can go on and on. Working in an Agile environment is less risky. The business strategy is focused on delivering value. If something isn’t valuable to the end-user, you know it quickly – not after months or sometimes years. This means the business isn’t wasting money and resources on non-value add efforts. The team is able to respond to quickly to change. If direction shifts following a sprint, the overall impact is limited to one sprints worth of effort. Think about it. When there’s a scope change 10 months into a 12 month project in waterfall, the ripple effects can be tremendous. That’s no good for anyone. Your architects and support can work ahead just in time rather than having to anticipate every need for the next couple years saving money and effort. Who wants to build something that may or may not be needed? When you release something into production that does cause a problem you’re not searching through a massive code base that took months/years to develop. You can focus on two weeks worth, identify the problem quickly and limit the impact to your customers and the platform. When you make small changes and something is really awesome you can build on that to maximize the value rather than focusing on other things that may not. An organization can respond to necessary changes that will help to reduce call center volume which has exploded since some marketing or servicing change was introduced reducing the risk of attrition for both customers and the poor call center employees.
There’s another meaningful way in which Agile reduces risk. People. Employees are working on things which they know and believe to be value add to the company and their customers. They’re empowered. They have business context. They have support to resolve issues quickly. They’re happy. This means they will stick around! You don’t have a staff of knowledgeable, hard-working and willing resources walking out the door b/c they’re micro-managed, overworked or putting an effort against something that may or may not, at the end of the day, make a difference.
Agile principles have people at their core. When you focus on people, great things can happen. When you focus only on the work….
You complete that sentence. Thanks for reading!