Know an Obscure Agile Voice?

Looking for 100 Agile Voices…

That was the first half of the headline Tuesday.  There was more to it.

Mark Levison is looking for “lesser known” agile voices. More obscure bloggers, authors, etc. Not the ones you’ll already find on someone else’s “Top 100” list.  As Mark headlined it,

…voices we should hear more from

Hmmm… Sounds a bit like that new NBC TV show, The Voice, doesn’t it?

Mark wants your nominations.  Maybe you can help…

Dateline April 24, 2012.  Mark Levison (Agile Pain Relief) wrote:

“In the past few years a number of Agile people I respect have published top 100 or even top 200 lists. While I like many others appreciate the attention they’ve brought the whole idea seems very anti-agile. Agile promotes a democratic meritocracy. These lists do the opposite…”

There’s a great suggestion tucked into the middle of the post:

“Instead I think we should be widely read in the Agile community often reaching outside our immediate realm.”

But then, I had to scratch my head at the next point:

“To that end I’m asking for your help creating a list of voices we should hear more from. My goal is find ~100…

Wait, won’t that new list just add another 100 names to hero or guru status? Maybe. On the other hand, a “democratic meritocracy” would seem to welcome nominations and electorates. So, let’s hear from you…

Go read Mark’s full article and see if you can help with the nominations. Or comment. Or put your blog in there… and then get it rejected…

I think it’s a great idea to recognize others who have influenced us. What do you think?

Cheers! 😉

11 Replies to “Know an Obscure Agile Voice?”

  1. Ken – thanks for the post. I suspect that we will not create 100 new guru’s. My goal is to democratize our learning to the point we never want new guru’s again. I made ~100 the limit because it allows a wide range of voices to be heard without being insanely time consuming. If a few others take on a task like this we should come up with a large collective list.


  2. The Agile community is too insular and narcissitic already, and they spend a lot of time navel gazing and reciprocal linking each other.

    Although self congratulation is always a popular agile past time, perhaps they should spend time looking at non-agile bloggers for fresh ideas.

    Meantime I can think of 5 or 6 agile voices I think we should hear a lot less from…. (and no I’m not thinking of Mark in terms of that list..)


    1. Hi Jordan! I enjoy your counterpoint. Keep on speaking up. It is refreshing.

      Sorry I didn’t catch your April 1st article until just this morning. I was overcome by some crunch or another. You got me thinking… about sprint-upon-sprint…I have to wonder whether we might need to build in some “recovery” time for sustainable individual performance. Time to think. (Time to plan?) IMO: We can’t really expect to run a “marathon” by doing back-to-back “sprints” can we? Could we organize the equivalent of a “relay race” and rotate our team members instead? Maybe we could rotate ourselves through training, research, or cross-functional outreach cycles in between on-task sprint duty cycles?

      Did you catch Andrew Fuqua’s post (after Thanksgiving) about being the “Slack” for your team? That one was very inspiring! But if I didn’t know Andrew, and I didn’t have some slack time right after Thanksgiving, I might have missed that one too. ((sigh))

      Now I just noticed, Andrew put up a really great-looking post on the Retrospective Prime Directive, etc. I’ll have to read that one tonight. Meanwhile…gotta run…

      Thanks again for your counterpoint, Jordan. You got me un-group thinking this morning! I find it refreshing to entertain a counterpoint. Sometimes I’m persuaded. Sometimes not. Either way, I’m challenged and renewed. So, please do press ON! (Time for me to press “Submit”…)


      1. Thanks 🙂 Well, hrrm, in my April post I don’t think I got directly into the sprint burnout thing…

        I think sprint burnout is a big factor and something people notice right away, or at least within months, and that’s the leading thing in kanban favor right now (it’s a face saving alternative to scrum).

        My bigger issue is with the obvious lack of cohesive architecture that occurs when building things in 2 week increments, especially with the construction being nonstop.

        That technical debt and haphazard design WILL sink the project, eventually, but that could be years down the road so there is not as much obvious knowledge of that, compared to, say, sprint burnout.

        So… if Waterfall is the deification of long term planning, and Agile is the deification of short term tactical value production…I’d like to see something in the middle.

        Eg, “set all the dials to ‘5’”…


        1. Ya know… Building things in 2 week increments doesn’t have to preclude an architecture. (sly wink!) In fact… (whispering) I have already coached more than one project where the team *did* have an architecture sketched out. For incremental implementation (aka “sprint”) planning, they selected prioritized feature sets and “thin sliced” each feature down through the layers and implemented just enough of whatever was still missing at each layer to support those features. Guess what? It worked!

          1. PS: Was I surprised? No, not at all. Well over a dozen years ago (mid to late 1990’s for example) the practice of “Feature Driven Development” (FDD) encouraged the lightweight use of just enough problem domain modeling to understand the context and solution. Features, like user stories, were phrased in business-speak and could be given a business value.

            Agile modeling, accomplished quickly with sticky notes, in close collaboration with the product owners and subject matter experts, typically amounted to no more than a few percent of the total development time.


          2. For how long tho? Show me the code base in 10 years I guess.

            I’m not doubting that that can be successful, I’m just saying, systems that I’ve seen that have evolved like that….get to a point…say 5 years into it.. That it should be completely rewritten.

            Much has been learned since then, and the old architecure-lets probably don’t cut it anymore.

            Then what needs is a deep architectural rethink; breaking things up into web services, distributing the system, getting more into loose coupling, and then rebuilding something new.

            At that point, I really think a sensible waterfall is the best approach.

            What I actually see happen tho is people keeping hacking away at the 5 year old code base, living within it’s limitations, until it turns into a 10 year old code base. What happens then?

            Then it’s even harder to do the total rewrite that the system needs and even harder to get the buy in…

            It’s the long term implications of visualizing every problem as a nail that can be hammered in just in time fashion as really an achilles heel.

            Responding to change is usually the excuse given, but how responsive to change can the team be when the system is moribund by decisions that were made years ago looking 2 weeks out?

            I really think that for little projects, sure, go agile. For something serious, a media distribution system, a large enterprise app, that another approach is called for.

            I just don’t see the tools in the agile toolkit to solve those problems…but I see them in the waterfall toolkit.


  3. Hey there Karol, thanks for the short! Just “thinking out loud” and learning together with others. I enjoy the dialog and learning from each other. I appreciate your voice, too!

    So, yes, we’ll all “Press ON!” together.

Leave a Reply