Sorry to say it guys, but Agile has gone limp over the last few years. As we get more and more coaches into the mix, both external as well as internal, organizations somehow have forgotten that it’s software that we’re trying to produce. Not great stand-ups.

Technical practices matter. In fact, if we could dispense with ALL process and still create the valuable quality software that is needed, we should do that. From a Lean perspective, process adds no customer facing value. But getting rid of all process is crazy talk. Even Fred George, who promoted “Programmer Anarchy” several years ago never got away from all process. In reality, his movement was premised on driving business decision making directly into technical decision making, and completely empowering teams to “be” the company. He premised the concept of “Programmer Anarchy” on using the best and brightest developers out there, and trusting that if they could do something as difficult as create great code that they could do the business decision making as well.

But perhaps we don’t have the absolute best talent out there. Perhaps it’s hard to lure people away from Google and Facebook because of the money and the chance to get great work environment and unbelievable work challenges (change the world, anyone?) Does that mean that we have to go back into the Fredrick Winslow Taylor world view of “The One Best Way”? With that way becoming making a choice between Scrum, SAFe, Lean/Kanban, and other development processes?

I’d like to convince you that what’s going to work for your organization and your employees is something in the middle. I, of course, lean into the “better technical practices will yield better outcomes” frame of mind. You may as well. But when Garrison Keillor said, on “A Prairie Home Companion” (a long running radio show on National Public Radio in the States), “Well, that's the news from Lake Wobegon, where all the women are strong, all the men are good looking, and all the children are above average”, that was satire! And the same is true of your organization. It can't logically be true that all organizations’ developers are all above average. But we can hold people to an acceptable level of technical practices that will yield in writing better code than merely having a process that talks about writing better code.

This session will speak to the specifics of the whats and whys.

 
1 favorite thumb_down thumb_up 4 comments visibility_off  Remove from Watchlist visibility  Add to Watchlist
 

Outline/structure of the Session

This is a straightforward talk that has a very simple premise.  The only artifact that really matters, the one artifact that uniquely adds customer value over anything else,  from all of the many artifacts that we create as an organization trying to become more Agile is the code that we create.  And no matter how wonderful our process is, without that code artifact, nothing else really matters at all.

This will lead us down the road of paying more attention to the technical practices of the delivery teams and helping them turn product ideas into code and cash.

We will examine the effects of being honest with ourselves as to where our delivery team capabilities are currently and suggest the best avenues to pursue for teams of different skill levels.

Learning Outcome

  • technical practices matter - more than any other factor in predicting project success
  • given the choice between great process versus great technical practices, the practices have to win every time
  • "You Go To War With The Army You Have - Not The Army You Might Want Or Wish To Have At A Later Time" and how to deal with that

Target Audience

Delivery team members, delivery team stakeholders (POs, SMs, etc), management, and executive management

schedule Submitted 8 months ago

Comments Subscribe to Comments

comment Comment on this Proposal
  • Joel Tosi
    By Joel Tosi  ~  7 months ago
    reply Reply

    Hi Howard,

       I wanted to give some time before I came back to review this session so I had a more fair frame of mind ;)

     

    My gut is I like the intent - weak code / irresponsible engineering makes it difficult to learn and pivot a product.  

     

    However - your submission wanders a bit.  The abstract could clean up quite a bit without the Fred George, Google, Lake threads.  If we were to print this, you would have to get to the point faster. 

     

    I'm also concerned that you are potentially focusing on the code being more important than the product and how weak code inhibits your ability to learn.  Your first bullet point around technical practices being the most important thing is concerning - is having no idea how to validate a product ok if the tech chops are solid?

     

    Perhaps you are playing devil's advocate - in which case I am intrigued but would need to see more of where you are going with this to make a decision.

     

    Thoughts?

    Best,

    Joel

    • Howard Deiner
      By Howard Deiner  ~  6 months ago
      reply Reply

      Hi Joel!  

      [sorry I'm late in responding - I'm recuperating from medical thing]

      I've thought long and hard over the comments and my frame of mind as I wrote this submission.  I believe that hidden in a small inconspicuous statement is actually where all of this comes from.

      "But perhaps we don’t have the absolute best talent out there."  The vast majority of today's IT marketplace is in this boat.  In fact, I think that today's IT workers may well have a lot in common with the blue collar assembly line workers of 60-70 years ago in the US.  They are pretty highly skilled, fairly well paid, but vulnerable on any number of social and political dimensions.  I think that could be an interesting book, but realize that is the background I feel deep down.  BTW, I don't look down on these people, and I don't despise them.  But they are not the people that are staffing Google and Microsoft Research.  IT implies large enterprise organizations.  Most of my consulting is with these sorts of businesses.  Things like Standard Operating Procedures didn't die with "Agile Transformations" - they simply got labelled something "more acceptable" for the troves of agile scaling consultants.  But I'm not going down that road now.

      I don't feel that I can avoid the issues and processes around large scale transformations.  And, even if I could, I don't think that the workers would necessarily be able to constructively be able to get the work of the organization done.  What I'm looking at is trying to get those "blue collar assembly line workers of 60-70 years ago in the US" to recognize that 30-40 years ago, jobs in areas such as automotive went away because of quality and lackadaisicalness.  People have to understand that no process, no matter how well intentioned and/or well executed, will solve technical problems.  And people must understand that all process, not matter how well intentioned and/or well executed, is a drag against the solutions needed by the business to move forward.

      I hope that gives you some insight.  This is not about a small team (a true Lencioni team) operating in a true product driven fashion (Lean Startup learning on product "whats" preceding or at least concurrent with engineering "hows").  I love those small extremely capable teams.  But they don't seem to be very common with the people I consult with. 

      Does that help?

      --  howard

  • Joel Tosi
    By Joel Tosi  ~  7 months ago
    reply Reply

    Hi Howard,

       I slept on this a bit so please don't think this is a gut reaction.  I highly suggest consider removing the Black Lives Matter comment or be ready to support that pretty substantially.  In general, I would recommend not using a heavy topic lightly.  If that is truly necessary for your talk, then you would probably want to move that forward and wrap your session around it.

     

    Best,

    Joel

    • Howard Deiner
      By Howard Deiner  ~  7 months ago
      reply Reply

      Hi Joel!

       

      I agree with you.  In fact, I don't remember why I would have placed that in there.  It doesn't make sense!  I didn't mean to trivialize the politics around that, and I apologize for my stream of consciousness in that.  To be honest, I don't even know how I would tie that in to the talk. 

       

      Again, please accept my sincerest apologies.

       

      --  howard