Agile Project Management and Incorporating Changes

September 27
blog author


Senior Business Analyst

Last week, I attended an IIBA event titled “Through the Looking Glass: Agile Product Management & Planning Methods” by Dave Sharrock. IIBA is the International Institute of Business Analysts, and the talk was centered around the challenges of managing long term product portfolios under the Agile methodology; or how to reconcile the concept of long term planning and budgeting with the Agile focus on small, well-defined work requests consisting of just enough requirement definitions at just the right time. The presenter was Dave Sharrock, an agile coach and one of only five Certified Scrum Coaches in Canada; he pulled off quite an engaging and interesting presentation, which I found highly resonated with some of the challenges we currently face at Appnovation in using the Agile methodology to manage big Drupal projects. Historically, the high cost of change in software development has led to inclusive thinking. Any idea needs to be captured in the first version of requirement specification and that leads to creating waste: bloated documents, unwanted features, and entitlement thinking. Agile helps to move from hypothesized requirement to validated requirements by allowing for prioritization and descoping to happen at all levels and at any time. Agile focuses in on short iterations of delivering functionality in increments, based on the core Agile principles or manifestos, such as working software over comprehensive documentation and responding to change over following a plan. The challenge for us however, as an IT services company focusing on delivering open source solutions, is that in platforms such as Drupal (which is one of our main development platforms), changes could potentially become increasingly expensive as we go further down the development path. For example, while it is easy to add content types to a Drupal project at any stage, if we need to add a new content type later in the development cycle and if the business logic for the new content type is not considered in the current work flows, chances are that we might have to start from scratch to build new business logic to include the new content type, thus incorporating way higher cost compared to having considered the content type from the beginning. Occasionally at Appnovation, we have had to deal with client requests to incorporate such “small” changes in a second or third project Sprint, and we’ve realized that over the course of trying to respond to clients need for change while keeping the project under budget, sometimes we are drifting away from Agile and tilting towards waterfall (ending up with something similar to Water-Scrum-fall), just to be able to bring some reliability to the development process. We posed the question of how to best address this challenge to Dave, and this is what he suggested:

* Try to avoid unnecessary change as much as possible: Line up your Business Analysts and Information Architects early on in the process, so that you can carefully plan for capturing requirements right in the early stages of the project and reduce changes that are a result of not properly understanding clients needs in the first place.

* Decode the impact for cost of change: Have a conversation with your clients and educate them on the concept of expensive change vs. affordable change. For example, help the client understand that a decision on the architecture has to be made by a certain date, after which changes will be too expensive While this will keep us from falling into the trap of constant change and the cost associated with that, it is still aligned with the Agile best practice of leaving decisions to as late as possible, but not later!