The Skill issue, the industry shame

I was reading Jason's blog when I came across this post. I could not agree more.

Way too many times I bump into problems that can be traced directly to the idea that you can hire just anyone, with any skill level and they will perform to the expected level of professionalism. This is pure bulls#%&!

Some time ago (just before the bubble burst in 1999) a company I was familiar with was hiring QA people just because they knew how to boot Windows. Yeah right! Way to go!

We also see the same with people putting together teams that behave like a set of individuals all pushing in different directions because "anyone" can be a manager! Stop believing in magic. You don't get a high performing team if you don't have a proper leader in the team (the leadership can be shared BTW, no need for a "hero", in fact that's sometimes worse). Start coaching the team and them make them understand how to work together!

If we put these two things together: hiring coders and testers that have no skill, and promoting people to leadership position that have no leadership skills what do you get? You got it: our software industry!

Can you believe it! This type of behavior and belief is rampant in our industry. Small wonder that we will be seeing lots of people being laid off in the near future...

PS: if you are smart and really good at what you do (testing or coding), you are better of these days starting your own consulting company, charging bucket loads of money and getting out of there once you are fed up with the local incompetence!

An inconvenient truth, in work management

I bet anyone in my position (Agile Coach) has faced this before: you present a work method to a team or a person (be it scrum, XP, DSDM, FDD, etc.) and they go "yeah, I see what you mean, but that would never work here".

If I only had a dime for every time I heard that I could be rich!

Today it happen again. Here I am presenting the Personal Scrum work method. People are following, they are asking some good questions and at some point it hits: "Yeah, I see what you mean and it makes sense, but that would never work for us. We have too much work we cannot predict because we want to have a very fast turnaround for our customers (1 business day) and that's why we cannot really plan our weeks that way. On top of it we are too busy to spend that much time (1-2 hours/week) planning what to do."

Now, for most of you (if not all) the problems in this phrase/quote are quite transparent, but for the person saying it, it was not. They did not understand some of the basic principles of work/time management and productivity:

1. If you cannot allocate your whole week because some portion of it will be "unpredictable" (have you heard of maintenance in production software?) then you don't allocate the full week to planned work! That's not a reason not to plan... Just estimate how much time you need for "unexpected" items (and that tends to be pretty regular from week to week), and plan the rest of the time!
   
2. If you are too busy, then how do you know your are doing the most important things for your stakeholders/customers? Are you setting aside the time to think through the priorities of your work from your customer/stakeholder's perspective? If not then I'm sure they'll be mad at you or at least disappointed -- even if you are busy!
3. If you are too busy (yes, again), that means you are "thrashing". This means: you have started many threads of work but are getting none of it done! Remember that only work that is "done" counts. Starting something you don't finish does not count (unless your manager/supervisor is clueless, in which case it is time to search for a new job anyway). Search for the ZEN of getting things to "done".
   
4. Work is work. Stating that a method (whatever that method is, take GTD for example) does not apply to manage your work can only be a result of not understanding the basic essence of any piece of work: 1) you get an order with some information and possibly inputs; 2) then you process it, alone or with a team; 3) finally you finish the work (as in "done"). This is true for every piece of work that needs to get done, whether it is planting potatoes or designing a piece of software, and certainly writing a business proposal or answering an RFP. If you don't understand that basic attribute of work there's a deeper problem we need to address. Managing the work is the least of my worries when I face this type of situation.

Now, all of these observations could have been done by anyone with experience in trying to manage work. But (and this is the sad fact) there's not too many people out there that understand the concept of "managing one's (or one's team) work". Sigh...
This brings back memories of a conversation I had with a senior and well known Scrum trainer/guru when he was training at our company:
In the CSM training, after the "promise" game exercise he was looking down and gloomy. I walked up to him and asked what was the matter. He turned and said: "see, this (the problems uncovered by the "promise" game) is what I see in all companies I visit, and that just makes me feel sad about the state of our industry. See, what I'm trying to do is just make our industry better, more professional".

Indeed, better and more professional. That's the right goal!