Mistakes in Agile

I'm not sure if this will be a series or a one off rant I just keep adding to for the rest of my life; regardless, here is something I'm experiencing right now in the fragile team I'm working in.
January 21 2016

I'm not sure if this will be a series or a one off rant I just keep adding to for the rest of my life; regardless, here is something I'm experiencing right now in the fragile team I'm working in.What the company has done is send all team members off to do an agile course and then decided to "do agile".  That easy? In practice they have taken a waterfall approach and applied the SCRUM ceremonies and iterative model (sprints) to it.  The language sounds good.  People are talking about estimation and planning and are doing retro's and fortnightly demo's.  There's even a build server and some (not many) automated tests, both UI and unit.

The problem is there's no quick deployment.  No feedback to see what works and what doesn't.  The scope is known and fixed and the entire scope must be delivered in one big bang.  But before delivery, there is a period of SIT (System Integration Testing) and UAT (User Acceptance Testing).  SIT and UAT is conducted in the same environment, so there's no real testing of deployment processes.  SIT ends on one day and UAT starts the next. Not even an database restore.

Developers are working with back end environments (web services) that frequently break or go down for whatever other reason. This causes devs to drop tools for hours at a time while the services are restored.  Sometimes they break because of defects. Sometimes it's bad code merges. Other times it's SQL clustering failover.  I can forgive the Sql Clustering but there's no execuse for the first two.  Don't release if your tests don't pass.  If you are release code that's broken and all your tests pass... Well, you have a problem.  Back end environments are also knowingly (can't afford software licenses in all of the 10+ environments) not fully representative of the system that will be in prod.  Some services are missing features.  Some knowingly throw timeout exceptions.

What can they do to get things fixed?

  • Automated deployment, or at least deploy at click of a button
  • (Aim to) deploy to prod at the end of each Sprint (this way there is no "oh we'll do it later. It's Done or it's no)
  • Automated test at least the important stuff (Unit Tests or UI tests or both)
  • Include load testing and browser compatiability testing into the sprint (and automated with at least an overnight/sprintly build).
  • Don't release broken builds into even test environments! (this should be covered by previous points on tests)
  • More, of which I'll rant about later.

Post a comment

comments powered by Disqus