Agile Software Quotes & Sayings

Countering the juggernaut of formalism is a minority worldview of equal historical standing, even though it does not share equal awareness or popularity. Variously known as hermeneutics, constructivism, interpretationalism, and most recently postmodernism, this tradition has consistently challenged almost everything advanced by the formalists. Iterative development practices, including XP, and object thinking are consistent with the hermeneutic worldview. Unfortunately, most object, XP, and agile practitioners are unaware of this tradition and its potential for providing philosophical support and justification for their approach to software development. — David West

The Standish Group is an Information Technology organization that assesses risk, cost, return, and value of software projects. Since 1994, they have published the Chaos report that studies software failures and successes. The latest Chaos report recommends agile processes as one of the ten project success factors. (The Standish Group International Inc. 2012) — Gloria J. Miller

Summary of Scrum vs Kanban

Similarities:
- Both are Lean and Agile
- Both use pull scheduling
- Both limit WIP
- Both use transperency to drive process improvement
- Both focus on delivering releasable software and often
- Both are based on self-organizing teams
- Both require breaking the work into pieces.
- In both, the release plan is continuously optimized based on empirical data (velocity/lead time) — Henrik Kniberg

Most literature on the subject of agile methodology... is written from the viewpoint of software developers and programmers, and tends to place its main emphasis on programming techniques and agile project management - testing is usually only mentioned in the guise of unit testing and its associated tools. ...However, unit tests alone are not sufficient and broader-based testing is critical to the success of agile development processes. — Tilo Linz

It's often the case that teams working in agile processes do not actually go back to improve the user interface of the software. But, as the saying goes, "it's not iterative if you only do it once." Teams need to make a commitment to continuous improvement, and that means not simply refactoring code and addressing technical debt but also reworking and improving user interfaces. Teams must embrace the concept of UX debt and make a commitment to continuous improvement of the user experience. — Jeff Gothelf

The key idea of agile is that teams essentially manage themselves ... It works in software, and it turns out that it works with kids. — Bruce Feiler

As an Agile software development team, we'd been following the hallowed eXtreme Programming tenets, including YAGNI. That is, You Aren't Gonna Need It: a caution to not write unnecessary code - — Anonymous

To focus on the visible at the expense of the essential is irresponsible. — Bertrand Meyer

The Scrum idea of a separated Scrum Master is good for Scrum, but not appropriate for most projects. Good development requires not just talkers but doers. — Bertrand Meyer

The essence of Agile movement, whether in new product development, new service offerings, software applications, or project management, rests on two foundational goals: delivering valuable products to customers and creating working environments in which people look forward to coming to work each day. — Jim Highsmith

Indeed, the ratio of time spent reading versus writing is well over 10 to 1. We are constantly reading old code as part of the effort to write new code. ...[Therefore,] making it easy to read makes it easier to write. — Robert C. Martin

Worse yet is the rejection of upfront requirements. The basic observation is correct: requirements will change, and are hard anyway to capture at the beginning. In no way, however, does it imply the dramatic conclusion that upfront requirements are useless! What it does imply is that requirements should be subject to change, like all other artifacts on the software process.

[...]

The agile advice here is irresponsible and serious software projects should ignore it.The sound practice is to start collecting requirements at the beginning, produce a provisional version prior to engaging in design, and treat the requirements as a living product that undergoes constant adaptation throughout the project. — Bertrand Meyer