I've been having some trainings on agility and software development, at an european Big Corp™ (where I work).
Here at european Big Corp™, management is worried that our size is making us slow, and they also want to be cool like the start-up kids in the valley. As such, we've been using/trying to use Agile, but with very limited success. Big Corp™'s solution to this obviously low success is to buy thousands and thousands of Euros worth of training, with Agile and Scrum certified trainers and partners, which - every single time - repeat ad nauseam the same doctrine and dogmas, much like liturgy in a church. A few examples:
* "So your colleagues are over-estimating every single task - pardon me, user story! - to have time to browse reddit? Estimate with story points, they'll see that their velocity is slow.";
* "So your colleagues don't like resolving bugs? Put a bug chart in the office where everyone can see it, they'll feel guilty and solve them!";
* "So your colleagues don't like to create tests and write half-assed code, totally ignoring definitions of done and the like? Just wait until velocity drops because of technical debt, they'll understand and learn!".
Well, what's my point here? Agile may require "safety" and all the technical goodies described in this article, but - before that - it requires a team of committed people. This is the basis of Agile and Scrum. And that's where my company fails, and that's why Agile - or any other approach - won't work here until people are responsible and committed. The build is now broken, will a team of uncommitted people will care? They'll push around the responsibility until someone fixes it.
So, yeah, Agile requires safety; but, before that, it requires commitment. I feel it's an engineering-type trait, to try to solve human issues with tools (bug charts, code coverage, continuous integration/delivery), and many engineering-driven companies seem to play the game that way. But all these tools won't solve the real problems which explain why a team might be failing. And if a team is committed, they'll eventually succeed, even without the shiny tools and cool approaches.
> So, yeah, Agile requires safety; but, before that, it requires commitment.
Completely agreed. There are certainly tools and processes that are more effective than others (as I discussed in the post), but for a creative discipline like programming, no process or tool will be effective unless the creators (the programmers) buy into it. That reminds me of a quote from Peopleware:
> The maddening thing about most of our organizations is that they are only as good as the people who staff them. Wouldn't it be nice if we could get around that natural limit, and have good organizations even though they were staffed by mediocre or incompetent people? Nothing could be easier—all we need is (trumpet fanfare, please) a Methodology.
Tellingly, the "high discipline methodologies"[1] page on c2 was kicked off by listing XP and the Personal Software Process.
(You can create systems for enabling median folk to accomplish things, even if they are disinterested. We call it "bureaucracy", and it sucks, but a lot of the time it kinda-sorta works. A bit.)
Anyway, as usual: you need good people, good process and good tools.
None of these are substitutable for the others, despite what methodologists, tool vendors and various worthies might tell you.
> (You can create systems for enabling median folk to accomplish things, even if they are disinterested. We call it "bureaucracy", and it sucks, but a lot of the time it kinda-sorta works. A bit.)
Yeah, it's true. And the kinda-sorta might be just enough to some companies (which are too big to fail and have enough leverage to push mediocre stuff to the market).
On a side note, I've been feeling, lately (and within the context of all this Agile BS my company tries to indoctrinate me with), that management is really the art of accomplishing stuff without making large assumptions about your resources (in software, without assuming any kind of talent, commitment or responsibility from the team). And, although it seems horrible to me, there's really a lot of knowledge and value in achieving things even when you only have a bunch of uncaring, undedicated and uncommitted monkeys which only care about collecting their paycheck.
"But all these tools won't solve the real problems which explain why a team might be failing. And if a team is committed, they'll eventually succeed, even without the shiny tools and cool approaches."
Commitment is the first requirement, but it doesn't guarantee the team understands or will derive an effective process in time to deliver .
Failed startups are usually an example of committed individuals that ran out of time.
I was reading your point (quite well put, actually) and thinking about how the Big Corp™ world is the exact opposite of the example you mention - failed start-ups. Big Corp™ initiatives succeed, even though - by my standards - I feel they're failing, and even though everyone is totally uncommitted.
Here at european Big Corp™, management is worried that our size is making us slow, and they also want to be cool like the start-up kids in the valley. As such, we've been using/trying to use Agile, but with very limited success. Big Corp™'s solution to this obviously low success is to buy thousands and thousands of Euros worth of training, with Agile and Scrum certified trainers and partners, which - every single time - repeat ad nauseam the same doctrine and dogmas, much like liturgy in a church. A few examples:
* "So your colleagues are over-estimating every single task - pardon me, user story! - to have time to browse reddit? Estimate with story points, they'll see that their velocity is slow.";
* "So your colleagues don't like resolving bugs? Put a bug chart in the office where everyone can see it, they'll feel guilty and solve them!";
* "So your colleagues don't like to create tests and write half-assed code, totally ignoring definitions of done and the like? Just wait until velocity drops because of technical debt, they'll understand and learn!".
Well, what's my point here? Agile may require "safety" and all the technical goodies described in this article, but - before that - it requires a team of committed people. This is the basis of Agile and Scrum. And that's where my company fails, and that's why Agile - or any other approach - won't work here until people are responsible and committed. The build is now broken, will a team of uncommitted people will care? They'll push around the responsibility until someone fixes it.
So, yeah, Agile requires safety; but, before that, it requires commitment. I feel it's an engineering-type trait, to try to solve human issues with tools (bug charts, code coverage, continuous integration/delivery), and many engineering-driven companies seem to play the game that way. But all these tools won't solve the real problems which explain why a team might be failing. And if a team is committed, they'll eventually succeed, even without the shiny tools and cool approaches.