The Agile Smells go on

Agile has gone mainstream. Companies do it, governments do it, consultants, and 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 and 7

Smell no. 8 - Special purpose teams

It’s not uncommon for companies or government departments to have to deal with changes that are imposed on them. Regulation changes or another unstoppable forces such as Micro$oft releasing a new version or their Operating System force compliance changes. Dedicated teams whose backlog is nothing but compliance changes is a smell. Giving some poor souls the ungodly task to keep up with mandatory changes is the easy way out and smells. It smells of “out of sight out of mind”. 

But it comes back to bite you in the behind. When it’s the same codebase there are merges to be dealt with, tests to be updated and potential impacts on the new “important” features. See, it’s code, just like your bank account doesn't care whether you spent money at the pub or the supermarket, the system doesn't care whether it’s compliance or new-feature work. A better alternative is to turn compliance changes into regular stories and have one team handle of all the work as they normally would. This way the effort is visible, prioritised by the business and built like everything else.

Smell no. 9 - Pilot Champions to change the company

In order to adopt Agile a few strategies tend to take place. A common one is to create a pilot project to try and see whether Agile works. A team comprised of the best and brightest is assembled. These fortunate individuals are encumbered with the delivery task and, upon success, “spread” their learnings or “champion” the change across the organisation. This rarely works. Not because the pilot team isn't good, they often are and they often succeed in delivering the project. The problem starts when they return to their original places. It’s quite hard for an individual alone to change the culture of an entire group. 

Another approach is to allow the new Agile team to go through the form-storm-norm-perform cycle and instead of disbanding it in the end, keep it running. Then progressively rotate a few inexperienced people through it. This way the team doesn't lose momentum and, overall, it’s much easier for an entire performing team to influence a few individuals. In conclusion, pay attention to how your organisation is approaching adopting Agile, if it involves making a few individuals into “Agile heroes”, that’s a smell.

Smell no. 10 - Big upfront [UX design/architecture/performance]

Several things can go wrong when developing software. The long list of problems range from usability issues, infrastructure, poor performance, integration, etc., etc. The number of things that can go wrong vastly surpass a team’s capacity to solve them. From a systems theory perspective software development is complex. Complicated too, but complex in a sense that there are too many variables at play and the prediction of an outcome is impossible. Despite the clear disadvantage many still believe that if they put enough effort before starting they will be able to cater for all scenarios, all questions and prevent certain doom. Yeah, that never works.

I’m not suggesting to ignore risks, or not to invest in solutions for known issues. But spending time and effort trying to answer questions that will never be asked is just waste. All companies want millions of users, but there is only a handful of Twitters, Facebooks and Googles. It’s a smell doing upfront work to solve problems that are mere reflections of wishful growth projections. Creating pixel perfect designs before development without ever putting it in front of an end user, developing the “perfect” multi-layer, multi-queue, architecture that can’t be deployed into production in parts or investing heavily to preemptively solve “web scale” problems are smells. The rule of thumb is do the bare minimum, nothing else, learn from it and improve as you go.

Smells no. 11, 12, 13, 14, 15, 16, 17, 18 and 19