Your code: is it that stuff you store in version control or, as Paul Graham argues, "... your understanding of the problem you're exploring"? Graham has written an essay offering eight suggestions for developers trying to understand the code on which they're working - some of which seem to contradict the advice of the agilists.
Although agilists focus much of their energy on helping their agile projects succeed, it is helpful to periodically stop and consider what causes some agile projects and agile adoptions to fail. Armed with this knowledge, perhaps one can avoid these same pitfalls.
At the start of each New Year, some of us stop to look backward, and actively resolve to move forward wiser than before. Scott Ambler, Liz Barnett and Kirk Knoernschild have shared with us their recommendations for working smarter in 2007, including: take a hard look at at your business objectives; equip your teams properly to maximize agility; and above all - behave yourselves!
Scrum co-creator Ken Schwaber spoke at Agile2006 on code quality as a corporate asset. InfoQ presents video of his talk, The Canary in the Coalmine. Schwaber discussed how a degrading core codebase paralyses a team and negates any Agility gained through process improvement. He proposed strategies for management to identify, track and stop this downward spiral.
As adoption of Agile methodologies grows, challenges abound, including the possibility of dilution as teams copy practices rather than growing them, implementing them without understanding. InfoQ's own Deb Hartmann gives us a frank discussion about how failure to teach the basics puts much at risk: the integrity and engagement of team members, and the trust of their customers.
Martin Fowler, one of the original creators of the Agile Manifesto in 2001, reflected last week on reports of Agile process being imposed on teams from the outside. He states his reaction succinctly: "Imposing a process on a team is completely opposed to the principles of agile software, and has been since its inception."
Some people think they can only be Agile with small, co-located teams and full management support, but most teams aren't that lucky. So, should they should give up on Agile techniques? Scott Ambler's answer is a resounding "No!" His Dr. Dobbs article "Imperfectly Agile: You Too Can Be Agile!" outlines how Agilists overcome common challenges that others use as excuses for not being Agile.
James Shore, a recognized speaker and writer in the Agile space, has had a crazy idea: Get rid of your bug database. He's not advocating that teams ignore problems; but bug databases are often so packed with questions, feature requests, and defects that there's little hope of their all being resolved. Shore and some others in Extreme Programming circles think there's a better way.
John Casey recently spent some time refactoring Maven's assembly plugin, using coverage reporting to mark his progress and make sure he didn't break anything as he went. It didn't exactly go as planned - but at very least it was a learning experience. His conclusion: when you're seeking confidence through testing, perhaps the worst thing you can do is to look at a test coverage report.
Scott Ambler introduces a term for a familiar project phenomenon: the "green shift" that occurs when people rework status reports to make them more politically palatable to management. But can management actually handle the truth?
Technical debt can shorten a product's life. But when technical debt mounts, it can be difficult to see how to pay it off. In her StickyMinds column, Johanna Rothman explains practices to help teams start paying off that debt - thereby easing their product's development and maintenance for a long time.
Creeping Featuritis is an insidious sort of product rot, reducing useful software into heaps of expensive widgets and aggravating help features. Peter Abilla brings us a chart by Kathy Sierra, capturing what it looks like from the customer's point of view, and reminds us to "focus on the customer and abandon the competitor-focused strategy all-together."