Many developers have been voicing their concerns about Agile being broken lately. Among them are prominent figures like Robert C. Martin and Kent Beck – two of the people who charted the Agile Manifesto. Some of the most frequently-mentioned problems with Agile are: Agile ignores technical debt; frameworks like Scrum are just “red tape,” which they were never supposed to be; programmers are asked to commit to arbitrary estimates and deadlines and never get the time to think thoroughly about the features they’re creating. So if we can acknowledge and work on these problems, perhaps we can fix Agile.

When you are solving a difficult problem re-ask the problem so that your solution helps you learn faster. Find a faster way to fail, recover, and try again. If the problem you are trying to solve involves creating a magnum opus, you are solving the wrong problem.

“We’re trying to be really agile, so we don’t waste time on design or documentation.”

“I have to ship this to production immediately, so I don’t have time to write tests!”

“We didn’t have time to automate everything, so we just deploy our code by hand.”

The desire to solve every possible problem that might come up in some context leads to failure. Solve the problem at hand, nothing more. Start with the application at hand. Everything that's not needed to implement that application, down to the function-argument level, has to go. Sure, write the code so that you can extend it later, but don't put those extensions into it right off the bat.

An informed guide to misconceptions of Agile.

I recently came across a rather misinformed document called the Anti-Agile Manifesto. Normally, I just ignore this sort of thing, but in this case, people I know who are in the exploratory phase of agile adoption were treating the document seriously. Because the thinking in this document, which is not uncommon, undermines the success of fledgling agile shops, it seemed worth discussing it.

First a definition: A story point is a measure of the effort required to build out a story. It has nothing to do with time. Points usually occur on a 1-to-5 scale (where 1 represents a trivial effort), but some prefer a Fibonacci sequence (1, 2, 3, 5, 8, 13, 21…) because the further you get from trivial, the more the effort ratchets up. I can't emphasize too strongly that this measure has nothing to do with time beyond the broad observation that hard stuff takes longer. There is no way to map a point to a particular time interval.

In other words, you're estimating something concrete — a fixed set of features. To insist on meeting an estimate at a fixed deadline is to commit to building that set of features. That set is bound to be wrong, however, so the estimate is bound to be meaningless. Committing to the deadline is effectively a commitment to build the wrong product.

I'm not sure about you, but in my "real world," building a product that nobody's going to buy isn't a particularly important goal.

The iteration is a cornerstone of agile development. It provides a heartbeat for the team and its stakeholders, and a structure for various routine activities that help keep development work aligned with what the customer needs. However, the way many teams run their iterations creates serious pitfalls which can keep them from delivering software as effectively as they could.

The orthodox approach to the iteration is to treat it as a timebox for delivering a batch of stories, which is the approach most Scrum teams take with sprints (the Scrum term for an iteration). In recent years many teams have scrapped this approach, either using iterations more as a checkpoint, as many ThoughtWorks teams do, or scrapping them entirely with Kanban and Lean software development.

1–9 (9)