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...

I don't know whether you have begun to participate in the trend of communicating through "skits" rather than Keynote or MS-PowerPoint presentations, but I would just like to recommend if you do it, you should dramatize "Jeapordy" with questions relative to your message ("What is ... VELOCITY?").  That is easy to do, and always a winner.  If "Jeapordy" is not possible on your budget, then next best is to have a large group of normally dignified people traipse around on stage in herd formation, as is so often done in Gilbert and Sullivan. I couldn't help but notice this morning that on our small commuter jet from Chicago to Atlanta, there were 50 seats, only six of which were in first class.  As I sat in the airport lounge waiting to board, I noticed there were 38 of us waiting to be upgraded.  38!  And only one unfilled seat.  So eventually, we all tried to board, and that's when I noticed we were all pulling carry-on sized black ro...

Many agile teams have never seen a business case, ever, and they may even be proud of it. Our mantra is that we deliver "business value," not just "software," quicker, better, and faster, but if so, we certainly don't spend a lot of time reporting on value delivery, and in fact we may be scornful about "analysis paralysis."  As software developers, we consider ourselves to be doing quite well if we can deliver the software every two weeks (or continuously).  And this is particularly if we've enabled this frequent high-quality delivery through automated testing and automated build-and-release techniques.  We've reduced business risk by making results visible more often, and allowing the business to change direction more frequently.  We assert that along the way of course we're also delivering value.  But how would we prove it? I've recently posited that we shouldn't even think of doing agile projects without capturing and recordi...

You will be amazed to learn that Army Field Manual number 6-22 is entitled Army Leadership, Competent, Confident and Agile .   If it weren't for the small word, "Army," at the beginning of this title, any aspiring lean/agile leader might eagerly browse through this readily available text for tips and tricks to warm the heart and increase the team velocity.  In case there's any suspense, I'm going to suggest that despite the title, you do exactly that. Of course, in the world of the Army Field Manual, command-and-control, like gravity, isn't a guideline--it's the law.  And we in the agile/lean community typically frown on command-and-control right along with " waterfall ," " big modeling upfront ," and using pens smaller than sharpies.  See, for example, this impassioned description from the " Energized Work " blog: Command and control elicits compliance to enforced processes through management by policy. Focusing on proces...

The "agile team leader" seems at first glance to be a sort of Schrödinger's cat :  if a project team is self-governing, then who is leading it?  If there's a leader, is it self-governing?  Is everyone a leader?  Is "the team" a leader?  What happens to individual responsibility and career development, and who watches over it?  Who makes the decisions?  What does an agile executive look like?  As Martin Proulx captures the issue in the title of his excellent August Analytical-Mind blog posting, " I don't feel so good, I'm a people manager in an Agile organization. "  It's interesting to think about. One way to break this question down is to recap some standard and helpful distinctions in vocabulary.  In the growing field of "leadership training," it has become well understood that a "manager" is not the same as a "leader."  See for example this ChangingMinds.org blog entry .  As managers aspire to become...

A colleague of mine just sent out a link to an exquisite Schumpeter blog in the Economist entitled " Down With Fun ."  You must read this blog!  It skewers the concept of enforced workplace giddiness for strategic gain.  In my view, the blogger is unnecessarily grumpy that today's workplace has eliminated the kind of fun they have on "Mad Men," which includes smoking, drinking, and vigorous workplace fornication, but that's just me. From The Economist, 9/16/2010 What about fun, though?  Should we simply give up on workplace fun?  Is my employer, ThoughtWorks, wrong to make "fun" one of its core values ?  The Economist warns that "...as soon as fun becomes part of a corporate strategy it ceases to be fun and becomes its opposite—at best an empty shell and at worst a tiresome imposition."  And indeed sometimes I feel a twinge of irritation as I leap away from a fast-moving oncoming scooter on the carpeting, duck from the path of ...

