Detecting Agile Bullshit

The Defense Innovation Board DIB advises the secretary of defense of the United States of America.

Members of the board are recognizable names like Eric Schmidt of Alphabet, or Instagram COO Marne Levine.

So I was quite surprised that a government committee was so straightforward to publish a document called Detecting Agile Bullshit.

Simple questions are used as a bullshit detector to identify organizations faking agile. Worth your time, if the government has this problem, you probably will also encounter it in the private sector.

Tips to Identify Fake Agile Organizations

Many attempts at achieving business agility are misguided and fake. But I consider the glass half full, not half empty. Fake Agile is a signal to do better.  Fake agile is a treatable disorder.  - Jurgen Appelo

Agile development has become such a holy grail that some organizations or project teams wave the agile flag whether they are true believers or not. They throw around talk of sprints, stories and Scrum without meaning it. Signs of this behavior are

• Ignoring users
• Nobody on the software development team is talking with and observing the users of the software in action; we mean the actual users of the actual code,
• Continuous feedback from users to the development team (bug reports, users assessments) is not available. Talking once at the beginning of a program to verify requirements doesn’t count!,
• Not deploying early an initial product release
• Meeting requirements is treated as more important than getting something useful into the field as quickly as possible,
• Development teams are silos instead of feature teams
• Participants act like ‘it’s not my job’,
• Technical Excellence
• DevOps or DevSecOps culture is lacking if manual processes are tolerated when such processes can and should be automated (e.g. automated testing, continuous integration, continuous delivery),
• Distributed version control management systems - Git - are not used,
• Continuous integration and delivery - Jenkins - are not used,
• Modern deployment platforms - Docker, Kubernetes - are not used.

Questions to Ask Programming Teams

• How do you test your code?
  Wrong answers: “we have a testing organization” responsible for testing”
• What tool suite are you using for unit tests, regression testing, functional tests, security scans, and deployment certification?
• How automated are your development, testing, security, and deployment pipelines?
• What tool suite are you using for continuous integration CI, continuous deployment CD, regression testing, program documentation; is your infrastructure defined by code?
• Who are your users and how are you interacting with them?
• What mechanisms are you using to get direct feedback from your users? What tool suite are you using for issue reporting and tracking? How do you allocate issues to programming teams? How to you inform users that their issues are being addressed and/or have been resolved?
• What is your (current and future) cycle time for releases to your users?
• What software platforms to you support? Are you using containers? What configuration management tools do you use?

For a team working on agile, the answer to all of these questions should  be a form of  “yes”.

Questions for Program Management

• How many programmers are part of the organizations that owns the budget and milestones for the program?
  Wrong answers: “we don’t know,” “zero,” “it depends on how you define a programmer”,
• What are your management metrics for development and operations; how are they used to inform priorities, detect problems; how often are they accessed and used by leadership?
• What have you learned in your past three sprint cycles and what did you do about it?
  Wrong answers: “what’s a sprint cycle?,” “we are waiting to get approval from management”,
• Who are the users that you deliver value to each sprint cycle? Can we talk to them?
  Wrong answers: “we don’t directly deploy our code to users”.

For a team working on agile, the answer to all of these questions should  be a form of  “yes.”

Questions for Customers and Users

• How do you communicate with the developers? Did they observe your relevant teams working and ask questions that indicated a deep understanding of your needs? When is the last time they sat with you and talked about features you would like to see implemented?
• How do you send in suggestions for new features or report issues or bugs in the code? What type of feedback do you get to your requests/reports? Are you ever asked to try prototypes of new software features and observed using them?
• What is the time it takes for a requested feature to show up in the application?

For a team working on agile, the answer to all of these questions should  be a form of  “yes”.

Questions for Program Leadership

• Are teams delivering working software to at least some subset of real users every iteration and gathering feedback?
• Is there a product charter that lays out the mission and strategic goals? Do all members of the team understand both, and are they able to see how their work contributes to both?
• Is feedback from users turned into concrete work items for sprint teams on timelines shorter than one month?
• Are teams empowered to change the requirements based on user feedback?
• Are teams empowered to change their process based on what they learn?
• Is the full ecosystem of your project agile?
  Agile programming teams followed by linear, bureaucratic deployment is a failure.

For a team truly working agile, the answer to all of these questions should  be a form of  “yes”.

Conclusion

The above questions are taken directly from the document Detecting Agile Bullshit. Evaluate organization to find out if they or you are agile.

Read also my related set of blogs How Healthy is Your Product? starting with Source Code Check  or Delivery Pipeline Check for an in-depth check of your agile framework, values and current work processes.

Now that government procurement acknowledges that some companies are just cheating with their agile claims, improve yours before getting caught. Luckily the check will find out your are really being agile instead of pretending.

I wish good luck and success with your agile transformation.