Ron Jeffries on the need for Technical Practice in Agile...

• I was going to write this out, which I don’t usually do with my tweet storms, and decided not to. So I have no idea where we are going.
• Topic is pressure on developers, and what they can do about it.
• It is common for developers to be put under pressure to deliver more, faster. I would say it is endemic. This pressure is invariably a bad idea. I believe it was Ward Cunningham who said that warming programmers’ feet did not make them go faster.
• The usual result of pressure is that developers invisibly turn down the quality dials, perhaps delivering raw code faster, but certainly delivering defects faster as well. 
• Adding pressure to programmers is a trick that never works.
• Now comes Agile. Agile asks us to deliver working software frequently, every couple of weeks or sooner. I believe the main value of this is that it focuses the customer-developer conversation on reality rather than fantasy, enabling more productive collaboration.
• However, to do this trick of continuously delivering working software, developers need to learn new things, things not typically taught in school and not typically learned on the ordinary non-Agile job.
• If you’re delivering continuously, your design must grow and evolve: you surely didn’t have it figured out in weeks one and two. Design evolution is done via /Refactoring/, a discipline of improving code’s design without losing functionality or breaking things.
• Refactoring is rarely, if ever, taught in schools. It takes time to get good at it. If you’re already in some incremental, iterative Agile effort, and you don’t know refactoring, your design is falling behind every day.
• Since refactoring needs not to break things, and since the design may need improvement anywhere, a comprehensive suite of tests is a necessary — if not sufficient — safety net for refactoring.
• This, too, must be done incrementally. We call this TDD and ATDD among other names.
• I could go on. The point is that to perform well in an Agile frequent-delivery situation, developers need to know a suite of capabilities that they’ll not have learned in school and that they’ll not have learned in pre-Agile situations.
• Most developers do not know these things at all. They’ve had no opportunity to learn them. That’s just the way of things.
• So here come old Agile, he come groovin up slowly, he got expectations he one holy terror ...
• He say “Come together, right now, and code for me”.
• And they don’t know how. They simply can’t do it. So old Agile, he’s pretty new to the game, what does he do? He reverts to what he knows, and puts pressure on the team.
• It says right here in the Agile playbook that the team /will/ deliver working software every week or two. Will, do you hear me? Read my lips, get me that working software or I’ll know the reason why.
• Yeah, well, we do know the reason why: they don’t know how.
• Does this happen every time? Of course not. Nothing interesting happens all the time. But it happens often, too often. And it’s good for no one.
• It’s not good for the project: it goes slower than it might, and then slower still.
• It’s not good for “Agile”: it doesn’t deliver what Agile promises, reducing Agile’s ability to do good things.
• It’s certainly not good for developers: it puts them under more pressure than before Agile.
• To me, there’s only one way out of this loop, and that is for developers to somehow learn the things they need to know. Ideally, companies would help them. Ideally, organizations like the Scrum Alliance would help them.
• Ideally, people would live in peace and harmony.
• Ideally seems not to happen as often as it might.
• Still, the only way out that I see is for developers to learn these skills. They may have to do it largely on their own. There are materials out there, often pretty affordable. We need to help them find those.
• It would be good if there were more support for the creation of those materials, a consortium or something, some group to fund the creation of what’s needed. 
• It wouldn’t be just charity, not at all. Why not?
• There are around a million Scrum Masters in the world. That suggest that there must be about five million developers who need this information. Ten bucks a month from five million people is enough money to go around between creators and backers
• I don’t know how to make that happen. I’m quite sure it’s needed.
• Agile cannot thrive without technical practice. Developers mostly don’t know the practices. For Agile to thrive, we need to help developers learn what they need to know.