I was working on some training materials this week, and I needed to whip up as-is and to-be business process maps .  These would be used to help trainees visualize how the software they were going to build in an agile way during the training would transform the fictional business for which it was being written. I got completely mired down in this seemingly simple task, and I realized it is because the more you think about it, the more the business process mapping for the purpose of planning a software project is just not simple. BPMN 2.0 If you're like me, you are probably thinking, "well gee, just throw together some circles, rectangles, and arrows, and you're done, what's the big deal?"  Indeed, I started down this track, and in the name of being professional, I spent an afternoon this week familiarizing myself with Business Process Modeling Notation (BPMN, currently at version 2.0).  I became fairly adept at BPMN, which is very nice for creating process ...

I was asked recently for guidelines on "how to use value points in agile projects".  I was glad to get the question, since some people, like the blogger who writes " Agile 101 ," say stuff like: value points are "not appropriate or particularly necessary in all cases."  Gah!  The Agile 101 author actually goes on to do quite a nice job describing how to use value points, and I recommend you visit the blog, but I would like to explain why I don't think all of this is an optional nicety. If you were CEO of your company and you were being briefed on your project every two weeks, what do you want to hear from your agile team? "We delivered 14 value points this iteration" (which translates into some specific thing the company values, in terms of cost avoidance, expected revenue within a portfolio, increased quality, or faster time to market) "We delivered 14 story points this iteration" (which translates directly into "2 weeks ...

Scott Ambler became my new hero in an instant today when I reached the conclusion of his dazzling Scaling Agile: An Executive Guide , published on his Agility@Scale blog site in February, 2010, where he refers to corporate productivity challenges as "lycanthropes." [p. 19, if you want to skip right to it.] I had been hoping to write about scaling agile to large organizations today and will doubtlessly do so immediately, heavily referencing Ambler, whose blog you really must visit early and often.  But I hadn't heard the word lycanthrope before, and I just had to pause and marvel at the aptitude of the metaphor, in a way I haven't done since I encountered Dan North and Martin Fowler describing the relationship between business and technical people in a software endeavor as the " Yawning Crevasse of Doom ."  If agile enthusiasts gain any traction at all in this world, and apparently we are (Ambler quotes a survey showing that 76% of American corporation...

A friend of mine works for a company that did some one-stop shopping and hired the vendor of their agile project management software to also run their IT organization transformation.  Handily, the transformation consisted of implementing the tool, which I'll call MegaAgileTron, and then providing training on the tool.  Apparently, at my friend's Friday's stand-up meeting, one of the people on his team said proudly "Wow, I have a lot of work to do today in [MegaAgileTron]!" And everyone nodded enthusiastically about how agile they have all become.  As my friend said, "it wasn't funny at the time, but now that I think about it..." Agile project management tracking software has become its own industry, and the gadget-oriented CIO may be tempted to think that the best way to take her organization to the next level is to buy, install, and provide training on a new project management tool.  This approach, once taken, has the handy side effect that she ca...

I was gripped by anxiety today when I found out that Toyota is recalling another 1.13 million vehicles , and even more if you count Canada. I worry for Toyota owners of course, American and Canadian alike.  But professionally, I feel even more worried for us advocates of lean and agile principles who have depended on Toyota to provide a one-word motivation to our audiences.  For decades, Toyota has been our hero , and even if we quickly disavow the company now as having any major role to play with lean, the questions about Toyota’s quality and processes are going to come back to haunt us , and we need to be prepared. So today’s recall news brings agile presenters (and would-be Toyota owners) together to ask three new common, and newly urgent, questions: Is there actually a problem?  Do friends let friends buy Toyota any more?  Or is this nothing more than an emotional media circus? If there is a problem, was it caused by Toyota’s adherence to lean principles?...

I was recently cheered and inspired by Jonathan Rasmussen's post on the " agile samurai ," also the title of his recent book.  In his blog, he suggests that the the samurai, unlike the "rice pickers," are the ones who: say what needs to be said call BS when they see it laugh in the face of unrealistic schedules and expectations tackle all the hard, complex, thorny stuff no one else wants to wade into are technically excellent at their craft take pride in their work and are comfortable in their own skins I liked this description, but it made me nervous in some ways as well. So since I'm prone to zealous pursuit of metaphors, to the point of finding and reading two or even three results of a Google search as I look for enlightenment, I investigated real-life samurais and found that they were actually constrained significantly in their behavior, living by a creed of " loyalty to one's master, self discipline and respectful, ethical beha...