I know it is Christmas time not Halloween, but think of it as holiday re-gifting. Here is an article on agile horrors I wrote for ProjectManagement.com Halloween Edition that we should be on the lookout for on our projects in 2014.

Frankenstein Process – This is the methodology designed by committee that tries to combine iterative, empowered development with linear scheduling and command-and-control task assignment. Perhaps created in an attempt to satisfy the desires of competing groups, but this half goose, half salmon abomination neither flies nor swims.

Agile practices are in a balanced network. Ruthless testing balances the need for comprehensive documentation; colocation, demos and daily stand ups reduce the need for detailed status reporting. Changes made to this web of practices can easily create risks, gaps and duplications if they are not carefully considered.

Think candy apples not pumpkin pie; hybrid methods work best when there is a core of agile for the team to own and execute, surrounded by a wrapper of more traditional process to buffer and integrate into a less agile aware environment. Don’t try and glom disparate process pieces together, it becomes a monster nobody loves or defends.

Zombie Projects – some projects should just die but won’t seem to. Doomed from the outset with unrealistic deadlines, overly ambitious scope, or ill equipped skills and support; everybody knows it will not end well, but nobody seems willing or able to kill it.

These death marches to eventual failure or cancelation are damaging to the people working on them who see the futility and mismatch of progress to targets. However, like the emperor’s new clothes there is a shared acceptance that this is unlikely to work, but nobody seems to speak out. Perhaps thinking that the “higher ups” must know what they are doing and would intervene if there are problems; they continue shuffling forward like an army of undead looking for brains.

Unfortunately, there are no brains here and the higher-ups rarely have some cunning plan that turns struggling forward progress into an elegant solution. More often if it looks, smells, and behaves like an undead zombie, it is one. Just like in the movies, it is best not to start shouting and bring attention to yourself if you are surrounded by zombies. Instead try to find an opportunity to exit quietly, see if there is a reset or restart initiative planned. Offer to be part of the solution, instead of bitching about the issues, usually others have reached the same conclusion and are looking for support to fix things.    

Vampire Scrum Masters and Project Managers – These people just suck the life out of things and never give back. Scrum Masters who look for process compliance but do not own or remove impediments; or project managers who push for velocity improvements, but don’t want to hear about quality improvements or refactoring plans.

Agile teams generally work very hard to deliver as many high quality features as they can. When they report problems or ask permission to undertake maintenance work it is so they can be better equipped to deliver high quality features long into the future. Like ignoring a Check-Engine light in your car or missing regular maintenance, you might save some money in the short term but it is a false economy longer term.

Scrum Masters and project managers need to learn enough about their teams and their technical domain to distinguish genuine reports of problems and requests for investment from everyday complaints and unnecessary requests for resume boosting technology upgrades.

Teams who routinely get their requests ignored by leads that just want results without investment will correctly draw the conclusion that they are not valued. When this occurs, the motivation to try hard, delight customers and go the extra mile to overcome an obstacle is removed. The delivery of results will decline and then the whole process sucks.

So, show some interest, ask people to explain why issues and requests are important. If all the solutions are not possible ask them to prioritize. Try as hard as you can to fulfill these requests and usually the teams will reciprocate with improved effort and results.

Product Owner Ghosts – these are business representatives that are kind of there, but not really, they tend to vanish or dissolve when pressed on anything. Whether it is a tough decision on a product feature, or their attendance at a demo; product owner ghosts are unreliable.

The product owner / business representative role is integral to agile processes. They are needed to ensure requirements are understood, refined and prioritized, along with providing prototype feedback and resolving design decisions. Like missing or getting a poor developer or QA person, a project with a “hardly there” product owner will suffer tremendously.

So, look out for signs of less than real product ownership. Warning signs of a non-committed or weak business involvement include:

C - Contrary – decisions flip-flop with no clear explanation

A - Absent – you cannot find them or get their time when needed

S - Switching – the person changes, no dedicated product owner is assigned

P - Passive – without prompting we would not hear from them for long periods

E - Elusive – they will not provide clear feedback on the suitability of a prototype

R - Reclusive – they withdraw from priority discussions and decisions

Instead try to staff projects with product owners who exhibit more solid, proactive business representations.

C – Collaborative – willing to discuss and evaluate alternative solutions

O – Owners – owning the backlog of work, taking reasonability for its grooming

N – Nearby – available when required to ask questions and get clarifications

C – Committed – having the same person or people throughout the project

R – Representative – representing the group we are building for, not personal goals

E – Expert – knowledgeable about the domain at hand to answer team questions

T – Traceable – contactable when needed or with a proxy available if away

E – Experienced – experienced in the field to warn of outliers and exceptions

(I prefer these attributes over Barry Boehm's CRACK mnemonic that does not emphasize the Nearby, Experienced and Expert qualities that can really save teams time.)

Getting the best users is always difficult since the best people are busy doing real work. Try to explain the costs and risks of building the wrong or a sub-optimal solution. Offer to back fill admin work from the project for the best people even just to free up some of their time each week for input and feedback.

Summary

Hopefully this light hearted view of some agile anti-patterns in the guise of Halloween ghouls reminds us of things to be on the lookout for. Unlike Halloween these problems are year round threats. More than just something that goes bump in the night, these problems are ever present in our lights-on projects. Look out for them and use your garlic and silver bullet awareness to keep them from impacting your projects.