QUESTIONS ABOUT SOFTWARE DEVELOPMENT METHODS AND PRACTICES OR PROJECT MANAGEMENT ARE OFF-TOPIC. Please consider Software Engineering or Project Management Stack Exchanges for these questions.

- Stackoverflow.com Wiki
11 articles, 7 books. Go to books ↓

What developers see as iterative and flexible, users see as disorganized and never-ending. Here’s how some experienced developers have changed that perception.


We have suffered through countless consultants and hours of meetings. Through this we discovered that Agile is simply the obfuscation of common sense – the bewitchment of the mind through language.


Many traditional industries seem to have formulated very well understood and reliable processes. However, rather than copying these approaches, the software industry is increasingly turning to a brand-new way of doing things: Agile.


What software makers can learn from Japanese manufacturing.


The tragedy of the cargo cult is its adherence to the superficial, outward signs of some idea combined with ignorance of how that idea actually works.


People in our industry think they stopped doing waterfall and switched to agile. In reality they just switched to high-frequency waterfall.


Technology culture is driven by an underlying ethos of agility, speed, experimentation, iteration, and hard work. This ethos — which can often foster incredible innovation, productivity, and change — is embodied by the Facebook-coined phrase, “Move fast and break things.” It’s come to define our culture and even permeate beyond technology companies into other industries looking to achieve the same gains at the same rate. But when it comes to people, “move fast and break things” doesn’t work. Because the “thing” being broken is a person.


Too many Agile teams feel they’re working on an assembly line, trying to keep up with the pace set by management. This pace, usually called a team’s “velocity”, may create a virtual assembly line. This is turning your Software Engineers into Agile Assembly Line Workers, and the negative effects are similar to what Ford’s workers experienced.


This guide has everything you need to know about agile metrics. It will cover every possible metrics you would possibly want to use, and tell you what they mean, when you should use them, how you should use them, and when you shouldn’t use them.


Agility is a good thing, no doubt, and the Agile Manifesto isn’t unreasonable. Compared to a straw-man practice called “Waterfall”, Agile is notably superior. Yet, so much of Agile as-practiced is deeply harmful, and I don’t really think that the Agile/Waterfall dichotomy is useful in the first place.