Pragmatic Agilist

Experienced agilists make it sound so easy, don't they?  They tell you over beers about the big, honking project they did last time.  They showed up, did some "workshopping," set up a little CI environment, and then, two weeks later, they began churning out working software.  And not just any working software:  high quality, low complexity, and perfect fit to business needs.  And why not?  The Product Owner was in the room to design and approve it!  Agile is fun!  Woo hoo! This may not sound like the projects you do at all, where you experience confusion, resistance, fear, sweat, and tears, and you teeter daily on the edge of failure, public humiliation, alcoholism, and unwilling participation in corporate "resource efficiency" efforts.   How can you be an agilist when you don't share this ability to triumph over the grim corporate realities and do the impossible every day (twice on Sunday?) http://simple.wikipedia.org/wiki/File:Shamu_in_SeaWorld,_San_

I'm pretty sure my few remaining friends in the "small, collocated team agile" community are going to desert me after this, but I actually have a checklist of 10 things to think about if you're a product owner at a big company thinking of trying out some agile today.  Some of these might even apply to you if you're in a smaller place.  So at the risk of inciting an anti-checklist riot (I'm sorry, Pez!), I am putting this out there in case it is helpful to someone else. From http://www.yogawithjohn.com/tag/yoga-class/ Here's what you should think about: 1.        Your staffing pattern.  A full agile project requires that you have the full team engaged for the whole duration of the project at the right ratios.  So as you provision the project, check to see whether you can arrange this staffing pattern.  If not, you will encounter risks because of missing people.  Concretely it means that: a.        You need your user experience people (if a

What do you think is your biggest blocker, in terms of introducing agile software development to an organization which hasn't used it before?  Ignorance?  Lack of the proper tools?  Cube farms?  These perils are grave indeed, but they are nothing compared to something for which I have just learned the name:  the " Dark Triad ."  Machiavelli tells it like it is--or does he? The Dark Triad consists of three personality constructs: Machiavellianism, narcissism, and psychopathy.  As that source of all knowledge, wikipedia says, The narcissistic personality (in the clinical sense) is characterized by a grandiose self-view, a sense of entitlement, lack of empathy, and egotism. The Machiavellian personality is characterized by manipulation and exploitation of others, with a cynical disregard for morality and a focus on self-interest and deception. The psychopathic personality, is characterized by impulsive thrill-seeking, and in its "primary" form by

As a budding agile coach at a new site, you are probably poised to champion "transparency."  You eager to introduce your friends to " information radiators ," open lines of communication, and fortnightly project showcases.  But not so fast! From some blogger who borrowed it from Dilbert without permission. As a wise mentor of mine once said, "the truth is something to be very careful with."  The control of information directly and indirectly translates into control over budgets, income, and even job security.  Sadly, if you are working in any organization which employs humans, you need to be careful.  You will run into a world of pain if you misunderstand what will happen to the flow of money in your company when you change the flow of information.  Three patterns to look out for: 1)  " Good news up; bad news down."   Are there people in your organization whose entire job it is to make sure that the people at the "coal face"

Albert Einstein turns out to have been both an awesomely brilliant physicist and an enthusiastic but comically bad sailor .  Apparently, he spent whole summers amusing his neighbors by capsizing frequently and needing to be fished out of the water.  You would think that he could be calculating wind directions and consequences in some small corner of his vast brain, while also solving World Peace, but you would be wrong.  Not sure about the World Peace thing, but he definitely couldn't sail. From a post by "Angel" on http://www.boatdesign.net/forums/sailboats/einsteins-sailboat-tinef-40050.html.  Watermark suggests image wasn't obtained legally by Angel, but what a cool photo! Einstein's difficulties have several points of relevance to you, if you are a person charged with helping people develop software in an agile way.  It's not just a parable--it's a valuable set of lessons learned!  Here's how to plunge forward in your agile training progra

Do you shun the people at work who hassle you with statistics about your company's software cyclomatic complexity?  Are you tired of this issue, frequently raised by developers whom you need, but whom you privately think of as highly strung prima donnas?  Do the words "JUST GO AWAY" not seem to work with these people? From http://www.comicvine.com/prophet-of-doom/29-66484/ You and I may find this counter-intuitive, but it turns out these geeky prophets of doom have a point.  "Technical debt" has actually been proven in the real world to cost you money both directly and indirectly.  Lots of money.  Moreover, you incur additional security risks when you turn a blind eye to unnecessary code complexity.  Your current laissez-faire attitude towards code quality could actually turn into an unplanned financial catastrophe at an inconvenient moment in the future. The "golden age" of research on costs of cyclomatic complexity seems to have been betwee

