The Quick Brown Fox

So I was reading this post on Medium, " The Trouble with Scrum ". As these things do, it started a bit of a mental chain reaction, leading to this tweet from me: I feel like Scrum is hard because communication is hard, and most of us have been, at best, not well trained. Just a quick look at the Manifesto (never mind the Scrum Guide for now) highlights this. Have a sloppy able because blogspot doesn't seem to have an easy way to make them: Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. Well, how do you know you've satisfied the customer? You have to talk to them, and get them to talk to you. Shouldn't we leave that to the experts in marketing and such? Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. That means not just communication, but constant, close communication. With CUSTOMERS. How do we even DO that?...

Working software over comprehensive documentation This line seems to me to be the least useful of the bunch, if only because it is so obvious as to seem unnecessary. Software without documentation may or may not be useful; documentation without software is always useless. This line causes technical writers a lot of angst, though, so maybe I will approach it from that perspective as a straddle the career boundary. Part of the angst seems to be rooted in a tendency for people to approach Agile stuff in a restrictive, black and white fashion. Most tech writers being in the business of providing customer-centric documentation of some kind, there's a tendency to think that Agile means getting rid of that wholesale, and I don't think that's what is actually meant. It is fairly common, though, to see "X has more value than y," morph into, "So you don't do y at all then. Good luck with that." Cue rolled eyes. This is of course a straw man; I've y...

Individuals and interactions over processes and tools. What a simple and profoundly revolutionary statement! Away with standardization, and with the idea that people are fungible "resources." Processes and tools are static things; individuals are alive, ever-changing, and their interactions cannot be predicted. We are told moreover that this focus leads to better outcomes, that people produce better things than things can produce other things. There is still a place for process and tools, but those things work best if they can be made to imitate the state of life, of constant adaptation.

We are uncovering better ways of developing software by doing it and helping others do it. What is a manifesto? Literally, it is a list, in this case a list of guidelines. What does the first line of the manifesto communicate? That the subject is not abstract, but is based in lived experience (doing it). It is pragmatic rather than hypothetical (better as opposed to best, perfect, etc.). Being rooted in experience and individual context, it will not look exactly alike to any two people.  Agile practice is subject to change and growth (uncovering is an unbounded process). I am confident that 20 other people would not have reached the same conclusions as these did, and that even if those same people were to meet again now, they might easily reach a different place.  It is rooted in the exercise of creating software. Application to other environments should be approached with caution, and should be guided by empiricism rather than attempting to fit one solution as-is...