A long, long time ago I started life (okay college life) as an Engineer. Electrical. Analog. For having grown up with always having a computer in my room I was about as far away from the digital world I could get and still be technical. Computing was easy. Oh pascal, if only you could see me now. Those were wild days, staying up until all hours of the night sitting in a basement computer lab trying to finish an assignment. When I wasn’t at classes or getting into a variety of trouble, I would spend time with my roommate, a Mac user. He’d mock my Amiga; “Do you really need two buttons?” I’d mock the Mac (pre-classic) “Hey I’ve got 4096 colors” but we’d agree on one thing, both were better than that loser IBM machine two dorm rooms down the hall.
Then came real life, I fell into the digital world, and found myself back in school getting a more formal digital education. I found myself in Design Patterns, listening to people around me furiously debating the merits and needs of singletons, factories and observers.
Then came Java, and the arguments continued. Performance, idiosyncracies of langauge (both C++ and Java) etc., etc.
Then came Open Source. Don’t get me started with open source. If the OS mafia reads anything I write they’ll try to shutdown our website.
Now we have Agile. And Lean Development. And Continuous Integration (CI). I’ll lump them together because they are the current arguments I hear today. Yeah, arguments. Developers become elevated and yell out “You’re not really agile!” I read books on what it means to be Lean, and how to identify if you are Lean. I find CI writers muttering under their breath that any build process that occurs hourly isn’t truly CI.
They’ve lost focus. Or more importantly their focus should not be your focus.
I wasn’t hired because I was a Design Patterns zealot. I wasn’t hired because there was a need for an expert on Lean Development. I wasn’t hired to support code in the OS movement. I was hired to produce a product. Our customers want our product, they want it yesterday, both features and fixes.
So what’s the best way to deliver value to the company and customer? To be honest, I may not know the best way, but I know we will do our best to do whatever it takes. I and my coworkers strive to find reasonable solutions in a reasonable time.
But the zealots cry out and tell you what you are doing wrong, not doing right. What they don’t understand is that if they want to be heard they have to show the value in the changes. You need to give the agile concepts breathing room. This is what really encourages adoption. Agile zealots need to understand why there is resistance, understand people’s concerns and address them, and believe me they will embrace the positive elements.
On the other side, why listen to these zealots? Because if you can get past the worship and hype, there is value in what they describe. If you listen, you can figure out what elements will be useful.
Agile really is an evolutionary model. Agile isn’t about anarchy or cowboy developers, but about adopting processes that improve on process management. Agile really helps break logjams where problems seemed intractable or a great unknown, places where development has struggled for decades over thinking problems only to have their solutions fall flat and disappoint customers.
Lean Development has a great focus on continuous refinement. Focus on problem areas and work to make it a little better. After you’ve done this take another look and make it a little better somewhere else. Very quickly the improvements add up.
And Continuous Integration keeps simple problems simple, resolving them in a timely manner. CI keeps developers from sitting on problems further compounding integration, testing and deployment.
There are values that are worth a look in all of these movements. Take what they give you, find the value and use it. Continuous Integration makes your life better. Problems are found (and hopefully fixed) when they happen, not weeks later. You are getting continuous feedback on the health of your project, not monthly or weekly feedback. If your life is better you can spend more time providing value to your company and your customers. If you deal with less pain you have more time to solve the problems you should be solving. And adding the features that your customers are waiting for and wanted yesterday.
What are you waiting for? Don’t be discouraged thinking you aren’t using CI ‘correctly’. Take elements and make them work for you, and the value will come quickly.
Build useful products that solve difficult technical problems? What kind of crazy talk is that? Next you’ll be saying that companies that use phrases like “Web 2.0″ should try to be profitable…
No pure solution works in all cases, but lets be honest most projects don’t implement unit tests, many projects don’t use a continuous build that works and gets fixed immediately when it fails and most projects still write big requiements documents and hang their clients at the end of a contract.
Agile has a lot to teach, and is still being adapted and defined. The banging on the desks by Zealots is all about the practical aspects of Agile not some theoretical set of processes. I can’t think of any article that doesn’t list the benefits of what they are advocating, but I see a lot of projects not adopting, adapting and changing. Most of those teams that don’t change think they are becoming more agile when they aren’t.
But its OK, because if you don’t change someone else will. When the guys that do it eat your lunch you won’t even know what hit you. So good luck thinking its all good, because it makes their life a lot easier.
You (Paul) make good points. As I see it there are at least two types of Zealotry that I am thinking of.
The first being those who are debating tradeoffs in decisions. For example is it better to adhere to a strict iteration timeframe and reject or revert issues that would not be completed within the iteration, or is it better to identify the highest priority items and allow the iteration to extend (for this item only) it’s time to accommodate the priority? There are tradeoffs to either choice, and you may find it desirable to do both at different times.
The second type of zealotry follows the definition ‘excessive intolerance of opposing views’. In the case where you decided iterations are one month, any deviation from a one month timeframe means you are not agile, and should start over. As far as I am concerned this strict interpretation doesn’t fit an adapting process like Agile. It’s this second type of zealotry that creates problems, because it is unforgiving to those who are entering into Agile as a novice. It creates barriers and isolates ideas. To me, it’s this type of Zealotry that is completely against adaptation, and rejects incremental improvements which is fundamental to concepts like CI, Agile and Lean Development.
I have come across a few articles like this now, and the thing that always occurs to me is that I have never met any of these agile zealots. In many years of working with many organizations I have never met a single agile zealot – I have barely come across anyone who knew what agile is. Maybe Im in the wrong city.