Agile methodology is particularly advantageous if you are selling an idea or innovation or if you need a proof of concept, a pilot implementation and early wins before you get the approval for the complete project.
Are you used to doing large-scale IT projects that require enormous investment of time and money? Normally, these projects are the ones that aim to deliver a “complete” business application package. IT managers start with the determination of project scope and feasibility, creation of a business case, blue printing, project planning, execution and delivery. Depending on scope and scale, such a project (from start to finish) could take months to complete and require a lot of resources.
How do you manage such large-scale projects? Typically, IT managers resort to the traditional sequential method. In this method, you determine all the business requirements in the beginning, agree to sign off with the business and move on to a lengthy development cycle. This traditional approach is characterized by work wherein each stage occurs in linear order and lasts a longer period. What’s the risk of such a method? At the end of a project, a team might have built the business application package it agreed to build and deploy. However, in the time it took to develop, test, fine-tune and deploy, business realities may have changed so dramatically that the product becomes irrelevant. In this case, the business has invested time and money to create a product that no one wants. Isn’t it possible to ensure that the end product is still relevant before it was actually finished? Isn’t it possible to divide the scale into smaller scope and deliver one product (smaller but value creating) at a time?
With the pressures of a limited budget and demand from internal customers for the immediate delivery of innovative solutions, one approach stands out– Agile Methodology. With Agile Methodology, you have a shorter delivery cycle and focus on delivering a “minimum value product”– the minimum scope that delivers the first set of products, functionality and value. You are not expected to deliver a complete solution with a host of value components. Agile development provides opportunities to assess the direction of an initiative throughout a defined roadmap. This is achieved through a smaller project cycle or iterations, at the end of which teams must present a minimum viable product.
The advantage of the Agile approach is the quicker visibility of results. This is particularly advantageous if you are selling an idea or innovation or if you need a proof of concept, a pilot implementation and early wins before you get the approval for the complete project. Also, you don’t have to request a huge amount of investment up front. You create, deliver and sell one value creation at a time. The challenge is to find the minimum scope that could deliver the first set of value and focus your efforts on delivering this first. Implement, test, evaluate and then move on to the next quick and responsive development cycle.
The industry sector that I work in has been badly hit by financial problems in the past couple of years. Obviously that affected IT funding especially on projects in a huge way, impacting our capabilities to deliver the same innovative outcomes from previous years. But the challenge for IT manager is managing the demand from the business partners who continue to request new IT solutions for their business. A lot of them obviously focuses now on innovation addressing how to win in this tough financial times, like profitability, process efficiency, and differentiation in customer experience.
It used to be easier to sell a huge multi-process, multi-business line and multi-year projects, for as long as you can prove the business value of your initiative– not anymore. What we do is sell an idea in a form a roadmap and focus on delivering the first minimum viable product– that’s when truly embraced agile methodology to project delivery.
Agile Methodology does not only apply to IT projects. It could apply to any other project with a large scope that potentially can be divided into small iterations of delivery. Some examples that I can think of are infrastructure projects and product development.
#Perspectives 
Thanks Kelvin for sharing a software development perspective of Agile methodology. Looks like it’s been an effective approach for your company. If I were your customer, I’d be pleased that my requirements, you depicted as “user stories”, are addressed in such such sweeping fashion.
In our case, we use agile approach but on a scale a bit larger than yours, not in weeks as you mentioned, but months, like say a month / 2 months at a time delivery. But always in those implementation we are working of an application for a specific process. I doubt if Agile will be as effective an approach for enterprise-wise or integration projects. I have not seen or read any cases of such application – but would love to if others have tried.
Agile in my experience is an effective software development methodology.For me, it is the most transparent & responsive methodology I have worked with. I have been in the IT industry for 16 years and I can say its where I have been most productive.
Our development cycle starts with sprint-planning. We typically have 2-week of sprints as we wanted smaller and frequent releases compared to big ones. We break down features into Epics and then each epic will have user stories (operations/actions a system user will do to execute a feature) like “As a user, I can create, edit and delete an advertiser”. This will be of course, broken down into technical tasks, and then we attribute story points as an estimate of the effort to finish a user story. Depending on the size of the team and resources on our disposal, we then as a team, commit the number of story points for our 2-week sprint. And this commitment will be the “goals of the sprint”.
We use Atlassian Jira as our tool to manage all our Epics, Stories and track the progress of our sprint. It offers a chart so that everyone can see the progress of the project. This transparency is very important as it gives everyone an idea if the project is going smoothly. We also do daily scrum stand-ups where each member tells everyone what they did yesterday and what will they do today and more importantly if there are any blockers that may prohibit the team from delivering the goals of the sprint.
At the end of our sprint, we do a retrospective and try to list things out that went well on the previous sprint and what didn’t and we try to carry on the good things and try to learn from what didn’t work. This retrospective helps the team in being more efficient and as a result we get better in estimation and we can deliver more story points the next sprint cycle.