The buzzwords of agile and devops are making companies think about how they are operationally organized as well as how they operate projects throughout the organization. Agile has been around for a while within software development organizations and became successful for software development teams because all teams (QA, backend, frontend, sustaining, etc.). The teams commit to work in their sprint iterations over the year to accomplish or deliver new enhancements, software and technology and can pivot very quick, but also deliver value at a faster rate.
Where does agile methodology fit in for implementation services?
I have been involved in a couple different agile projects from a services delivery standpoint and have found there to be some pros and cons in agile delivery. I think the number one problem that we faced was trying to force all agile principles on the project and completely replace all the waterfall aspects. I quickly learned that it was a struggle and larger effort to tailor packaged work products into stories and tasks that fit in line with agile.
- Sprint reviews and sprint planning
- Early demos to let customer see exactly where at they stand in the project. It also helps facilitate additional requirements or ideas to be implemented.
- Standup meetings
- A quick cadence allows all the implementation team to determine what each person is currently working on for priority and to clear up any impediments
- Big Board planning
- Allows the larger team and stakeholders to get a clear understanding of the goal and purpose of the project. It sets up the project team to understand the expectations of the project, but at the same time what it is going to take for the project to be successful and how it’s going to be accomplished.
- Lack of product ownership
- The product owner is a critical piece to an agile delivered implementation because they are the ones who need to communicate priorities and ensure stories and tasks are approximately aligned with the business needs and expectations.
- Stories vs tasks
- There is a no clear way of determining what a task is and what a story is in an implementation. Project teams are quickly confused with what to place as a story and what is a task. Classic work break down structure is much simpler to work against.
- Non-agile project dependents
- Typically, in many projects, additional SME’s are needed to accomplish the work. If they are in a traditional operational setting, it’s harder for them to commit to work if their team or other projects are not also in an agile. This can cause significant delays to the sprint and push out tasks/stories to future sprints.
I think it’s a work in progress, but it’s clear to me that adopting agile and replacing it, 1 for 1, with waterfall is not a good idea. I think by taking some of the pros I mentioned here and applying them to traditional waterfall methodology we could improve the current delivery methodology.