Pragmatic Agilist

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