Skip to main content

Posts

Showing posts from September, 2010

Schrödinger's Agile Leader

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

Agile Fun

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

Value Chains and Value Streams: Strategic Maps Are Better For Project Inception

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

Using Agile to Optimize Value of Projects

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

Slaying the Agile Scaling Lycanthrope with A Barrage of Silver Bullets, er Maturity Models

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