{"id":148,"date":"2011-11-04T07:33:31","date_gmt":"2011-11-04T15:33:31","guid":{"rendered":"http:\/\/zuill.us\/WoodyZuill\/?p=148"},"modified":"2011-11-07T10:43:39","modified_gmt":"2011-11-07T18:43:39","slug":"agile-success-why-not-me-too","status":"publish","type":"post","link":"https:\/\/zuill.us\/WoodyZuill\/2011\/11\/04\/agile-success-why-not-me-too\/","title":{"rendered":"Agile Success – Why Not Me Too?"},"content":{"rendered":"

I like to talk<\/h3>\n

I was given an opportunity to present a session at the Agile San Diego group last night.\u00a0 I have some pretty clear ideas about how to be productive in developing software (and a fair number of solid successes in turning out useful software), and those who know me are sick of hearing this stuff.\u00a0\u00a0I am always looking for an opportunity to find someone new to bore.\u00a0 Thanks for stopping by.\u00a0<\/p>\n

Agile Success seems elusive<\/h3>\n

Over the past 13 years I’ve been using\u00a0(or sometimes fighting to be allowed to use) an Agile approach in software development.\u00a0 For about a year I have been slowly gathering my thoughts into a talk on Agile Success.\u00a0 I’ve given about 5 talks on this theme now\u00a0– each very different,\u00a0and the audience has mostly been folks\u00a0new to Agile thinking.\u00a0\u00a0<\/p>\n

Agile San Diego is a group of highly sophisticated Agilists who are typically expert debaters and highly competent loud arguers –\u00a0 I like it very much.\u00a0 So I took this opportunity to solidify my materials and\u00a0put it\u00a0to the test.\u00a0 The results were so-so, IMHO, but it is in the doing of a presentation that I discover the presentation that I must do.<\/p>\n

Agile Success – Why Not Me Too?<\/h3>\n

In its current state, the talk is called “Agile Success – Why Not Me Too?”.\u00a0 It’s mostly about the “Why Not”: we tend to block ourselves from achieving good result by hanging on to “old and busted” thinking and practices.\u00a0 Perhaps we do this because the old ways seem so right (but they are oh so wrong)\u00a0, or perhaps just because we are comfortable with them, or “our customers (or boss, or manager, or marketing) require it”, \u00a0or … well\u00a0 – there are a lot of reasons we keep doing things the same old way – you get the idea, I am sure.<\/p>\n

For this instance of the\u00a0talk, my main goal was to show that we are typically our own worst enemy.\u00a0\u00a0More specifically, it is the things we think are most solid,\u00a0meaningful, useful, and productive in our process that are the most likely\u00a0to be hampering our progress and wasting our time and money – and we\u00a0don’t have the skills or openness or whatever to recognize this.\u00a0 In other words, those are our\u00a0blind spots.\u00a0<\/p>\n

The Maxims<\/h3>\n

Here are my three main talking points.\u00a0 I call them Maxims (to differentiate them from the Values and Principles):<\/p>\n

Critical Maxim 1:
\nIt is in the doing\u00a0 of the work that we discover the work that we must do.<\/p>\n

Critical Maxim 2:
\nEmbracing change is IMPOSSIBLE if your code is not Easy to Read, Easy to Maintain, Easy to Grow, and Easy to Change.\u00a0 Everything else is secondary.\u00a0 Everything.\u00a0 This applies to \u201clean start-ups\u201d too!\u00a0 Code becomes HARD really fast – often within a few hours if we are not paying attention.<\/p>\n

Critical Maxim 3:
\nQuestion Everything<\/p>\n

In my own work, I use the Agile Manifesto and Principles as a guide to evaluate everything.\u00a0 I use them as a quick sanity test for every practice that I am using\u00a0or\u00a0thinking of using.\u00a0 However, I also recognize that I am the inventor of the process I follow, and therefore use the 3 Maxims\u00a0to keep from\u00a0getting off track.\u00a0<\/p>\n

Using Maxim 3, I also question\u00a0the value of the Maxims and the Agile Manifesto\/Principles themselves.\u00a0 It is a vicious, never-ending continuous loop of vicious, never-ending\u00a0continuous loop of… – so I don’t get too serious about it.\u00a0 Whenever my brain starts bleeding I take a break, let things coagulate, and then get back to it.<\/p>\n

Also, the 4 values, 12 principles, and 3 maxims are\u00a0not written in stone.\u00a0 It is likely that there are other important missing maxims\/values\/principles, and there might be errors and partial omissions.\u00a0 But this is a living thing – adjustments are allowed – cells split, some things become vestigial – and so on.\u00a0 Complete re-writes are allowed.\u00a0 Nothing is sacred.\u00a0 Continuous improvement\u00a0must include improving the things we improved previously and think can’t be improved.\u00a0 Throwing some things out and letting other things die off\u00a0is okay.<\/p>\n

The talk took less than an hour, plus about 1\/2 hour for discussion.\u00a0\u00a0 Not bad for solving all the problems that ever were or ever could be.\u00a0 Well, no one else saw it that way, but this is my blog and I can make up anything I want.<\/p>\n

However, what I was trying to show is that my current thinking (which is based on real, every day cranking out of healthy, usable functionality) is that:<\/p>\n