Can Agile Software Development Seem Unresponsive?

Agile Software Development is a hot topic, few software team leaders or CIOs would not either claim to be using AGILE methods already, or heading in that direction.  In some future post I want to talk about the prevalence of people relabeling what they do as agile and declaring victory and also share some of my lessons learned about why it may not always make sense to use an Agile method, like SCRUM.  But for this post I want to talk about a different problem.  What if the migration to a formal, disciplined Agile method like SCRUM actually seems less responsive to the customers?

The client case was a small software team that had built a comprehensive learning management platform incrementally over a number of years.  The team had no formal engineering method, process or life-cycle.  The small group of experienced developers were highly customer driven, rapidly making fixes, changes and enhancements on an unplanned and unscheduled basis.  While they had no measures it was clear to all that a large percentage of the work they did was fixing problem introduced by previous work.  The errors and hiccups not withstanding management of the company perceived that they had a responsive and flexible software team.

Then based upon some outside business events they had to both increase their capacity and throughput and become much more disciplined to meet deadlines and commitments to some major changes and enhancements.  It was clear that their error prone, silo’d organization was not going to be able to tackle the challenges of designing and implementing major changes to both the function and technology of their software, so we decided to create a more disciplined Agile approach with the use of the SCRUM method.  We implemented a two week spring process, and then moved to a bi-weekly release process scope items would take a month to go from the product backlog to a release (at a minimum) and fixes (barring hot fixes) would take two weeks.  (We applied the agile approach to the current system as well as the new system being developed.)

The challenge was how to resist the temptation to break the process and make “one important change” right away since the development team seemed less responsive than in the past.  The users and stakeholders had not seen the benefits of the new system being developed since it had not reached minimum viable product status to enable conversion.

We took three steps to help make the new disciplined SCRUM approach more acceptable:

  • Focus on improving uptime reliability of the system, and we measured and report progress. While not related to the Agile approach it demonstrated tangible improvement.
  • Focus on communicated the status and progress of tickets, showing how the backlog decreased. Again, while it may not have satisfied the user who wanted his or her change made immediately it showed that in general fixes and enhancements were being handled.

Finally, we violated the SCRUM method a little by allowing scope to change during the sprint.  IF a new ticket came into the backlog that was more important than one being worked on we would re-prioritize work in the sprint, staying within the same resource allocation – essentially a one for one swap.