#agile #throughput #outcome #process

Idea

Agile is a set of values and principles. They proclaim that a better way to deliver software, seeking customer satisfaction, is to

• foster interactions, favor an organic way of working^[1].
• have working software as soon as possible^[3] and at all times,
• have proximity of engineers and customers, and
• iterate quickly^[2] and adapt to change, both in what we build and how we work.

Links

[1]: self-organizing-teams is a way to organize a team to facilitate it being agile.

[3]: Keep options opened is a way to handle backlog for agility

• Delegation framework is how you control a team while allowing it to be agile
• Agile is aiming at addressing the particularities of the economic equation of software engineering
• Agile is a way of applying natural selection to features and products
• To keep things agile keep batches small
• Agile is somewhat the scientific method applied to process, in that it's reinforcing and reducing the length of the direct feedback required to go from formulating an hypothesis to validating it, therefore making sure the outcome is effectively the "theory" of the product rather than just an hypothesis.

References

[2]: The agile manifesto^ref and its principles^ref The manifesto

• DoD, Detecting agile BS^ref\

  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.1 (The Program Executive Office (PEO) does not count as an actual user, nor does the commanding officer, unless she uses the 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!
  • Meeting requirements is treated as more important than getting something useful into the field as quickly as possible.
  • Stakeholders (development, test, ops, security, contracting, contractors, end-users, etc.)2 are acting more-or-less autonomously (e.g. ‘it’s not my job.’)
  • End users of the software are missing-in-action throughout development; at a minimum they should be present during Release Planning and User Acceptance Testing.
  • 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).