Developers and Change – Scare Tactics?

Upon reading an interesting post by Chris Spagnuolo on “Doing one thing every day that scares you,” we had a revelation. What does that look like pragmatically for a development team that is struggling with their releases or workflow or even struggling to get to a more agile development environment?

One of Chris’ mentors, Alan Atlas told him that the definition of insanity was to do the same thing over and over again and expecting different results. If we remember correctly, Mr. Atlas was quoting Rita Mae Brown in her book Sudden Death in 1983. Often it is said that Albert Einstein was the originator of this quote, but there seems to be little evidence that this is true.

Regardless, we took this to heart and wondered what it would look like to literally do something that “scares us” every day. (Based on Eleanor Roosevelt‘s quote: “Do something every day that scares you“).

So here’ the scenario: You have a struggling team trying to meet their deadlines. Who knows what the reason could be. Estimation issues? Product Owner input issues? Team member communication issues? Management value issues? Scope issues? Tool issues? Process issues? Design issues? Technical debt issues? Consultant or coach issues? Holy cow! It could be any of those!

So how would you scare your development team?

Here are four ways we’ve thought of:

  1. Convince the Product Owner to take a full day or two days to do nothing but sit with the team and answer their questions (Holy smokes, a fully involved PO???).
  2. Completely (and we mean completely) remove any outside distractions for an entire week and give your development team five (5) full days of heads down coding time with morning and afternoon 15 minute stand-ups to discuss the days work.
  3. Spend 10 minutes with each developer asking them directly what they need, hardware-wise, and tell them you’ll buy it (and follow through with buying it)! *See article by Jared Richardson on buying hardware for your dev team here.
  4. Allow the developers to come in for a week according to their personal sleep schedule with no issues or complaints from management. See how that works for your team and allow them to work it out between themselves if there are resource dependencies on each other. (We’ve worked with developers who enjoy the mornings… and some who enjoy coming in at lunch time…)

I asked some of my developers this a couple days ago. They agree! What would this do for your developers productivity?

Have any others? Comment below and let us know how you would scare your development team into productivity!


3 Replies to “Developers and Change – Scare Tactics?”

  1. Exactly how is removing all interference and non-technical people trying to make decisions from a team (which likely and usually knows how they work better) going to scare them ? By showing them how it should be for a week, then taking it away and going back to over head and bureaucracy ?

    The only people this is going to scare isn’t the dev team, it’s the people who are focused on control and being “in charge” opposed to results.

    You should watch Ban the Boss.

    Building vBulletin 3, we had no such negative influences or constraints and succeeded very well.

    The vast majority of developers know what and how to do things, it’s just the mindset of typical management that agile panders to, it’s has less to do with project success.

    I suggest reading :

Leave a Reply