Though I consider myself primarily a developer I’m also trained in economics and finance, so from time to time I read about stuff not your stereotypical developer reads, such as persuasion, finance debacles and economy (knowingly that economic schools are a best attempt at decypherying what they can’t).
I read Scott Adam’s latest book and find it quite interesting. Go read it and thank me later. One of his main points is that you should thrive for setting a system and not goals, instead of setting yourself a goal to lose 10 pounds set in place a system to be healthier by eating everyday healthy stuff, whatever that means for you, but the point is focusing on the everyday efforts instead of the goal you are trying to achieve. True, if you lose 10 pounds you might be healthier and that’s the expected outcome but you lose yourself into achieving a goal and not on how to reach it. And worst of all once you reach your goal you might toss all you put in place and bam! you are back 10 pounds heavier or worse.
I keep hearing same phrase by different people, amongst them, authors, CFOs, CEOs: people overestimate what they can achieve in 1 or 2 years but they underestimate what they can achieve in 5 or 10 years. I heard it differently too, that we overestimate the future in the short run but underestimate it in the long run. 10 years ago everybody was using Blackberries and now we use our iPhones to call Uber drivers, Facetime with someone around the globe, watch our movies, stay up to date with our global village and so on.
And what does that have to do with Systems vs Goals you ask? well, I think I’ve witness in the past that if you set yourself a system vs goals you achieve way more stuff than if you set yourself goals.
Back in the day, around 2004 I used to work for a Salvadoran company (if you don’t know where El Salvador is, lets say is a third world country) and we were pretty much pre-agile revolution (agile is Circa ~ 2001), our system for developing software was pretty much like this:
- We need a software system to track our routes
- Let’s throw two months with one developer working 70%
- She will gather requirements from final users in 2 weeks
- Start coding on the third week
- And lets test last two weeks
Pretty much the Waterfall model with some nasty exploitation of resources such as your truly blogger.
In the end if I recall correctly the system I developed was doomed, totally out of context with what the VP wanted and what the users needed and myself frustrated because that product never saw the light in production. I wasted more than 2 months working on it with overtime that I will never get back. The goal was for me to develop a software and comply with project budget and time. Utter shennaningans.
When I came to the States in 2010 I joined a small goverment contractor and they had established Agile principles, I know this is 2016 and Agile is the best since sliced bread or the worst for some folks depending on which camp you are, I don’t get religious on either one but what I can tell you is that an agile shop establishes a system, you set goals for every sprint, you do estimation on the roadmap of your product and what not, the important part is you set a system.
Every sprint we will produce something that actually runs and we present to our customer new features, some get tossed others get criticized and some get approved and praised, we have happier users and happier developers. Back in my story users were disappointed on the IT department. On my states’ story I remember our users were on average happy (they kept hiring the company) and I was stoked that people didn’t yell at me and I pretty much work a normal week.
If I had worked systematically, although would have been only for 4 sprint, maybe there would be a product still running and some good memories on how I did something worth remembering. In waterfall a goal was set for me to achieve within a certain period of time, there was no system, I didn’t achieve the goal. With a system within two weeks I would have something working that could have been improved instead of a doomed product that nobody cared about.
Agile is an umbrella of practices and over the years I’ve worked for more than 3 companies using some sort of agile system. Every company defines what they understand by those practices and interestingly most of them work, the focus is more on the system on how to develop good quality software rather than on the final goal. In my experience the final goal or product by all means is never what you think in the begging, it gets shaped by users and product owners, you can’t know what you want until you actually see it, then you’d know. Build a system to achieve it.
If you liked this entry you might want to hire me because the summer is officially over.