Agile Development Doesn’t Work
Agile Development Doesn’t Work
- Q:
- How to build great software?
- A:
- Build a great team, and have them build it for you.
Dave Rooney, in one of his blog posts last year wrote “Waterfall Works“. Somewhat tongue-in-cheek, he made a useful point. The waterfall style of development actually did, and continues to, deliver some projects successfully. Agile also delivers some projects successfully. Even in the absence of any particular style of development, some projects have been and continue to be delivered successfully. What conclusions can we draw from this observation? That projects are the common denominator for success? I don’t think so. So what is the common denominator for successful delivery of great software products?
People.
Engaged, committed people.
People that really want to make a difference.
“Never doubt that a small group of committed people can change the world. Indeed, it is the only thing that ever has.”
~ Margaret Mead
If you buy into this, then everything else pales into insignificance. Agile doesn’t matter, Waterfall doesn’t matter, processes in general don’t matter. People will find their own way. Some of those people will like Agile, and use it. Their success will come from the sweat of their brows and their commitment to making things work.
Actually, Agile started out from this premise. Software folks, distressed by the continual dilution of their energy, commitment and talents caused by dysfunctional ways of working, dysfunctional management, dysfunctional clients, etc. took matters into their own hands and “uncovered better ways“. Somewhere along the way since, this premise was lost.
So, why do we continue the specious and pointless arguments about which method, approach, style, is better? If we are going to argue (and I can’t see that ending anytime soon) then how about we start talking about how to get the best out of people? (By which, I mean, “how to arrange circumstances such that people can come together and discover what fulfilment means to each of them personally?”. About how best to organise and arrange the work such that, as Herzberg demands, we ensure that “people have good jobs to do”?
How about we stop studying processes, methods and tools, and rather study theories of motivation, engagement, sociology and psychology instead?
And how about we come together to explore these issues? Because I’m certain about at least one thing. Imposing yet another management fad on long-suffering workers is definitely not the way to go.
– Bob
Think Different
Hi Siddharta,
Thanks for contributing to the conversation.
I take issue with your assertion that “People are a big focus of Agile methods”. In principle, yes. That’s where the Agile Manifesto and its principles came from. But in practice, these days, most organisations adopting Agile do not grok this.
And of course people and process can go together. If the people see a value in “process”, then they will have it. Do you grok the motivational issues inherent in “process” imposed from outside?
– Bob
Well, you asked:
If we are going to argue (and I can’t see that ending anytime soon) then should we not be arguing about how to get the best out of people? How best to organise and arrange the work such that, as Herzberg demands, we ensure that “people have good jobs to do”?
—
If you ask me, I think all of the above are very popular topics in agile conferences and mailing lists. Culture, motivation, behaviour etc.. So much so, that its in fact quite repetitive.
As for organisations not adopting those parts, that’s a different story altogether. Changing large organisations on a dime is a very rare occurance.
It’s the new companies, who have no baggage, who will adopt it first, then continue it when they become big. And as the old companies die out, the industry will change. Thats the way change will happen, not by preaching to large orgs about why they should change their mindset.
Hi Thom,
Thanks for contributing to the conversation.
By “we” here I am talking about folks that are interested in the effectiveness of organisations as a whole. Whereas I’d love for devs and other teams’ members to concern themselves with these wider issues, I don’t think we’re quite there yet. So I’m making a plea for folks looking at organisational effectiveness (cf Rightshifting) to quit obsessing about processes methods and tools, and start(?) obsessing about motivation. An organisation aligned to motivational effectiveness – as is necessary for knowledge-work organisations – looks, feels and thinks VERY differently to traditional organisations. cf “Synergistic” vs “Analytic” mindsets, respectively.
– Bob
Hi Bob,
I don’t feel like you’ve addressed my point. By drawing a false dichotomy between “devs and other teams’ members” and “folks that are interested in the effectiveness of organisations as a whole” and implicitly putting me in the first bucket you’ve avoided noticing _my_ plea for balance.
Surely focussing on “motivational effectiveness” to the exclusion of understanding the impact of process, methods, tools is an equally absurd position to the current (strawman) status quo you are attacking?
T.
Thom,
If you’re simply looking for an argument, then you won’t find it here. Happy to accept you’re right in all particulars. You win! Yayyy.
– Bob
Hi Chris,
Thanks for contributing to the conversation.
Never met any degree’d Managers. Must be some, though, right?
– Bob
You’ve met one now 🙂
Terrific post. What first excited me reading about Agile (from the outside looking in, unfortunately!) was the focus on people, it seemed socially aware, in my more optimistic moods I’d almost say it cared! What depresses me a little today is how it seems to be getting adopted as the latest way to control, as if for some the terminology/process has changed, but the name of the game remains the same.
Hi Phil,
Thanks for contributing to the conversation.
Some folks suggest we should let the command-and-control dinosaur organisations simply die out, as they are unredeemable. I reject this, not least out of respect for the many many folks still bound “before the mast”. Should we just write them off and abandon them to their fate? For me, that would be unconscionable.
– Bob
Hi Kris,
Thanks for contributing to the conversation.
Excellent point about what does is mean to “get the best out of people”. At least I didn’t write “get the most out of people”. Phew. I’ve just edited that paragraph so as to to make it clearer – hopefully.
I subconsciously had in mind Familiar’s Purpose: “Allowing people to come together to discover what fulfilment means to each of them personally”. I accept the phrase I actually used could easily be misconstrued as potentially exploitative, in the way you describe. And yes, far too infrequently have I seen/heard folks engage in dialogue about the purpose of work, in general, and its place in society and the human condition. BTW Have you read Prof Seligman’s “Flourish” #book #recommended – and my related blog post “PERMA and the positive business”? /2011/11/05/perma-and-the-positive-business/
– Bob
I haven’t got round to reading Flourish in full yet (on my book shelf), just bits that piqued my interest in the contents, though I have already read Seligman’s previous book, seen the videos of talks around PERMA, etc, etc. Positive Psychology is one topic that I’m very interested in.
I hadn’t seen your blog post you mentioned, but after reading I have to concur strongly with your sentiments there as well. 😉
You’re absolutely right. It is about people. Great people can do great things despite the insanity around them. Not so great people need help. Now it gets complicated.
Some people like little or no structure and discipline. They know what they need to do and want the freedom to just do it. Other people like lots (and lots) of process, procedures and rules so they know exactly what they need to do and how they need to do it.
If you have both extremes of people on your team, you’re in trouble. You’ll never satisfy both no matter what software development approach you use. Each team must find a middle ground where everyone get something that matters to them and sacrifices something for the benefit of the team. In my opinion, agile approaches handle these situations far better than command-and-control approaches.
Ultimately, agile and waterfall are just labels. The terms make it easier for us to establish context and debate ideas. This is a good debate. Thanks for sharing your ideas!
Agile is exactly that: stepping out of the way of bright people and let them do their magic. Nothing more, nothing less. The fact that most teams claiming to be “agile” try to implement it as yet another process to throw between the feet of bright people is indeed very sad.
Hi Bob,
The title of your posts reminds me of a couple of comments on a post that I published about 4 years ago on PM Hut (you can find it here). Mainly, both comments claim that Agile projects never get done because of the constant changing requirements.
Pingback: Is ‘Agile’ important? | Digital by Default
Hey Bob, I totally agree – with modifications 😉 I think that “Agile Techniques” / “Human-centric Empowerment Techniques” do make a difference, even in a waterfall environment. I’m not saying they’ll change the world, but they can make people feel and perform better…
Any human activity requires some level of competence to be performed with some success. Any form of management or process that prevents people from doing their work or gain proficiency (a higher level of competence) will render these people ineffective.
So if to some group following the rules of Scrum (as an example) is overly important, they become slaves to the process and will deliver nothing. They lost focus.
Advancements in software development require better education in software development itself. The software craftsmanship movement is important for that reason.
You are right about the motivation. People need to have a reason to get better at the trade/craft.
Pingback: LL: Understanding Agile | Training Agile Teams
Pingback: Agile Isn’t Everything and Everything Isn’t Agile – Paul Taylor