Pragmatic Agilist

One reality of modern software development is that teams are not collocated.  Not around the same table, not in the same building, not in the same city, and often not in the same time zone. In some cases, companies are taking advantage of exchange rates or pay rates, and locate teams where they can buy more hours for each unit of their currency.   In other cases, companies cultivate a better work-life balance for their employees, and stop enforcing policies around grueling commutes and time clock punching. Communications tend to deteriorate even more once you let Briana work from home in Wisconsin and Tad work from his mom's place in Hawaii, and everyone has to get on a conference call with Australia at 4:30pm, CST, since a third of the team isn't even in a time zone which is offset by a full hour from you.  Especially if Tad has small barking dogs and a cockatoo. So here's one incredibly good thing you can do, in the face of this potentially toxic communicatio...

IT community members catechized on the Agile Manifesto will recall that the original signers placed a higher value on "working software" than on "comprehensive documentation." But is working software in isolation our ultimate goal?  I think that as the Agile community has moved in the direction of delivering value , rather than just delivering working software , we are now newly realizing we need more than just rich face-to-face conversations at white boards.  We need accessible archives populated by well-structured documents which have been written in full sentences.  It's time to even the balance. An early Tech Writer Scott Ambler has done the Agile community a huge service with frequent and comprehensive surveys to determine what people are actually doing in the field, and how well it's working ( see this Ambysoft page for a full list of his surveys and results ).  As Ambler reviewed his results in 2008, he was surprised to find that Agile ...

I just read a very angry blog entitled:  Business Analysts And The Million Dollar Question - What Would You Say You Do Here?   The author quotes Scott Ambler's famous line, " Remember, 'BA' is also the abbreviation for band-aid " and he goes on to say that if you hire a typical BA, chances are high that "you're not just wasting your money; you are, as a matter of fact, risking your project by introducing an additional monkey that'll have to be subdued and sedated as your project moves on and the rest of your team starts doing some real work."  Okay, then. Tom Smykowski, Office Space BA The Agile Manifesto itself seems to be taking a direct swipe at Business Analysts when it talks about valuing " working software over comprehensive documentation" and "customer collaboration over contract negotiation."  Somehow, Business Analysts have ended up as a proxy for everything bad about the "Waterfall" developm...

Forced by circumstances (and an especially pragmatic client), I've recently been asking peers and "the blogosphere" the apparently naive question, "is it important to do automated testing and clear up what Mike Cohn calls ' manual test technical debt ?'" Theoretically, if you have no Big Upfront Design and you also have no automated test suite, you're pretty much just building a big unplanned mess and you'll never be able to change anything for fear of breaking something else.  I understand that, and so does my pragmatic client.  But can this issue be quantified?  Aside from feeling somewhat inadequate when reading agile theory, I mean. The reason it's important to ask this question is that setting up and maintaining automated testing is expensive.  Unlike many agile practices, which can be set off with some sharpies and a clean wall, automated testing requires a large scale capital expenditure to bring one or more testing packages in...