2018 Goal: Less Agile and Scrum Talk
Hello, and welcome to Scrum Tawk, I’m your host John…
One of my goals for 2018 is to spend less time trying to unravel #agile and #scrum. Disambiguation is a rabbit hole and the words way too mushy. I spent a ton of time in 2017 rehashing various debates. I strongly doubt I was adding anything meaningful to the body of knowledge, so my guess is that my time (and your time) is better spent elsewhere.
So with that, I’m going to be downplaying the Agile and Scrum talk. Here’s why…
First, it is boring and repetitive…
- Mentioning Agile rarely moves the conversation forward, especially with folks outside of the Agile-nerd bubble.
- Any Google search yields the fact that many of the debates on Agile and Scrum are almost a decade old. They’re not getting resolved…the confusion lingers. I’d argue they are getting worse as “Agile” gets older, gets marketed/sold, and becomes the default. The likelihood that I am going to unravel any of this confusion is very low. Some helpful souls have reached out to let me know that they were having the same debates with the same people 6+ years ago.
- At least for me, Agile encompasses a number of valuable patterns, practices, and perspectives. It also comes with a good deal of baggage — almost no one I work with is encountering Agile for the first time. The high performing teams I’ve worked with pick liberally from a whole range of patterns (many outside of the Agile umbrella), so I find it more helpful to jump straight to the full corpus of patterns. Coincidently, these teams rarely say they’re “doing Agile” or “doing Scrum”.
- I span tribes, but at heart I am a “product person” (UX, product management, etc.) and a diehard systems thinker type. Recent Twitter rants from various Agile-folk have persuaded me that Agile (as it exists today) is primarily for “software development”, with a strong history of being for “software project development”. Though there are many calls for “the business” and “the team” to work together, I sense an implicit (and sometime explicit) boundary. The Product Manager is expected to have the answers, and the team dutifully delivers usable/tested stuff. I prefer taking a broader, more holistic view.
- Friends of mine from the product/UX community have put a ton of energy into figuring out how to “plug” best practices from those communities into Agile practices. Again, I think this underscores a bias towards Agile as the “way software developers do their thing”, and puts the other areas of expertise on the back foot trying to learn how to “play” Agile. The Agile community has embraced me (and others) from the product world— “we really need great POs” — but personally it doesn’t feel like the gist. Again, I’ve always imagined there to be a more overarching “way” that combines product, UX, org-design, support, Ops, etc. My worry is that boundaries fuel the Feature Factory and output-centricity.
- About a year ago I ran into Joshua Kerievsky and Modern Agile. When I need a “generative” snapshot of Agile (something that captures the gist, and can generate/filter appropriate “ways”), I fall back on Modern Agile as it is purposefully free of specific practices, and has applicability for the whole organization…an important characteristic given that most “problems” are not solely software development problems. I find MA to be a perfect compliment to many Lean principles/practices which take a broader systems perspective. The argument is typically “but MA doesn’t explain the how” to which I argue that we’re swimming in the how. They why is equally important, and principles like “Make safety a prerequisite” seem to deeply resonate with teams.
- Even among self-identifying “agilists” there are vastly different interpretations of what Agile is, isn’t, should be, shouldn’t be, etc. There is nothing inherently wrong with this (it is kind of cool, actually), but it makes talking about Agile very difficult.
- In a similar vein, some people identify so deeply with certain aspects of Agile — self-organization, working at a sustainable pace, “trust [teams] to get the job done” — that any discussion about the relative benefits of different practices, or the design of different “patterns”, becomes difficult due to the deep personal investment. Ardent agilists bake a lot of their personal identify into Agile. Truth be told, I am one of these. It makes it hard for ME to talk about it.
- Anything that is marketed and sold (and certified) will be tough to unravel. This is a constant with any “helpful” thing (see DevOps, for example), where there is demand to “buy it”. The dialogue around Agile is heavily influenced by the experience of teaching it for money, trying to introduce it into potentially hostile environments, and catering to the needs of people (and companies) who buy/attempt to install frameworks (at this point…later adopters).
- In my mind, Agile patterns/practices are tools used — in concert with many patterns adjacent to Agile — to achieve valuable business outcomes. As Neil Killick pointed out recently, talking about Agile too much gives the impression that “doing Agile” is the end-goal. I don’t believe that…but it is damn easy to come off that way.
- It can be impossible (for most non-methodologists operating in the real world) to decouple Agile from Scrum. Scrum is 1) controlled by two people, 2) has a perspective, 3) manifests that perspective — including various fears — in its design, and 4) is one of many valid approaches. Again, nothing wrong with this — hey, kudos to Jeff and Ken, and to rabid Scrum fans — but it makes the discussion that much harder in my world.
- The Agile community is absolutely wonderful, and I feel wonderful (and honored) to be a part of it. This is in no way a repudiation of Agile, but just an acknowledgement on my part that talking about it explicitly doesn’t help — n=1 — me much.
Hopefully Agile-folk will find the content interesting. I’ll be talking more about specific practices and less about nebulous “Agile” and way less about Scrum.