From the translator: this is the DIB Guide: Detecting Agile BS instruction (version 0.4) , which the US Department of Defense Innovation Committee (DIB) published in open access on October 9, 2018.

Agile is a buzzword in software development, so all software projects of the Ministry of Defense are now almost by default declared "flexible." This document will help program managers and defense specialists distinguish software projects with a truly flexible methodology from projects that simply use “waterfall” or “spiral” (under the mask of Agile).

Principles, Values ​​and Tools

Agile experts and enthusiasts identify key indicators that characterize this culture and approach to agile development. In its work, DIB has developed its own guidelines, roughly reflecting the true values ​​of Agile:

Agile value	DIB principle
Individuals and interactions are more important than processes and tools.	“Competence is more important than process”
Working software is more important than complete documentation.	"Reduce the time from the start of the project to the deployment of the simplest basic functionality"
Cooperation with the client to negotiate a contract	"Implementing DevSecOps culture for software systems"
Responding to changes is more important than a plan.	“Programs must start small, be iterative and build on success — or they are quickly turned off.”

Key indications that the project is not very flexible:

• None of the development team communicates with users and does not track the software in action; we mean real users of real code. (The program evaluation department is not considered a real user, just like a senior officer, unless he uses the program in his work). Acceptable alternatives to communicating with users: monitoring their work, sending them prototypes for feedback and other research methods that do not involve a lot of verbal communication.
• There is no constant feedback from users for the development team (bug reports, evaluations). It is not enough to talk once at the beginning of the project to check the requirements!
• Compliance is considered more important than obtaining the minimum useful result as quickly as possible.
• Stakeholders (development, testing, DevOps, security, contractors, end users, etc.) operate more or less autonomously (for example, “this is not my business”).
• End users are not involved in the development; as a minimum, they must be present during release planning and acceptance testing.
• Insufficient culture DevSecOps, when manually running processes that can and should be automated (for example, testing, continuous integration, continuous delivery).

Some typical tools for agile development (they change as
appearance of the best):

• Git, ClearCase, or Subversion is a version control system for tracking changes in source code. Git is the de facto standard in modern development.
• BitBucket or GitHub - hosting repositories. It also keeps track of tickets, has "applications" for continuous integration and other tools to improve performance. Widely used by the open source community.
• Jenkins, Circle CI or Travis CI is a continuous integration service for building and testing Bitbucket and GitHub projects.
• Chef, Ansible or Puppet - software for creating configuration recipes and translation configuration tasks or support to a number of servers.
• Docker is a computer program that performs virtualization at the operating system level, also known as “containerization”.
• Kubernetes or Docker Swarm for container orchestration.
• Jira or Pivotal Tracker - tickets, monitoring and management.

Graphic version:

Questions for developers

• How do you test the code? (Incorrect answers: “We have a special organization for testing,” “The testing and evaluation department of the product is responsible for testing.”)
  
  • Enhanced version: which toolbox do you use for unit tests, regression testing, functional tests, security scanning and deployment certification?
• How automated are pipeline development, testing, security and deployment?
  
  • Enhanced version: which toolbox do you use for continuous integration (CI), continuous delivery (CD), regression testing, program documentation; is your infrastructure defined by code?
• Who are your users and how do you interact with them?
  
  • Extended version: what mechanisms do you use to get direct feedback from users? What toolkit do you use for generating bug reports and tracking tickets? How do you distribute work on the elimination of bugs between teams? How do you inform users that their issues are being resolved and / or already resolved?
• What is the duration of the current and future release cycles?
  
  • Extended version: which software platforms do you support? Do you use containers? What are your configuration management tools?

Questions for project managers

• How many programmers are included in the organization that distributes the budget, and what are the main stages of the program? (Wrong answers: "We do not know", "Zero", "It depends on the definition of the programmer")
• What are the management metrics for development and operation; how they are used to communicate priorities, identify problems; How often does the guide look at them and use?
• What have you learned in the last three sprints and how have you applied new knowledge? (Wrong answers: “What is a sprint?”, “We are waiting for the approval of the management”)
• Who are the users who benefit from each sprint cycle? Can I talk to them? (Incorrect answers: “We do not deploy the code directly to users”)

Questions for customers and users

• How do you communicate with developers? Do they monitor your work and ask relevant questions that demonstrate a deep understanding of your needs? When was the last time they sat side by side and discussed the features you want to see?
• How to send suggestions on new features or report problems or bugs in the code? What kind of feedback do you get for your inquiries / reports? Have you ever been asked to try out prototypes of new software features and see how you use them?
• How long does it take to implement the requested function in an application?

Questions for guidance

• Is the working software version delivered at least to a small sample of real users at each iteration (including the first one) and are reviews collected? (hint: every two weeks)
• Is there a statute for a product that sets out the mission and strategic goals? Do all team members understand both? Do they see how their work contributes to the achievement of goals?
• Do user reviews turn into specific tasks for sprint teams with a deadline of less than a month?
• Are teams authorized to change requirements based on user feedback?
• Do teams have the right to change their process based on what they learned during development?
• Is the entire ecosystem of your project flexible? (If a agile development is followed by a linear, bureaucratic implementation procedure, this is a failure.)

For Agile teams, the answer to all these questions should be yes.

Graphic version:



More detailed information on some of the functions of the Defense Ministry programs is contained in Appendix A ( “Ten Software Requirements” ), Appendix B ( “Software Development Metrics” ) and Appendix C (“Software Errors and Rules” [link will be added later] ).