How to adopt a frAGILE work environment

Much dry erase ink has been spilled on the merits of using Agile methodology in software development, and techniques for how to incorporate it well into the incumbent mindset. I have weighed it, I have measured it and I have found it to be awesome. Someday, I’d like to try it. It is claimed that Gandhi once said, “I’d become a Christian if I’d ever met a real one.” That is seems about right. Agile is a great mindset, project management methodology and work philosophy. It is so good, I wonder if it has ever been tried. 

When I went to SCRUM training (an Agile “sect”) the instructor said most organizations are “SCRUM-but”–that is “we do SCRUM, but, we change X“. If you really want to get the worst of waterfall and Agile try this variant of SCRUM-but: “frAGILE”. This stands for “false reality” Agile. True frAGILE:

1. Promise the impossible: Fix the timeline, and fix the allocated resources while constantly adding to scope
2. Promote ignorance: Hide from the client the effort involved in creating a feature. That way more work can be added with no insight into the impact to the timeline
3. Punish the messenger: Though the team did not set the scope, nor can they create more folks to help out ex nihilo, find ways to make them feel guilty when timelines necessarily change due to increased workload
4. Practice politics: Inserts middlemen, proxies, end-run maneuvers wherever possible to add confusion and resentment to the process
5. Provide the minimum resources: Use no dedicated resources and prevent formation of a solid team dynamic or discernible velocity (until the 11th hour, then triple the team, because throwing money and bodies at problems always works!)
6. Pass over due diligence: Perform no feasibility before beginning work. (This is Agile–we can patch holes with unicorn powder and fairy blood, afterall!)
7. Put up walls between team members: Sequester the developers from the end users so that weeks go by in between requests for features and evaluation of work performed
8. Put all work in one bucket: Considers all features equally important and all “must have”. Do this with new features, too (see point #1)
9. Prevent a sense of accomplishment: Vacillate between feature-driven release and time-driven release without warning and watch the team start to sizzle and pop through your magnifying glass
10. Pass the buck: Uses “retros” and off-the-record conversations to undermine team members self confidence. Selectively remember who made decisions and avoid owning mistakes whenever possible
11. Preach ownership, practice fiefdoms: Have as many permutations of “boss” as possible so that no decision is final and blame allocation is easier down the road (you have to think ahead!)

When combined, these 11 modifications to the Agile Manifesto will ensure an exciting first half of a project and an excruciating second, and third, and fourth, half of the project…for those that stick around that long.