At this stage most developers have come across agile development methodology in some form, Scrum etc. In it’s various incarnations it usually follows the same formula:

  • Create a Product Backlog
  • Groom the Product Backlog. put it in priority order and estimate the tasks using whatever process suits
  • Spring Planning. Plan your sprint by choosing what you will complete in a timeframe
  • Sprint! and have daily Scrums to review progress
  • Sprint Demo. Show your you deliverables to the stakeholders
  • Retrospective. Look back and see what worked and what could be improved
  • Repeat!
No surprise there. The theory is solid but the practice I have found is less solid. I was in one company where we made the decision to switch from our bulky Waterfall Software Development Life Cycle (SDLC) quarterly release schedule to a more flexible Agile approach. The approach was gung-ho. An Agile Leadership Team was set up to steer the company in the right direction resulting in more than 100 developers being sent on Agile training over a 6 month period, scores of policy documents being written detailing how to manage releases, sprint processes and structure, backlog structure, even the process of estimation had a policy document. What we were left with was the most inflexible oxymoron of an “Agile” process that you could imagine. Since all teams were in cadence, all had to have the same sprint length, in this case 3 weeks – I personally prefer 2 week sprints. Any retrospective ideas the team had were never implemented as they would break the process documents and so developers were to told to conform to the new model. The biggest issue I had here was with the releases. All sprints were batched up and released every quarter! Yes, we had in effect, a Waterfall SDLC with the nametag switched. The old switch-aroo will get you every time! So now I hope you see I’m not against Agile – quite the opposite I think it’s great when done right. But it is exactly as it says on the box – agile. >If you put Agile into practice and a year later you are still doing the same thing, then you’re not improving your process and you’re doing something wrong! Well how can this be avoided or fixed? The power of Agile lies in the Feedback loop created with the sprint retrospective. This Retrospective can be considered the most important part of the Agile Process. It gives the actual troops on the ground a voice on two equally important issues what they see as working and what they see as not working. And invites suggestions on how to fix the latter. Without this continuous improvement, the fundamentals of agile can’t be built upon to provide a SDLC that solves the problems for your individual company. The lesson to be learned. Don’t fear change – adaptable companies or development teams are more productive when times are good and more capable when times get tough.