“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.”
www.drdobbs.com/architecture-and-design/endless-flexibility-the-enemy-of-agile/240169083, posted 2014 by peter in agile development opinion
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.
www.drdobbs.com/architecture-and-design/getting-the-point-of-points/240168663, posted 2014 by peter in agile development management planning
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.
www.drdobbs.com/architecture-and-design/theres-no-room-for-deadlines/240168577, posted 2014 by peter in agile development management planning
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.