DIB Guide: Detecting Agile BS (2018) [pdf]

What makes the state of “agile” processes in modern software development so depressing is that actual agility is worthwhile and – if anybody were actually to adhere to actual agile project management principles – achievable. However, I’ve been through at least a dozen agile “transformations” over the past 20 years or so since XP kicked off this whole trend and they all end up going like this: management hires some “agile consultants” who don’t have much (or sometimes any) actual…

The fact that this had to be produced, reviewed (probably by lawyers) and cleared for open publication is a sign that the DoD has recognized that it's wasting a lot of time and money paying teams to make things that help the DoD...and not getting it -- despite agile's promise of delivering working software to users ever iteration. The document contains and is a symptom, the root cause analysis of why this document exists should be next. Reading between the…

Great document overall! > The purpose of this document is to provide guidance to DoD program executives and acquisition professionals on how to detect software projects that are really using agile development versus those that are simply waterfall or spiral development in agile clothing (“agile-scrum-fall”). Actually doing 'waterfall' properly would probably be fine? Or at least not the bogeyman it's made out to be. The real danger is that the project would just be managed badly, independent of professed approach…

Agile Value: Individuals and interactions over processes and tools DIB Mapping: “Competence trumps process” This makes sense to me, that said: how do you commodify competence? I'm thinking about the teams I've worked with that do agile but wind up writing an objectively difficult-to-maintain codebase because they lack competency in anything that resembles best practices. I will commend the teams for shipping large products and doing agile though.