Over the past couple of years I have heard the term GSD used quite a bit as a means to describe high-performing individuals (note I did not say team). I have to admit that this is not an acronym that I was very familiar with, primarily GSD referred to my designation in college as someone who didn't want to join a fraternity, the politically correct term would be Gosh Darn Independent (And this is probably a great way to define who I have been throughout my career).
Before embarking on this post I did some quick google searches and came up with some thoughts on GSD:
- The Urban Dictionary definition:
-
GSD is brought about through severe bout of procrastination, not getting work done on a regular basis, therefore needing to set aside long amounts of time to disappear and get shit done.
-
- What Spinks Thinks - http://whatspinksthinks.com/2013/11/04/get-shit-done-the-worst-startup-culture-ever/
The term, as it is used now is, Get Shit Done, which does sound great at first pass. However when you start working with GSD as part of building a defined delivery process you start to see some very ugly things drop out of it:
- Heros - Those great people who came in and saved the day and got some serious shit done under intense pressure. Never mind that the day they were saving maybe shouldn't have happened in the first place or even worse, the situation requiring them to save the day via GSD was of their own making, convienently lost in the thrill of GSD.
- Lack of Defined work - Who cares what I am doing so long as at the end of the day I can show you how much shit I got done.
- Lack of Plans - See above.
The problem as I see it with GSD is that we aren't asking ourselves a basic question - Are we doing the right shit at the right time?
Yes getting 'shit' done is good and getting it in done makes us feel good, however if there is no real process behind your way of getting shit done then you will be destined for unpredictable delivery of the work that brings your organization the most value.
I find in my experience that GSD is more about individual glory over a team (see my blog on Teams Deliver) which I find troubling on so many levels.
Organizations spend lot's of money having their technology teams deliver features that they believe bring value to the business and even though there may be many ways of delivering this value, ie Agile, Waterfall, Lean, I have yet to see GSD making its way into main stream product and project management lexicon.
Continuing my educational tour of the world of GSD I found a posting from two guys named Daniel Epstein and Pascal Finnette who appear to be individuals who provide support, coaching and services to technology entrepreneurs specifically regarding GSD:
- GYSHIDO - A movement started a few years ago dedicated to The Art of Getting Your Shit Done. They identified that their most intrinsic value as employees was that they got shit done, but in looking at their code of honor I see elements of good process, so is it possible thatGSD has some value? Too soon to tell. But here is their code of honor:
- Relentless focus - Focus on the 10% of your activities which drive most of the value. Relentlessly.
- Boring consistency - Do the right things over and over again. Consistency forms habits. Habits make hard things effortless.
- No Bullshit - Don't bullshit yourself or others. Apply brutal honesty and transparency to everything you do.
- No Meetings - Meetings come in only two forms: Standing or social. If it's social, it's over breakfast, lunch, coffee, dinner or drinks. If not - don't sit down.
- Follow up - Don't let others wait for your part of the job. Ever.
- Don't be an Asshole
As I read through their ethics I believe (I haven't talked with these guys) that their process could align with the agile type world. Why?
- Many of the elements of what they believe is good GDS is what I consider good behavior of Agile teams:
- Focus on the work that delivers the most value - Agile, 2 week sprints, deliver production ready features continually.
- Consistency - Keep your Scrum Teams together, let them improve in estimation, execution, test automation, boring? maybe, get shit done fast? yes
- No Bullshit - Retrospectives ask us to be brutally honest when things are working and fix what doesn't work. Attack the problem not the person (see number 6 - Don't be an Asshole)
- Follow-up - In Agile I always talk about how we need to think of minutes over hours when resolving issues that are blocking us from completing our work.
Agile teams focus on identifying the valuable 'thing' that we need to deliver and then develop lightweight plans to deliver it incrementally. I suspect that GSD has its roots in waterfall SDLC where a project would roll happily along, green week after week, oblivious or ignorant to how the project was actually unfolding. Decisions made by the team that never surfaced had large impacts on scope and viability of the project.
GSD I believe emanates from the need for a project team to 'pull a rabbit' out of the hat in order to deliver the project 'on-time'. My years as a waterfall PM saw this time and time again. We fool ourselves into thinking that we can predict a large project from beginning to end all up front, you can't, period.
So when you are rewarded in a GSD organization they are ultimately is saying that the organization values chaos over effective planning and delivery.