"No amount of process over-specification will make up for bad people. Far better: Staff your project with good people, do whatever it takes to keep them happy, and use simple, well-bounded processes to guide them along the way."
Coad, LeFebvre, De Luca, 1999, Java Modeling in Color with UML
"The history of software engineering is riddled with failed attempts to realize gains in quality and productivity without first creating a supportive environment To improve bad situations, many managers spend their money on … tools, methodologies, outsourcing, training, application packages and what have you, but they rarely spend anything to improve or to remove the management that made those situations in the first place."
Gerald M. Weinberg, 1997, Quality Software Management: Volume 4 Anticipating Change
"Developing software in a team is a social process taking place through interactions with other people. … The quality of these interactions determines, to a great extent, the enjoyability, sustainability, and efficiency of the overall development process."
Luke Hohmann, 1997, Journey of the Software Professional: The Sociology of Software Development
"Some managers and customers believe they can pick the value of all four variables. 'You are going to get all these requirements done by the first of next month with exactly this team. And quality is job one here, ...'. When this happens , quality always goes out the window ..., since nobody does good work under too much stress. Also likely to go out of control is time. You get crappy software late."
Kent Beck, 2000, Extreme Programming Explained: Embrace Change
"... before you start planning a project, you have to understand why you need to carry out the project. Without understanding why you need the project, how will you be able to tell if you have succeeded?"
Kent Beck, Martin Fowler, 2001, Planning Extreme Programming
"... the quality of the people on a project, and their organization and management, are much more important factors in the success than are the tools they use or the technical approaches they take."
Frederick P. Brooks, 1995, The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition
"I've evaluated process definitions in many major commercial methodologies. After lengthy inspection and analysis, I couldn't find a single process that was defined in enough detail to ensure repeatable outputs. … When activities are so complicated and complex that they can't be defined in advance and aren't repeatable, they require the empirical process control model."
Ken Schwaber, Mike Beedle, 2002, Agile Software Development with Scrum
"Most managers are willing to concede the idea that they've got more people worries than technical worries. But they seldom manage that way. They manage as though technology were their principle concern."
Tom DeMarco, Timothy Lister, 1997, Peopleware: Productive Projects and Teams
"A software process describes what to communicate, when to communicate, how to communicate, and with whom to communicate (most process descriptions will not tell you why; this is normally left for someone to write a book about!)."
Stephen R. Palmer, John M. Felsing, 2002, A Practical Guide to Feature-Driven Development
"There is no room for a 'throw it over the wall' mentality on an agile project. Analysts do not throw requirements over the wall to designers. Designers and architects do not throw designs over a wall to coders; coders do not throw half-tested code over the wall to testers. A successful agile team must have a we're-all-in-this-together mindset."
Mike Cohn, 2006, Agile Estimating and Planning
"There is a vast difference between a product that forces you to change the way you work and one that inspires you to work differently. Being forced to do it 'their' way is uncomfortable and usually unproductive. The freedom to discover better ways of working is more enjoyable and inspires new insights into other approaches to get your work done."
Andy Carmichael, Dan Haywood, 2002, Better Software Faster
"The word 'agile' implies that something is flexible and responsive and in a Darwinian sense has an innate ability to cope with change. ... By implication, Agile software development methods should be able to survive in an atmosphere of constant change and emerge with success."
David J. Anderson, 2004, Agile Management for Software Engineering: Applying the Theory of Constraints for Business Results
"In our experience, as teams move to more agile development practices, many come to rely less on the requirements and architectural understandings (and more extensive modeling) that they may have acquired in the earlier 'lifecycle' phases of their prior methods. At the same time, however, many of these same teams have come to rely on simple but effective visual representation of the domain model as the primary architectural construct for the project."
Dean Leffingwell, 2007, Scaling Software Agility: Best Practices for Large Enterprises
"Not every enterprise that tries to adopt Scrum will succeed. At times, you and your people will hate Scrum. However, don't shoot it. It is only the messenger. To the extent that you and your enterprise succeed, though, you will always know where you stand. … Sometimes such transparency let's us see things that aren't what we wish to see."
Ken Schwaber, 2007, The Enterprise and Scrum
"...if you sit back and reflect for a moment, you'll notice that producing and maintaining software is not a random series of events. There are patterns, and these patterns offer an opportunity to take control of our products, our organizations, and our lives."
Gerald M. Weinberg, 1992, Quality Software Management: Volume 1 Systems Thinking
"There are three legs that hold up every implementation of empirical process control: visibility, inspection, and adaptation. … those aspects of the process that affect the outcome must be visible … various aspects of the process must be inspected frequently enough that unacceptable variation in the process can be detected . … If … one or more aspects of the process are outside acceptable limits … the inspector must adjust the process or the material being processed."
Ken Schwaber, 2004, Agile Project Management with Scrum
"Use case modeling, when used in isolation and performed incorrectly, may lead to certain types of problems.... the possibility of ending up with a functional model instead of an object model. … Use cases authored by different developers may describe the same thing differently. … When domain analysis is performed in conjunction with use case modeling, it reduces the risk of a functional design. … Domain analysis pinpoints the language to be used to create textual descriptions in the use cases."
Frank Armour, Granville Miller, 2001, Advanced Use Case Modeling: Software Systems
"IT projects are supposed to generate business benefits in the form of either increased revenue (make money) or decreased costs (save money). All other benefits, e.g. increased customer satisfaction, reduced order cycle time, reduced risk or better regulatory compliance, ultimately end up being a lever for one or both of these categories."
Michael Gentle, 2007, IT Success!: Towards a New Model for Information Technology
"Various studies have shown that in addition to being more effective at catching errors than testing, reviews find different kinds of errors than testing does … Thus, even when testing is done effectively, reviews are needed for a comprehensive quality program."
Steve McConnell, 2007, Code Complete: A Practical Handbook of Software Construction
"Many people may thnk that agile is just another software development process. Although that is true to a degree, there is a lot more to agile than just a process or just a set of practices. Agile (or agility) is more of a mindset - a way of thnking about software development."
Greg Smith, Ahmed Sidky, 2009, Becoming Agile: ...in an imperfect world
Copyright 2010 Stephen R. Palmer. All rights reserved.