Why you should never employ a techie to solve your problems!!!
I've just read a fantastic debate on the usability of Git (or rather the lack of) and it reminds me that most technical folks I encounter are too clever for their own good and will constantly introduce complexity for the sake of it (or to keep their souls clear from the devil - users).
The problem with this is that these wannabe rocket-scientists are fundamentally too stupid to appreciate that real people may not care about the elegant layers of abstraction or powerful combinations of wacky commands that can yield amazing powers. What they want is a simple solution to the problem they have expressed. The technical folks I admire are the technical folks who can create a simple, usable solution in a format that is acceptable and digestible by the end user.
As Einstein quoted "Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction.", which indicates the technical community appears to be filled with lots of intelligent fools...
And just to illustrate this further, I would include Spring in the mix here as an (actually it's a collection of) overly complex solution(s) to a fundamentally simple problem space, which given the size of the user community indicates their are a lot of intelligent sheep...
God Mentality
My recipe for developing a God Mentality.
Ingredients:
- a team of non-agile developers
- a single zealous (or inexperienced) agile coach
Method:
- Prepare a clean team working area
- Gently introduce the agile coach to the team
- Gently stir until a process emerges
- Trust the coach
- Allow process to fester
- Praise the coach
- Serve with a slight pinch of sarcasm
Adopting agile is extremely difficult and coaching is a great way to being in the necessary skills and expertise to a team. However, coaches are not infallible and will inevitably leave their own stamp on your project. Leave a single coach on a team for long enough and they will become an almost god like figure and the team will depend more and more on their advice and wisdom (KB/C3). A good coach will be able to adapt the processes and methodologies to suit your environment, but a zealot will probably insist on adapting your environment to match the methodology. To produce a really good God Mentality it is imperative that they are unquestioned in their approach and instead followed blindly. This works particularly well with a team of inexperienced (or long serving corporate) developers.
Unfortunately, if you fail to produce the perfect God Mentality, you're probably doomed to a life of perfect agile. The moment some diversity is allowed to challenge the preaching from God #1 you are on your way to never exalting a single guru (or their processes) again...
Unfortunately, the quality of agile coaches varies remarkably and this recipe may not always produce the perfect God Mentality.
My Agile Awakening
I've considered myself to be an agile developer (albeit of the pragmatic/lazy style) since the very early days of XP and through the course of my career have had the opportunity to experiment with most of the practises and methodologies in various 'flavours', but it wasn't until I joined exoftware at the start of this year that I truly appreciated what agile truly means.
"Agile" as a term has been niggling at me for years, because it has no clear defining definition, leading to abuse where everyone can, and often does, claim to be "Agile". Similarly, methodologies are extremely quick to jump on the bandwagon and claim to be agile (this is a topic for a future rant).
It is even more frustrating when there are so many purists out there advocating methodologies under the banner of agile. I'm sorry, but this just doesn't cut the mustard, if you're doing pure XP, you're an XP shop, but that doesn't necessarily follow that you're agile. Yes, the technical practise may be extremely good, but that doesn't mean the process is...
In just a few months at exoftware I have been fortunate enough to witness how a truly agile team doesn't follow any particular methodology, but continually improves their own processes, borrowing practises and techniques from any methodology. This sits extremely comfortably with me and confirms my beliefs of what agile is (mainly gleaned from Alistair Cockburn). But the surprise wasn't that agile should be pragmatic in it's application, but that in order to improve your agile process the best techniques and practises are themselves agile.
As an example of true agile, is there any real/substantial difference between an iteration, timebox or a sprint. I'm going to be happy to call this whatever the customer wants provided we can both agree a clear definition of what it means. And rather than get into the whole what does done mean, lets choose a term that means something in the customers context. Purists will have you release to production at the end of every sprint, but this will simply never fly for many large organisations (would you really want your online banking application being updated every 2 weeks with new features that had not been rigorously tested). Similarly, will I get bogged down in ceremony about when to hold a retrospective, of course not, I'll use them whenever I feel there is an opportunity to learn or adapt. I'll apply them not only to the deliverables, but also to the process being used to deliver.
The elitism inherent with many of the methodologies (and lets not forget the software craftmanship alliance) doesn't help with agile adoption, it just makes everyone else feel inferior... Wouldn't it be great if the team that brought us the manifesto got back around the table and gave us something SMARTER (specific, measurable, acceptable, realistic, timeboxed, energising, rewarding) rather than a few open-ended, fluffy statements so clearly open to abuse...