Get a bunch of agile evangelists together, and we like nothing better than argue over the details of our favorite Agile Maturity Models (AMMs) over a few beers, the more complex the better.  "But HOW can you make a REAL DIFFERENCE until you TACKLE HIRING PRACTICES FIRST!" we holler, having (unfortunately) switched to tequila shots a little later in the evening.  Our client practices are raw boulders, and we are going to help them build a pyramid! http://science.howstuffworks.com/engineering/structural/pyramid.htm If only our clients will listen to us, we think, we can help them "start small," and gradually evolve into high-performing teams like the ones we're used to.  First they might try Stand-Ups and Burn-Ups, we say.  Then if all goes well, we will try test automation.  Refactoring for extra credit, but only once the analysts have been trained.  Sequence is all, and it gives us a lot to argue about.  Let's build that pyramid! AMM rendering of

Do you have trouble wrapping your arms around the question "what do Agile Business Analysts do?"  I figured it out today!  And I will tell you!  And as a special bonus, I figured out what the Waterfall BAs do too--so if you didn't know, and you were worried--and who among us isn't--you can kill both birds with one blog. Business analysts of every ilk do two things really well: They look at the big picture end-to-end.  They are able to describe concisely what your project is doing and why.  They are czars and czarinas of the "elevator pitch."  They see it all, and they make sure everyone else on the team sees it too. They look at every detail of your project pixel by pixel .  Who is the person in the room most likely to say: "wow, paragraph 4, sub-element 2 totally contradicts that chart on page 3 in the leftmost column."  The BA, that's who.  They are razor sharp.  They are intolerant of errors.  Any errors.  A BA is probably reading thi

Let's say you're a Business Analyst, and you're okay.  You've done your job for years.  You are a subject matter expert in your own right, and you get the job done.  Suddenly, a sparkly-eyed Agile Guru (SEAG) shows up at your workplace and asks you to stop writing a "requirements document" that holistically describes the software your developer friends will be building.  Instead, the SEAG insists that you use a set of index cards to "hint" at what needs to be built, tape the cards to a wall, and plan to focus on the details of each card later, right before the developer starts to build it.  And maybe you won't even write those details down then, either.  You'll take the "hint" from the card, have a "conversation" with the developer, everyone will nod enthusiastically, and off you go to find out more about a different hinty card. Really, when you put it that way, it sounds totally crazy. This is why some an

Agile enthusiasts are quick to make fun of people who pick and choose among various agile concepts, philosophies, techniques, and tools, rather than working hard to be "pure."  We have a word for people who do that:  dilettantes.  From http://lifeasareader.blogspot.com/2010/11/i-am-cafeteria-catholic.html But when we use two words we call them "cafeteria agilists." If a software development team has a burn-down chart, weekly releases of something to production, and no discussions with the business, ever, we are quick to chorus "THAT's not AGILE!"   If they have a great working relationship with business partners and talk daily, but managers still do estimates of work durations, and assign work to the programmers and testers, we roll our eyes, and we start to abbreviate:  "TNA!"   If a team deviates from any named agile technique, be it Scrum, Extreme Programming, Crystal, or WaterScrumFall, and even if they follow that last one to

From a really great blog post on agile adoption:  http://smoovejazz.wordpress.com/2011/02/16/an-agile-approach-for-adopting-agile-practices/ I've observed some different agile transformation patterns, and maybe you have too: Just Do Standups   (Shoot, then Aim):   some people feel that since you're "agile," you should just start doing stuff, like daily standups, and then build more of the the plan as you go.  Find a team and start doing some agile with them!  Start a revolution one practice at a time, one team at a time. Pros:   you're very busy from the start. Cons:   what exactly are you doing and why? KPI-Driven Change (Aim, then Shoot) : some people who have worked in large corporations for a while will tell you that to get the respect of the people, you need to start with a plan, support the plan with awesome printed and online collateral.  Then you "kick off," tell teams what to do, and measure them using "Key Productivity Indica