Agile anti-patterns list grows stronger

Agile has gone mainstream. Companies do it, governments do it, consultants,contractors. Everybody does it. Right? Maybe not. The metaphor that comes to mind is a group of young men discussing sex. It’s cool, new and everybody wants in. The majority say they are doing but the sad fact is that most of them are lying and those that are actually doing it, are doing it wrong.
After seen Agile done well, and badly I started to become aware of “smells”. These smells are signs that despite of an Agile veneer, it’s not agile at all. A side point is that the word Agile has lost its meaning. It became this silver-bullet-buzzwordy thing and now it’s close to worthless. See, the point is not Agile, the point is to get better at developing software. Hopefully these smells will give you ideas on how to get better at what you and your team do.

Smells no. 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15 and 16

Smell no. 17 - It's iteration 3 and everything is going according to plan

In my experience teams don’t actually do that well in the first two or three iterations. It takes a little while to gel together and move stories smoothly across the wall. When I first played a Project/Iteration Manager role I freaked out when Iteration 1 ended and it yielded zero points. Yep, zip, nada. I even thought about cancelling the scheduled showcase because the team had delivered nothing. I carried through though, we had the showcase and clearly stated that despite our best efforts no points were delivered. I desperately attempted to demonstrate progress by enlisting every technical accomplishment to try and convince stakeholders that several stories were virtually done and we had missed them by "this much". Still that zero points was a nagging pebble in my shoe. Iteration 2 got slightly better and the third one almost hit the expected points. On I4 the point floodgates  opened and the subsequent one normalised and points plateaued as expected.

Over the years I saw this pattern repeat itself a few times. In fact, I haven’t many teams, starting from scratch, create and maintain a steady velocity since offset. This may not a particularly strong smell but it’s a scent :P and I learned to get suspicious when I seeing top to bottom straight lines on a burn-up chart.

Smell no. 18 - No retrospectives

Teams don’t necessarily have to have every single ritual described in the textbook - (Is there an Agile textbook anyways?) as discussed in Too many, too long meeting, but there’s one I never forfeit. A team's responsiveness relates to its ability to deal with constraints, limit work in progress and reduce waste by maximising the amount of things you don't do. To succeed at these three points a team must improve continuously through collective agreements on what they are doing well and should perpetuate and what they are poorly and need to be stopped/changed. And that folks is a Retrospective.

Retrospective is a simple, 30 minute get-together, potentially beer driven, that creates forum where all are heard and problems are effectively discussed, prioritised and selected for action.

A few pieces of advice on Retrospectives:

• Keep it short, sweet and delivered in various formats
• Make sure to value everyone’s opinions equally
• Assume that people try their best. They do not wake up saying to themselves: “Today I will do shit work.” If outcomes weren't great this time around it is not pure evilness and Retrospectives are not inquisitions nor root cause analysis sessions
• Pick only one or two items to act on and make them cards on the wall, alongside with all of  the other stories in the backlog. 
• Don't generate a huge list of retrospective items, a.k.a unplanned work, because it will never get done. When this happens the team eventually looses faith in the ritual and retros become mere bitching sessions
• Dot voting is not only a great way to make it “democratic” but it also forces all participants to read and understand the topics raised by others

Retrospectives are a fantastic form of feedback. Feel free to ditch every other ritual except this one. If your team doesn’t do it, start now. Do it weekly to start off with – there’s probably a lot of stuff accumulated steam and few session will be required for people to vent it all. Once a calmer mood sets in, run a Retrospective session every iteration. Not having retros is smell. It's a smell that your team isn’t improving and has no mechanism to do so.

Smell no. 19 - Now-and-then Manually-sudo-Automated Test Suite

Test Driven Development - TDD is hard, only developers that made a genuine effort to write tests before code know what I'm talking about. TDD is a massive mind-shift because it forces proof before logic and understanding before hacking. But I digress. My point is that unit tests are scarce and often compensated by a suite of functional tests written in isolation by testers. In large corporations these tests are generated by the thousands using some ludicrous "smart" recording testing tools like QTP or Rational Functional Tester. The suite is then manually executed as little as once per release, which in some places means two or three time a year! Furthermore, execution is in complete isolation from a build process or continuous integration server, completely destroying the ability to provide developers with meaningful and timely feedback. The cherry on top is, as time goes by and no one has the time to maintain the scripts, they grow stale and start to fail. Making test run reports interpretation a a graphics designer exercise - it's all slightly different shades of red.

Let's face it, if that's what your project have then you have no automation. You also probably have no tests and most likely have a big distraction to take care of.