From the @DeptofDefense comes this great
document on detecting #agile bullshit:
https://media.defense.gov/2018/Oct/09/2002049591/-1/-1/0/DIB_DETECTING_AGILE_BS_2018.10.05.PDF
"... how to detect software projects that are really using agile development
versus those that are simply waterfall or spiral development in agile clothing".
Some takeaways:
8 replies
"Key flags that a project is not really agile:
- 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.
(The [Product Owner] does not count as an actual user."
"- 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!"
"- Meeting requirements is treated as more important than getting something
useful into the field as quickly as possible."
"- 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)."
It also provides a set of questions to ask development teams and management: "-
Who are your users and how are you interacting with them?
- What is your (current and future) cycle time for releases to your users?"
"- 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?
- Who are the users that you deliver value to each sprint cycle? Can we talk to
them?"
"- Is feedback from users turned into concrete work items for sprint teams on
timelines shorter than one month?"
It even has a nice flowchart on how to detect #agile bullshit: