A particularly worrying variant is the Scaled Agile Framework or SAFe. Essentially this is codified bureaucracy, in which the customer is almost totally absent. It is now pervasive in large firms because it gives the management a mandate to call themselves agile and keep doing what they have always done. Essentially it subordinates the agile teams to the bureaucracy, rather than doing what is necessary to achieve business agility, namely, namely [sic], transform the big monolithic internally-focused systems into arrangements where the budgets, HR, Finance and so on are flexible and externally focused in support the Agile teams in operations. The insignificant role of the customer in the chart above is indicative of the problem.

I’ve used the term *Feature Factory* at a couple conference talks over the past two years. I started using the term when a software developer friend complained that he was “just sitting in the factory, cranking out features, and sending them down the line.”

How do you know if you’re working in a feature factory?

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.

Here’s part 1 of short animated video describing our engineering culture.

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.