Skip to main content

Posts

Showing posts from October, 2010

And We are His Sisters and His Cousins and His Aunts...!

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

The Agile Business Case

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

Agile Lessons from the Army Leadership Field Manual

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