Agile is not a game!

I recently spent a few hours playing with Google’s cardboard virtual reality glasses.  It was a lot of fun touring alien worlds and the deep seas. It was fun, but it wasn’t real.  In a moment of reflection, I came to realize that many organizations are practicing virtual Agility rather than real Agility.  Over the next four entries of the Software Process and Measurement blog, we will count down twenty of the most nefarious indicators that should clue you into the realization that you are practicing virtual Agility rather than real Agility. Unless you are playing a game, virtual Agility does not deliver real value!

20. Agilefall –  If you are doing waterfall and calling it Agile, virtual might be a kind word to use for the world you are living in.  Examples of hidden waterfall abound; for example, a colleague described an organization that was breaking work into analysis, design, coding, testing, and implementation tasks each in different iterations, but doing stand-up meetings and demos (lots of Powerpoint) so they could call it Agile.  Doing waterfall and calling it Agile misses the point.

19. Testing Apartheid – Treating testing as a follow-on to other activities is a close cousin of doing waterfall and calling it Agile.  I recently talked with an organization that had a development team (mostly coders) and a testing group (all testers).  Each used Scrum and in their minds, each was a separate but equal Agile team. Testing is an integral part of developing code or anything else and is a key feedback tool.  You aren’t done until you have tested!

18. S/He Told Me To Do It – Doing anything (at least in knowledge work) just because the book or consultant told you to do it tends to be virtual Agility. Software or product development purely by checklist assumes that your current context is same as everyone else’s context.  Every Agile practitioner should understand theory and goals so they can tailor the process to meet your needs.  Virtual reality allows you to practice in a pristine environment with a fixed context based on whoever designed the scenario — the real world is much less consistent.

17User “Taskies” – User stories are a tool that links something someone wants to a benefit (persona, goal benefit). Writing tasks masquerading as user stories jumps over the whole business need thing and get immediately to define a solution or building…something. Many teams assume that shortcutting the process is efficient.  Without business context, the team might as well be taking orders at a fast food restaurant. Defining tasks before establishing the business context puts the cart before the horse (said backward: Horse the before cart the putting as same the exactly this).  IT DOES NOT MAKE SENSE.

16. Leader Dependent Organization – Agile is built on a philosophy of motivated individuals forming teams that self-organize and self-manage.  Team members pull work, support each other, and meet commitments.  Managers passing out the work while trying to maintain an effective 100% utilization rate is counterproductive building a self-organizations team, lowers motivation, and can act as a bottleneck.  Typically self-managed teams have lower turnover, higher productivity, and throughput than equivalent manager lead Agile teams

When I originally, began contemplating this theme I thought that I would be able to be somewhat tongue-in-cheek when describing the incidents and observations that drove these 20 (ish) non-Agile scenarios.  The problem is that all scenarios that tell you that you are living a virtual world, however innocuous, are the outcome of some misinterpretation or organizational dysfunction. They should not be made light of.

15 –11 Next!