Detecting Agile Bullshit

Tags:
2019 01 01 head

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, who was CEO of Google and 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 [1].

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

Learn from yesterday, live for today, hope for tomorrow. The important thing is not to stop questioning.

— Albert Einstein

Identifying Fake Agile Organizations

Agile development has become such a holy grail that some organizations or product teams wave the agile flag whether they are true believers or not.

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

They throw around talk of sprints, stories, and Scrum without meaning it. Signs of this behavior are

Ignoring users

  • Nobody in 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 such as bug reports or user assessments is not available. Talking once at the beginning of a program to verify requirements does not 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 is not my job

  • Technical Excellence

    • DevOps or DevSecOps culture is lacking if manual processes are tolerated. Such processes can and should be automated using 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 answer: “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 do 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 do 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 own the budget and milestones for the program?
    Wrong answers: “we do not 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 is 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 do not 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 product agile? Agile programming teams followed by linear, bureaucratic deployment are a failure.

For a team to truly work the agile way, the answer to 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.

2019 01 01 agile bullshit

Read my related set of blogs How Healthy is Your Product?

Additional blogs for an in-depth check of your agile framework, values, and current work processes are:

  1. Code Scene As a Crime Scene

  2. Delivery Pipeline Check

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

I wish good luck and success with your agile transformation.

Links