There are lots of quotes flying around the agile community. Some are logical, some are obvious, some are takeoffs from other quotes, a few are downright nonsense. I won't embarrass the author by using his or her name.
Here are some of those, I'll add to this post from the top when new quotes pop up almost daily.
| The Original Quote | The Assessment |
|
User stories are too often just rephrased specifications - #Fail |
User stories are short, simple descriptions of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system. They typically follow a simple template: As a < type of user >, I want < some goal > so that < some reason >. A software requirements specification (SRS) is a description of a software system to be developed. It lays out functional and non-functional requirements and may include a set of use cases that describe user interactions that the software must provide. If you write good user stories - from the point of view of the User, it defines a goal and the outcome that the goal will produce. As stated above the SRS contains a set of Use Case that describes User interactions the system must provide. This is one of those quotes that appear to be based on the lack of understanding of what a good User Stories and good software requirements look like. |
|
“Working software over comprehensive documentation.” IME software changes a lot of over time. Documentation, rarely so. |
Working software over comprehensive documentation fails to consider what the customer considers needed documentation to accompany the product. If that documentation needs to be comprehensive, it had better be comprehensive. Since when do the developers get to decide what the customer needs. Say the manual for the Manuals for Avionics systems for personal and commercial aircraft flight systems with their software-intensive system of systems in the domain we work. If your software can be operated, maintained, tested, V&V, upgraded without comprehensive documentation, fine. It's likely so simple it needs no comprehensive documentation. OR, it's so obvious it needs no documentation. OR you're just a coder and the documentation is done by someone else. |
|
Never confuse the map with the journey - The project plan is only an outline (and a guess at that), so you should believe the team’s results and not the plans. Remember, it is the achievement of the objectives that are important, not the production of artifacts. Be careful not to confuse the end (objectives) with the means (artifacts and activities).
|
Correct, but this quote is missing the other ½ of the core idea of all Closed Loop Control systems. When the actual or desired performance does not match the Planned performance, find the Root Cause of this variance and take corrective or preventive actions to get back on plan. If the Plan is not what you wanted or needed, given the past performance, then Change the Plan. That's what plans are for. They're a guide - a strategy - to reach a destination. They're required to change when the destination changes, or the path to that destination changes, or the means to reach that destination changes. This is the basis of all Closed Loop Control systems, from the speed control of the car, to the flight controls for an aircraft, to the temperature controls for your home, and of course the business controls for software development. Those artifacts may well be the critical success factors for the software - how about the User Manual, the Maintenance Manual, the Installation Manual, the Performance Tuning Manual. Or maybe the configuration instructions for updating and releasing the product. Or how about test resulting showing coverage, verification, and validation of the capabilities in support of maintenance of warranty. |
| We don’t need an accurate document. We need a shared understanding. |
So what happens when this shared understanding is the shared understanding of the wrong knowledge, requirement, instruction? How is that shared understanding shared in a way that can be validated and verified that it's what is wanted? Verbally, handwaving, sticky notes on the wall? How is that shared understanding preserved for later, possibly much later, when the software is in production in the field. Why did we decide to do it this way might be a question asked weeks, month, years later. Where's the accurate document documenting that shared understanding |
| Right and wrong cease to be useful concepts when you’re talking about software development. |
So in the agile development world, there is no right or wrong? No Right software to deliver the needed capabilities, for the needed cost, at the needed time? No right software to comply with external regulations, interfaces, security requirements, governance requirements? No right number of defects before we go live? No right performance of the system before it goes into production? |
| Prediction is very difficult, especially about the future - Neils Bohr |
Bohr was speaking of the evolving theory of quantum mechanics and what it was going to show in the late 1920's. In the software development business, a prediction may be difficult, but there are literally 100's of papers, books, tools, conferences, professional societies, training resources on how to predict - to make an estimate about the future - for software development. Here's a list of those resources we use in our domain and possibly yours. There is no reason not to learn how to make credible development estimates, with the accuracy and precision needed to make informed business and technical decisions. Now, you may not know how you may not be able to afford to make those decisions, the underlying probabilistic and statistical process may be too chaotic, or many other reasons. But predictions can be made and made well. |
