In The Freedom of Limited Capacity, Agile coach Mishkin Berteig wrote about what happened when he used Agile planning practices on his own business. By making his long work queue visible, he now had a better way to grapple with reality. Paradoxically, he also experienced a reduction in his stress level - in spite of his very visible backlog! The same effect has been observed on Agile teams.
Alex Champandard has written a piece on using Scrum within the game development industry, and how Scrum can be augmented with Jim and Michele McCarthy's "Core Protocols."
In Better Software magazine, Robert Sabourin's article "X Marks the Test Case: Using Mind Maps for Software Design" shows how the practice of Mind Mapping helps with test design. The author says: "If you've run through the standard design approaches and still need that killer test case, try mind maps." And he goes on to suggest how to get started.
PRINCE 2 is a traditional project management method, mandated for government agencies in the UK. Extreme Programming (XP) is considered one of the lightest Agile software development methods, relying on team self-management. In this case study, Barbara Roberts uses one of the more management-oriented Agile methods, DSDM, to get these two approaches working together within a single project.
The fit between Agile teams and traditional enterprises can be challenging. Agile may highlight or exacerbate pre-existent dysfunctions, in areas a project manager may not be well-placed to address, so those involved in Agile roll-outs are thinking about alternate ways to organize the enterprise. Holacracy, created at Ternary Software, suggests that self-organization can extend outside IT.
The terms "Agile software development" and "Business Agility" are confusing: are they orthogonal or complementary? James Taylor says that for even the most complex systems, Agile development can deliver business agility - particularly when supported by the right technology. For business rules he recommends a Rules Engine, and provides guidance in how to distinguish rules from requirements.
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.
Software engineer Paul Tyma, in a recent blog entry, tells us "I don't get this new craze of a job called 'Agile Coach'. I mean, everything I've read about Agile and XP seems dead simple." Though not a proponent of Agile, Tyma has done XP, so perhaps there's a basis for his view that an Agile Coach is not so much a 'coach' as "a hall monitor or a secret police officer."
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.
Agile software development and Lean Thinking go hand-in-hand for many practitioners. Six-Sigma blackbelt Mike Wroblewski has blogged some lessons learned from a recent kaizen session. People are a key variable in both manufacturing and software environments, so his lessons learned in manufacturing are also interesting for Lean Software practitioners using kaizen events for process improvement.
Brian Marick, reflecting on conversations heard at Agile2006, blogged about his concern that some of us are telling stories from the purely human or social viewpoint, while other are telling technology-only stories, noting that that XP isn't a story you can tell well without talking about both of these. Marick encourages us to include both when we communicate in and about projects.
Bob Payne interviewed Mary and Tom Poppendieck at Agile2006 about their next Lean book, which focuses even more on software than the last. Mary summarizes it as "So you think Agile is a good idea: now what?" saying it will help people get started with Lean, going beyond the recipes of the first book to provide practical information and case studies to help teams do their own process experiments.
Scott Ambler believes that User Experience Design (UED) is critical to the success of agile software development techniques, because it increases a team's chances of building the right software to meet customers' real goals. This article describes how Agile and UED communities can work together closely for project success.
It's been said before: Agile may be simple, but it's not so easy. Mishkin Berteig contributes some one-page quick-references to jog our memories and keep us focused on delivering value.
Proponents of Agile methods suggest they can spare organizations some outsourcing nightmares, by helping in-house teams produce ROI comparable to outsourced solutions. Stories from Sprint and Sears provide incentive to at least give them a hearing.