Constituencies and Concerns, Reactions and Aspirations in Developing a Software System - Rev 0.5
This is a “talk with exercises”, “questioning agile” in terms of the constituencies involved in developing significant systems, their diverse concerns, and the reactions & aspirations that follow from having their concerns met, or not. Framing “Agile” or methods and tools in general this way, what can we learn? Questions like:
- If “waterfall” is bad, yet “waterfall” persists, why is that? Do we really have that many masochists in the world, or does it maybe appeal to a need?
- What the heck is the attraction of a PERT Chart? Of having a CCB?
- Why is it so often that the QA people & practices are labeled as “not getting it” about “Agile”.
- Automated unit testing is a Beautiful Thing(tm), and an even harder sell to non-programmers than to programmers? Why is that?
Key ideas: There’s a simple frame of thought that accounts for the invention of methods and tools in developing software, “Agile” and otherwise, that the people involved are trying to get what they want from the hideous cost, risk and disruption of making software. - All significant software systems have multiple constituencies, with unique concerns & etc. that overlap perhaps only by involving the system being built. - Any technique, tool or policy is invented or adopted to take care of somebody’s problem, but might not be so good for somebody else.
Since I’m not an authority on what “Agile” is (That’s a rant for another time.) the presentation will be stories of techniques - “Agile” and otherwise - used in practice, exploring consequences for different constituencies. Examples will be sought from the group, with several opportunities for group work by the attendees interwoven, thus a presentation of type “Other.” Some stories will be selected from from the “Agile” literature, looking for constituencies under or over-served by the position or tool.
“Agile” practitioners might come away with a better understanding of the “resistance” they sometimes encounter, and possibly some additional tools for working with other groups while developing software. - Concerns, reactions and aspirations from all perspectives are valid - simply because someone involved with the system has them. - Seemingly nonsensical behaviors of others are rooted in some kind of “sense” from their perspective. Indeed, they may be right.
This is a “talk with exercises” - switching between exposition and exercises for everyone there.
Introduction - Anybody ever had to deal with ‘those people” who “Just Don’t Get It(tm)?” My story of recovering Router-co, taking a rigid mess “Agile.”
Exercise - Small groups, tell each other your stories of changing how you do things, or of having change inflicted on you. Each group pick one to tell the rest of us.
Brief-out - Let’s note sticking points & constituencies in the stories.
Talk - “Constituencies & Concerns, Reactions & Aspirations.” A couple stories of working with constituencies & etc. - half and half from my experience & pulled from the “Agile” literature. (Example - Clarke Ching’s story of working with a QA organization to the benefit of all by understanding their agenda vs. dismissing them out of hand.) Work through a couple sticking points (“The CCB is an impediment sent by the devil.’) to demonstrate using this POV to illuminate others’ concerns and suggest ways of working with them.
Exercise - Back to the groups, look at the story you picked in these terms. Come up with some ways to satisfy everyone.
Brief-out - What happened?
Talk - How do specific “Agile” techniques serve all of the constituencies we’ve encountered? Open to a round-table, while fleshing out a list of constituencies & etc. noting ways to adapt the techniques that have come up to their concerns. Finish - “Here’s a paper / article to go with what we just did, which you can read any time.”