Good Agile /Bad Agile
I have recently been getting a growing amount of traffic to my site from an excellent blog entitled “Stevey’s Blog Rants”.
I have also received mail from my readers recommending that I mention a particular post of Steve’s entitled “Good Agile Bad Agile”.
Despite the fact that this post is a little dated it is one of the most commented Agile posts on the net because of its open an frank discussion about the potential deficiencies of Agile. If anyone who interested in reading this warts and all discussion about the new Agile religion, then look no further. Its a very well written post casting doubt on Agile as a silver bullet development methodology /framework.
The post has tons of comments which make very interesting reading and is a must for anyone interested in getting to the bottom of what Agile and SCRUM is really about and how in the real world to motivate development teams. One comment added to Steve’s post which really struck home was one written by Clark Stanley where he discusses where the real answers are to are found in the quest to deliver successful projects :-
A successful software methodology (not new, others have suggested it):
(1) Hire really smart people
(2) Set some basic direction /goals
(3) Get the hell out of the way
In addition to the steps about, there’s another key: RETENTION. This is basically the “secret sauce” over at Google and a number of places. They’ve figured out that the above works, and everything else about how Google works revolves around RETENTION and ATTRACTION of talent. All the food, money, etc is to make it attractive to the top performers to stick around.
How do you make developers want to work for you? Make them believe the things they hate most don’t exist in your environment. I haven’t worked at Google, and don’t have any inside knowledge, but I do know it’s a publicity traded company, and at the end of the day they want to make a profit and make the shareholders happy. Do I believe they truly don’t have deadlines? No, I don’t. They don’t have deadlines they tell developers about, but I bet they have an idea of how long they’ll let a project go along before they kill it off. I also bet while it may be true that you can swap teams along before they kill it off. I also bet while it may be true that you can swap teams every other day if you want it won’t serve you well when it comes to bonus time.
Bottom line, they’ve figured out above 3 steps, and then built an internal economy that ensures:
- Bad projects die, and good projects complete
- Bad developers leave, and good ones never ever ever leave
I’d love for someone at Google to weigh in on this with internal insights. I can say the two things I’ve seen absolutely kill performance on teams is:
- Bad projects that just don’t get killed. A company that keeps beating its head against the wall just because they don’t “quit”. Stupid, insane, and bad business. Worst of all the good developers smell out these failures waiting to happen and get frustrated beyond all hell when the project keeps running like the Energizer Bunny.
- Mediocre or bad developers lingering along because a company is unwilling unable, or just completely clueless about performance management. Nothing will drive a project straight to hell faster than some below average performers. Not only do they drag down the project but they drive the top folks out of the organization faster than anything. Sure, there are some people who “like” being the biggest fish in a very small pond, but most top performers like to be around other top performers.
Combine the above two and you have a recipe the ensures you’ll be looking for a silver bullet in any methodology anyone can come up with. Problem is the only thing that really works is to solve the real problems. This leads me to one-word silver bullet software methodology.
All I wish is that I had written this myself. Never a truer ward spoken
This entry has been viewed 1404 times.