jump to navigation

Friday Philosophy – Why doesn’t Agile work? September 16, 2011

Posted by mwidlake in development, Friday Philosophy, Management.
Tags: , ,
13 comments

Why doesn’t Agile Development Methodology seem to work?

I’m going say right here at the start that I like much of what is in Agile, for many, many years I’ve used aspects of Rapid Application Development {which Agile seems to have borrowed extensively from} to great success. However, after my post last week on database design, many of the comments were quite negative about Agile – and I had not even mentioned it in my post!

To nail my flag to the post though, I have not seen an Agile-managed project yet that gave me confidence that Agile itself was really helping to produce a better product, a product more quickly and most certainly not a final system that was going to be easy to maintain. Bring up the topic of Agile with other experienced IT people and I would estimate 90% of the feedback is negative.

That last point about ongoing maintenance of the system is the killer one for me. On the last few projects I have been on where the culture was Agile-fixated I just constantly had this little voice in my head going:

“How is anyone going to know why you did that in six months? You’ve just bolted that onto the side of the design like a kludge and it really is a kludge. When you just said in the standup meeting that we will address that issue ‘later’, is that the same “later” that accounts for the other half-dozen issues that seem to have been forgotten?”.

From what I can determine after the fact, that voice turns out to be reason screaming out against insanity. A major reason Agile fails is that it is implemented in a way that has no consideration for post-implementation.

Agile, as it is often implemented, is all about a headlong rush to get the job done super-quick. Ignore all distractions, work harder, be completely focused and be smarter. It really does seem to be the attitude by those who impose Agile that by being Agile your staff will magically come up with more innovative solutions and will adapt to any change in requirements just because they work under an agile methodology. Go Agile, increase their IQ by 10 points and their work capacity by 25%. Well, it doesn’t work like that. Some people can in fact think on their feet and pull solutions out of thin air, but they can do that irrespective of the methodology. People who are more completer-finishers, who need a while to change direction but boy do they produce good stuff, have you just demoralized and hamstrung them?Agile does not suit the way all people work and to succeed those people it does not suit need to be considered.

The other thing that seems to be a constant theme under Agile is utterly knackered {sorry, UK slang, knackered means tired, worn out and a bit broken} staff. Every scrum is a mad panic to shove it all out of the door and people stop doing other things to cope. Like helping outside the group or keeping an eye on that dodgy process they just adopted as it needed doing. Agile fails when it is used to beat up team. Also, I believe Agile fails when those ‘distractions’ are ignored by everyone and work that does not fall neatly into a scrum is not done.

I suppose it does not help that my role has usually been one that is more Production Support than development and Agile is incompatible with production support. Take the idea of the scrum, where you have x days to analyse, plan, design, unit test and integrate the 6 things you will do in this round. On average I only spend 50% of my time dealing with urgent production issues, so I get allocated several tasks. Guess what, if I end up spending 75% of my time that week on urgent production issues, and urgent production issues have to take priority, I can screw up the scrum all on my own. No, I can’t pass my tasks onto others in the team as (a) they are all fully assigned to their tasks and (b) passing over a task takes extra time. Agile fails when it is used for the wrong teams and work type.

I’ve come to the conclusion that on most projects Agile has some beneficial impact in getting tasks done, as it forces people to justify what they have done each and every day, encourages communication and gives the developers a reason to ignore anything else that could be distracting them as it is not in the scrum. Probably any methodology would help with all of that.

My final issue with Agile is the idiot fanatics. At one customer site I spent a while at, they had an Agile Coach come around to help the team to become more agile. I thought this was a little odd as this team was actually doing a reasonable job with Agile, they had increased productivity and had managed to avoid the worst of the potential negative impacts. This man came along and patronisingly told us we were doing OK, but it was hard for us to raise our game like this, we just needed help to see the core values of Agile and, once we did, once we really believed in it, productivity would go up 500% {That is a direct quote, he actually said “productivity will go up by 500%”}. He was sparkly-eyed and animated and full of the granite confidence of the seriously self-deluded. I think he managed to put back the benefits of Agile by 50%, such was the level of “inspiration” he gave us. Agile fails when it is implemented like a religion. It’s just a methodolgy guys.

I find it all quite depressing as I strongly suspect that, if you had a good team in a positive environment, doing a focused job, Agile could reap great rewards. I’m assured by some of my friends that this is the case. {update – it took my good friend Mike less than an hour to chime in with a comment. I think I hit a nerve}.

Friday Philosophy – Tainted by the Team August 26, 2011

Posted by mwidlake in development, Friday Philosophy, humour, Management, rant.
Tags: , , , ,
3 comments

A while ago whilst working on one project, a colleague came back to his desk next to mine and exclaimed “I hate working with that team! – they are so bad that it makes everyone who works with them look incompetent!”

Now there is often an argument to be made that working with people who are not good at their job can be great for you, as you always looks good in comparison {it’s like the old adage about hanging around with someone less attractive than you – but I’ve never found anyone I can do that with…}. It is to an extent true of course, and though it can seem a negative attitude, it is also an opportunity to teach these people and help them improve, so everyone potentially is a winner. I actually enjoy working with people who are clueless, so long as they will accept the clues. You leave them in a better state than when you joined them.

However, my friend was in the situation where the team he was dealing with was so lacking in the skills required that if you provided them with code that worked as specified, which passed back the values stated in the correct format derived from the database with the right logic… their application code would still fall over with exceptions – because it was written to a very, very “strict” interpretation of the spec.

In one example, the specification for a module included a “screen shot” showing 3 detail items being displayed for the parent object. So the application team had written code to accept only up to 3 detail items. Any more and it would crash. Not error, crash. The other part of the application, which the same people in the application team had also written, would let you create as many detail items for the parent as you liked. The data model stated there could be many more than 3 detail items. I suppose you could argue that the specification for the module failed to state “allow more than three items” – but there was a gap in the screen to allow more data, there was the data model and there was the wider concept of the application. In a second example, the same PL/SQL package was used to populate a screen in several modes. Depending on the mode, certain fields were populated or not. The application however would fail if the variables for these unused fields were null. Or it would fail if they were populated. The decision for each one depended on the day that bit of the module had been written, it would seem. *sigh*

The situation was made worse by the team manager being a skilled political animal, who would always try to shift any blame to any and all other teams as his first reaction. In the above examples he tried to immediately lay the blame with my colleague and then with the specification, but my colleague had managed to interpret the spec fine (he did the outrageous thing of asking questions if he was not sure or checked the data model). Further, this manager did not seem to like his people asking us questions, as he felt it would make it look like they did not know what they were doing. Oddly enough they did NOT know what they were doing. Anyway, as a consequence of the manager’s hostile attitude, the opportunity to actually teach the poor staff was strictly limited.

That was really the root of the problem, the manager. It was not the fault of the team members that they could not do the job – they had not had proper training, were unpracticed with the skills, siloed into their team, not encouraged to think beyond the single task in front of them and there was no one available to show them any better. The issue was that they were being made to do work they were not able to do. The problem, to my mind, was with the manager and with the culture of that part of the organisation that did not deal with that manager. He obviously did not believe that rule one of a good manager is to look after the best interests of your team. It was to protect his own backside.

But the bottom line was that this team was so bad that anything they were involved in was a disaster and no one wants to be part of a disaster. If you worked with them, you were part of the disaster. So we took the pragmatic approach. When they had the spec wrong, if we would alter our code to cope, we would alter our code. And document that. It gave us a lot of work and we ended up having a lot of “bugs” allocated to our team. But it got the app out almost on time. On-going maintencance could be a bit of an issue but we did what we could on our side to spell out the odditites.

I still know my friend from above and he still can’t talk about it in the pub without getting really quite agitated :-)

Friday Philosophy – The Secret to Being a Good IT Manager June 3, 2011

Posted by mwidlake in Friday Philosophy, humour, Management.
Tags: , ,
10 comments

If you go into a book shop there will probably be a section on business and, if there is, there will almost certainly be a load of books on how to be a manager. Shelves and shelves of them. There is also a large and vibrant market in selling courses on management and aspects of management. I’ve been on a couple of such course and, if you can manage to be open minded whilst keeping a cynical edge, I think they can be useful.

However, I think I most of them are missing the key points and that if you can but hold on to the following extensive list of guiding principles you will be a good IT manager. Maybe even an excellent one :-):

  1. Your top priority, at all times, is to see to the best interests of your people.
  2. Whatever you develop, be it code, databases, network, a team of support staff – User Acceptance is paramount.
  3. You must find ways to deal with other teams and your own management hierarchy in such a way as to be allowed to do (1) and (2).
  4. That’s it.
  5. OK, if pushed, I’d say Never Lie. Maybe that’s just personal though, it’s because I don’t have the memory, audacity or swiftness of mind to pull it off. By not lying I don’t have to try and construct what I said to who and why.

I’m sure people could cite some other hard rules like “you must be within budget” or “you need to get buy-in to your vision” but I don’t agree. Budgets can be negotiated and the difference between those deemed visionaries and those deemed fantasists seems to be to me down to success and luck. Luck is luck and for success I refer you to points 1 through 5.

OK, maybe a final rule is:

  • Never ask for or aim for something that is not realistic.

So, I am now able to develop my team and my application and not expect to be able to spend half the company profit on the fastest box out there, as it is not realistic.

There are a shed load of other things that I think are important to helping you be a good manager, you know, techniques and methods for improving things, but nothing else that is key.

And it’s such a simple, small list even I can aim for it.

The shame of it is that I don’t think it’s enough to be developed into a book or a course so I can’t sell the idea. That and I’ve gone and given it away in this blog. Also, though I feel I can give points 1,2 and 5 a good shot, point 3 is way beyond me…possibly because of point 5… So I am not a great manager.

I’m going to hide behind this stout wall now, with my hard hat on, and wait to be told how naive I am…

Update – A couple of weeks later, Kellyn on her DBA Kevlar blog put similar sentiments to looking after your guys, more from the employee’s perspective and far better covered

Why given so many of us feel this way and want things to be this way…are they not?

Friday Philosophy – The Best IT Person I Have Met September 24, 2010

Posted by mwidlake in Friday Philosophy, Perceptions.
Tags: , ,
3 comments

I’ve had the pleasure of working with and meeting a lot of talented and capable people in IT – some of them have even been nice people too :-) {In fact, most people I have met do not match that annoying myth about IT’s reputation for social awkwardness). However, for me one person sticks out in my mind as the best person I have worked with in IT.

It’s Barry. I’m pretty sure none of you have met Barry, and in fact as I knew Barry back in 1996 I’m not so sure I would recognise him (and I have no hope of remembering his last name) if I met him now.

Barry and I met when I got press-ganged into a Unix system administration team. I was just getting started at being an Oracle Performance person and knew very little about Unix Sys admin. But, for reasons I won’t go into now, I went home on the Friday as an “Oracle expert” and came in on the Monday to find my desk had been physically lifted and moved into the Unix sys admin corral and I was now a “Sys Admin not-expert”. My protestations were listened to – and then ignored, with the information that if I did “not knuckle down and get on with it”, the money would stop flowing. So, rather dazed and just a tad unhappy with the situation, I sat – and sulked – at my desk. And there, sat next to me, was Barry.

You are probably expecting me to now tell you that Barry knew Unix sys admin inside out and how he took me under his wing and showed me the ropes. Well, he didn’t. I have no idea where they got Barry from, I think he was a pro-C developer, but he had just been similarly abused by management and deposited into a team he had not signed up for. And he knew even less about being a sys admin than I did. I at least knew my way around a few monitoring commands like top, w, ps, “glance” etc.

Barry was also not very quick with IT. Don’t get me wrong, he was not stupid, but he was not one of these people who just had an affinity for technology and spent all his spare time building their own media server when CD-ROMS for PCs were still quite new. In fact, he seemed to find the whole of IT to be something of a challenge.

What Barry had though was enthusiasm, commitment and curiosity. Not in an annoying, bouncing all over the place crying “this is great” way, but more a case of “OK, server Falcon has run out of disk space. What can I do about it? How do I find out where the storage has all gone, who is using it and can I get it back off them?”. And he would set to. He’d start with what he knew (which was little more than the “Man” {Online Manual} command in the first week) and the bits he could suck out of my head and work through it. Every few minutes he’d be tapping me on the shoulder and saying things like “Look, you can get information about disk usage here, and map it to the real physical disks by greping for this”.

It was Barry’s attitude that made him stand out, and also his ability to infect you with the same attitude. I started off in that team furious and demoralized, determined to find a new position and resign ASAP. But Barry got over his annoyance and started working. He asked me for advice and discussed the issues over with me, even though I was as clueless as him. When he found something he showed me it. When I found something, he was keen to learn it.

Between us, we got by. We knew very little and it was hard work, but because Barry was not daunted and would keep working on the problem until he had it sorted, he dragged me along with him. Often I would still be there with him into the evening, sorting something out when everyone else had gone home. He did not just take on every problem people came to us with though, he would stick with what he felt was the biggest issue until it was sorted, and he would keep with it, and ask for help, and try what you suggested.

{oddly enough , the worst person I ever worked with was already in this team. Maybe that is why the others left and Barry and I were pulled in!}

It only lasted a few months as we both escaped to jobs more suited to our skills, but I learnt a few things. One was that a crummy job could be made a lot better just by your attitude and another was that some people (Barry, not me) had a real talent for enthusing people and thus getting things done. And also, that you did not have to be highly intelligent or knowledgeable to do a very good job. That’s lucky for me, then :-)

Team Work & The Science of Slacking July 23, 2010

Posted by mwidlake in Friday Philosophy, Management, Perceptions.
Tags: , , ,
add a comment

We all know that working in a team is more efficient than working on your own (and I did say a week or two back how I was enjoying the rare privilege of working in a team of performance guys). Many of us also know about team dynamics and creating a balanced team of ideas people, completer-finishers, implementers, strategists and so forth. Those of use who have been exposed to training courses or books on team management know all these good things about teams and how we are supposed to get the most out of them.

How many of us, though, have been introduced to the work of the French Agronomist Max Ringelmann and the aspect of teams named after him, the Ringelmann Effect? In summary the Ringelmann Effect proposses that people in teams try less hard than they do when working alone. Especially if they think no one is watching them.

Back at the start of the 20th century Ringelmann tested out his ideas using a tug-of-war experiment. He would get people to pull on a rope as hard as they could and record their efforts using a strain gauge. Then he would get them to pull on the rope as part of a team, from 2 to 8 people. As soon as people were part of a team, they pulled less hard. With two people in the team, each pulled 93% as hard as on their own, with three people this dropped down to 85% and with 4 it was just 77%. By the time there were 8 people in the team, effort was down to 50%.

This idea of shirking work more and more as the team increased in size became established in modern psychology and was given Mr Ringelmann’s name. Psychologists explain that when someone is part of a group effort then the outcome is not solely down to the individual and, as such, is not totally in their control. This acts as a demotivating factor and the person tries that little bit less hard. The larger the team, the greater the demotivation and the more significant the drop in effort. Ringelmann found that effort was down to 50% in a team of 8 so how bad can the impact of the team be? I think most of us have at least witnessed, and quite possibly been in, the position of feeling like just a cog in a massive corporate team machine. Thoroughly demotivating (though, of course, we all of us still tried as hard as we could, didn’t we?).

The effect is also know under the far more entertaining title of Social Loafing.

Monsieur Ringelmann was far kinder at the time and pointed out that these chaps pulling on the rope could well have been suffering from a lack of synergy. They had not been trained together to pull as a team so that could account for the drop in effort, they were not synchronising their effort.

However, in the 1970’s Alan Ingham in Washington University revisited Ringelmanns work and he was far sneekier. Sorry, he was a more rigorous scientist. He used stooges in his team of rope-pullers, blindfolds and putting the one poor person pulling for real at the front of the team pulling the rope. Thus he could record the effort of the individual. Ingham found that there was indeed a drop in efficiency due to the team not pulling as one. But sadly, this was not the main factor. It remained that the drop in effort was mostly down to the perceived size of the rest of the team. The bottom line was proven to be the human capacity to try less hard when part of a team and that the drop in effort was directly proportional to the size of the team.

We are of course not immune to this effect in the IT world and someone has even gone to the effort of checking that out, James Suleiman and Richard T Watson.

It seems the ways to reduce this problem are:-

  • Don’t give people boring jobs.
  • Don’t give the same job to several people and let them know they all have the same job.
  • Ask people how they are getting on and give them mini-goals along the way.
  • Atually reward them for success. Like saying “thank you” and NOT giving them yet another boring, hard job to do as they did the last one so well.

I think it is also a good argument for keeping teams small {I personally think 5 or 6 people is ideal} and split up large projects such that a single team can cope. Then give tasks to individuals or pairs of people.

If you like this sort of thing you might want to check out one of my first blog post (though it is more an angry rant than a true discussion ofthe topic) which was on the Dunning-Kruger effect, where some people are unaware of their own limitations – though I did not know it was called the Dunning-Kruger effect until others told me, which only goes to show that maybe I am not aware of my own limits… Read the comments or click through to the links from there to get a better description of some people’s inability to guage their own inabilities.

Friday Philisophy – To Manage or to Not Manage March 26, 2010

Posted by mwidlake in Friday Philosophy, Management, Uncategorized.
Tags: ,
6 comments

Recently a friend of mine Graham Oaks blogged about his decision to step back from management and return to the Technical Coal Face.

I made a similar decision 3 or 4 years back, so I have a lot of empathy for his position and his decision. I found that to do the job of a manager takes up a lot more time, effort, patience and emotional effort than I had realised. Team leading is bad enough, having to coordinate the efforts of a half dozen people and sorting out the myriad issued they throw your way. Being in charge of multiple teams, responsible for strategy, dealing with staff development and moral, being a buffer against HR and having to deal with the politics created by people who WANT to be managers and wield power is more than a full-time job. Trying to hold onto a technical element as well, I found I could only manage it by doing the technical job as a “hobby”, in my own time. It was just too much to keep going year after year.

I had to chose. Give up the technical to give me enough personal resource to remain a manager and get better at it, or stop being a manager and start re-gaining my technical skills. I chose the latter.

Since I made my decision 3 years ago, I have met several people who have made the same conscious decision to step away from management and return to a more technical role. You may stand to earn more as a manager {which is something I objected to before being a manager and I still object to having been one – it should be possible to earn the same doing either} but for some of us it is not enough to make losing the hands-on work a sacrifice worth making.

One of the points Graham makes in his blog is that his spell as a manager has given him an appreciation of the challenges of management and the particular hells and stresses of the role. I think this is something that people who have never been managers have trouble really understanding.

I was working with a guy a couple of years ago and he was telling me how much of “a Moron” his boss was. In fact, he felt his current boss was even more of a moron than his previous boss. He then confessed that all of his bosses had been morons. “What, every single one of them?” I asked. Yes, absolutely all of them. That struck me as incredibly unfortunate, that every single one of these managers (and he’d had a lot as he moved between teams and positions on a regular basis), most of whom had come up through the technical ranks, were all Morons. I pointed out this unfortunate coincidence and wondered if there might actually be a common factor with all of these managers. He told me there was; They were all Morons.

He himself had never been a manager. He said he was too smart. Not smart enough to get what I was hinting at with the common factor suggestion though.

Obviously, some managers are poor at what they do; there are poor people in every job. But something I took away from my time being a manager is a lack of empathy for anyone saying all managers are a waste of time when they have never done the job themselves.

After all, I doubt there is any job where just doing it means you are an idiot.

Except Sys Admins – They are all idiots :-) (ducks behind server).

Advert for the Management and Infrastructure SIG March 24, 2010

Posted by mwidlake in Management, Meeting notes.
Tags: , ,
4 comments

I’m a bit late doing this (life is just too busy at the moment) but I want to mention the next Management and Infrastructure Special Interest Group meeting of the UKOUG next Week. Tuesday 30th, being held in Oracle’s London City office.

I get asked by people what exactly the MI SIG is? {Honest, I do, I got asked twice this month alone!}. Is it a management meeting or is it another one of the technical SIGs, like the UNIX, RDBMS and RAC/HA SIGs? I’ve struggled to come up with a single line to sum it up. Other than to say “Both”.

It might be easier to sum up the target audience. The MI SIG is for technical people who need to deal with Oracle as a component of a large IT environment. Most of the audience could knock up a PL/SQL script to create a new set of tablespaces each month, would be able to instal Oracle {if given a couple of days and the manuals to peek at} and could explain two-phase commit. Maybe.
But what they have to deal with in their working lives are things like using Grid Control to manage 500 instances, understand what options are there for providing disaster recovery {if not the exact commands to eg set up physical standby or active/passive RAC}, knowing enough about storage options to make a sensible decision on which is best for each type of Oracle system they have. So it is a technical SIG, but covering general principles and, well, Infrastructure.

And the Management? Well, when the SIG started this bit was really interesting to me. When you have a lot of IT going on, especially in large organisations, the people looking after Oracle are not the people looking after Networks, or Storage, or Backups or half a dozen other things. And you probably have a team of people doing all that Oracle stuff with/for you. So you have to hire staff and keep ’em happy and deal with teams who you have no power over but you need them to do stuff for you. And that Management part can be a lot harder than the technology, especially if you never planned on being a manager but just woke up one day with that monkey on your back.

So with the technical aspects of Large IT Infrastructure comes the management component too. The SIG is there for that audience.

I chair this SIG, so I am more than a little bit biased, but I think it is a good line-up of talks for this up-coming meeting. We have two talks on using OEM/Grid Control, one around using it for deploying clusters, one about how you go about integrating it with the likes of LDAP, Kerbros and using the Custom Metrics, ie plugging it into the wider infrastructure.

We also have a presentation on the latest/greatest Exadata2, from some Oracle friends.

To wrap up the technical talks I am going to try and explain some of the guiding principles for gathering statistics for you oracle databases. Not the details of DBMS_STATS command syntax, but why you need good stats, how you get them and the issues we all seem to end up facing with it.

Balancing the techical side is a talk on Birkman and understanding teams and people.

So, you can see it is a line-up matching the diversity of the SIG’s purpose.

As I said earlier, I initially was very interested in the management side of the SIG and I worried I would be pretty lonely in that opinion. For various reasons, those of us on the technical side tend not to have much time for those “soft skills” we associate with management theory. However, when I took over the SIG over a year ago, I asked the audience if they would want some talks on hiring staff, dealing with people, motivation… Over 60% of the audience said “YES!”. Quite loudly. About 30% said “OK, so long as we get technical stuff as well”. 6% said “over my dead body”.

I think the reason so many wanted the management side as well is, whether we like it or have an affinity for it or not, it is part of the job. And so we need to be able to do it. Personally, I quite like the human side of IT, but my wife tells me I am strange.

If your organisation has UKOUG membership it is free to come along to the SIG (one person per membership, excluding Bronze membership) Anyone can come along for £80. You would be very welcome and I am sure you will learn new stuff. Don’t let the fact that we retire to a pub afterwards where the chair buys a round sway your decision to come along at all.

Friday Philosophy – CABs {an expensive way to get nowhere?} March 11, 2010

Posted by mwidlake in biology, development, Friday Philosophy, Management.
Tags: , ,
3 comments

A few years ago, my wife and I went to New York for a holiday. We got a cab from the airport into Manhattan. It was an expensive way to see, at great length, some of the more uninteresting automobile transit routes through New York. We arrived at our hotel a great deal later than we anticipated. And with a lot of our paper dollars no longer in our possession.

I’ve also taken cabs through London, usually at the weekend to get back to Liverpool Street Station. The trip is generally quick, painless and not too expensive, no matter what bit of London is currently being dug up. Those black-cab drivers know their stuff.

Of course, the CABs I refer to in the title of this Friday Philosophy are not private cars for hire. In this context CAB is Change Advisory Board. A term that can make grown developers weep. If you do not know, the Change Advisory Board is a group of people who look at the changes that are planed for a computer system and decide if they are fit for release. My personal experience of them has been similar to my experience of the taxi variety, though sadly more of the New York than London experience.

You might expect me to now sink into a diatribe {ie extended rant} about how I hate CABs. Well, I don’t. CABs can be a part of a valuable and highly worthwhile process control mechanism. Just as proper QA is core to any mature software development process, so CABs are important in getting informed, talented stakeholders to review proposed changes. They check for overall system impact, clashes with other proposed changes that individual development streams may be unaware of, use their own {hopefully deep and wide} experience to consider the changes and to verify Due Diligence has been invoked {that last one is a bit of a minefield and where, I believe, many CABs fail}.

Sadly, though this is often the aim, the end result is too often a bunch of uninformed and technically naive politicos trying to wield power, using the CAB meeting as an extended game of management chess.

I’ve seen CABs trade changes. “I’ll let you have X if I can have Y and Z”. I’ve seen CABs turn down changes because the form had spelling mistakes in it. I’ve seen CABs object to a change that will save the company 5 million pounds a day because it lacked one signature.

That last one just stopped me in my tracks {I’m not exaggerating either, if anything I am underplaying the cost impact of that decision. I saw the figures and I wasted a couple of days of my life checking, 5 million pounds a day was the least I felt I could prove.} We are talking about enough money every day to pay the salary of everyone on the CAB for several years. And they blocked it because the DBA team had not signed off the change. No effort was made to address the lack of the signature in any way, the change was just refused.

The DBA Team had not signed off the change because the one and only DBA Team Leader who was allowed to sign off was on holiday for two weeks. They needed that holiday too, for other but I suspect linked reasons.

Now, I knew the DBA Team Lead and he was a good bloke, he knew his stuff and he was not paid 5 million pounds a day. His deputy was paid even less but was no less talented but she was not allowed to sign off the change as she was not the DBA Team Lead.

That was a CAB gone very wrong. The process of the CAB had been allowed to over-rule good business sense. It was also overruling general and technical sense, but that really is secondary to what keeps the business making a profit.

I’ve seen the opposite of course, technical teams that just apply whatever changes they feel are fit, with no oversight or CAB. To be honest, this less controlled process seem to mess up less often than a poor CAB process as the technicians know they are the ones who will spend the weekend fixing a mess if one occurs. But that mess up will occur eventually, if control is lacking, and the bigger and more complex the IT environment, the greater the chance of the mess up.

So, I feel CABs are good, no make that Great, if you have the right people on them and you have a sensible cascade of authority so one person being away does not block the system. That is quite a bit harder to put in place than a simple “Dave A, John, Andrea, Alex, Raj, Dave P, Mal, Malcolm and Sarah have final signoff” which most CABs effecively become.

But there is one last fault of CABs I want to highlight. They tend to treat all changes in the same way and all changes are not the same. Upgrading the underlying OS is not the same as adding a cardinality hint to one Business Objects report.

If your CAB or change process treat the two above examples the same, then your CAB or change process is broken. Now, in all IT “rules of thumb” there is an exception. In this case, I am truly struggling to think of one. My feeling is that if your change process treats an OS upgrade the same as adding a hint to a report, it is not fit for purpose.

Those are my main issue with CABs. They should be of significant business importance, but nearly always they are implemented with one process to deal with all situations and then get taken over by people with an “Office Politics” agenda as opposed to a “Getting the best job we can reasonably expect done” agenda.

I’m very passionate about this and I have a way I hope can throw this issue into context, an analogy.

Ask yourself this senario.
You go to your doctor with a niggly cough you have had for a week OR you go to your doctor because you almost passed out each day you got out of bed for the last three days.
If your doctor treated you the same for both sets of symptoms, would you be happy with that doctor?

Why are all IT changes handled by most CABs in exactly the same way?

(BTW if you ever almost collapse when you get out of the bed in the morning, do NOT go to work, go instead to your doctor and ask them for a full medical and if he/she does not take blood pressure readings and order a full blood chemisty test, go find a new doctor.)

Friday Philosophy – What Was My Job Again? December 11, 2009

Posted by mwidlake in Management.
Tags: , ,
2 comments

How much control do we have over what job we are in?

I know I have mentioned this before, but I did not choose to work with Oracle – I fell into it by accident. I found myself in a job which I was no longer enjoying, for a boss who had issues with me and I had issues with a salary (mine, of course). So I decided to apply for a job with a company a friend of mine worked for:

For those of you who are not UK-born or have seen less than three decades go by, in 1990 “Oracle” was a teletext company that provided information on your TV screen for the TV company Channel 4. Basic news, entertainment, sports etc via chunky text and chunkier graphics thrown up in glorious low-res.

I honestly thought I was going for an interview with that company, as opposed to the other “Oracle”, some database company with the same name which went on to pretty much conquer the corporate database and applications world. That was a pretty lucky break for me and I made a conscious decision to stick with this database stuff.

Many years later I was on a contract doing database performance tuning. Someone, a manager, came and asked me about how they could save space, not in the database world but in the Unix filesystem world. So I made the suggestion that they check out the man page on compress. We compressed some big files and he went away happy, leaving me to get on with my database stuff. My big mistake was, when he came back a week later and asked how he could get the compressed data out, I promptly showed him. I revealed too much knowledge.

I came in to work the next Monday morning and my desk had gone. There was an oblong square of dust and hula-hoop crumbs, nothing else. Even my pile of “documents to get back to” from under the desk was gone. Had I been sacked? No, I had been put in the Unix system administration team. My desk had been picked up and physically moved across the room to the Unix Corral, along with everthing on, under or next to it.

No one has asked me, it had not been mentioned to me at all, the managers had just realised on Friday that half the existing team (contractors) had left at the end of the week and no replacements had been found. That devious manager I had helped had told the others I was a whizz at Unix and so my fate was sealed. I was not a whizz at Unix, I was barely competent at basic shell programming. But I learnt a bit before deciding I wanted to stick at the Database stuff and went off to a contract doing that again. I still kind of wish I’d done the Unix a little longer though.

The final shift I’ll mention, and is probably more commonly echoed in other people’s experience, is coming in one day to find you are a manager. This had happened to me small-scale a couple of times, taking on a contract where I ended up in charge of a team, but in this particular case I was a permanent employee managing a team of 4 DBAs and my boss left. Within the week I found that I was being treated as the manager of 5 or 6 teams, totalling about 30 people. More by them than by upper management, but upper management cottoned on and asked me to do the job. Long story cut short, I resisted the move upwards but it happened anyway. Not, at that time, what I wanted at all.

I’ve told the above story a few times when doing presentations on management-related topics and many people, a surprising number to me,  have said to me afterwards that the same sort of thing happened to them. I am also now chair of the Management and Infrastructure Special Interest Group of the UK Oracle user group. That SIG is full of people with a similar story.

What is the point of this particular Friday Philosophy? Well, these experiences have made me realise that a lot of people are probably doing jobs they just found themselves in, or in the case of managers, just got pushed into.

If you did not chose your job, you are unlikely to be a good fit, especially to start with.

I’m sure most of us have experienced this and, looking back, can see that initially we lacked the skills, the background, even the inclination for the role. But we either got on, moved on, or become morose and bitter.

This also means that we are all probably encountering a lot of people in that exact situation, all the time – People doing a job they just found themselves in. So, if someone seems to not be doing a job as well as they could, check how long they have been doing it. If it is a recent change, remember your own experience and cut them some slack. You would have appreciated it when you were them.

It also explains Morose and Bitter Geoff who manages Accounts too, doesn’t it?

Friday Philosophy – Disasters September 4, 2009

Posted by mwidlake in Perceptions.
Tags: , ,
4 comments

Some of you may be aware that I occasionally do presentations called something like:-

“5 Ways to Progress your Career Through Systems Disasters”

The intention of the presentations are to comment on things I have “been in the vicinity of” going wrong in I.T. and ways to avoid them, in a light-hearted manner. Having a bit of a laugh whilst trying to make some serious points about project management, infrastructure, teams, people and the powers of chaos.

I’ll see about putting one up on my Web Site so that you can take a look {check back this weekend if you like}

The talks usually go down well but there are two potential issues in giving the talks:

  • The disasters or problems, if in some way my fault, could make me look like an idiot or incompetent.
  • If it is known who I was working for when I “witnessed a disaster”, it could make that company look bad.

I never used to worry too much about this when I worked permanently for a company that was pretty relaxed about “stuff happens, it is good to share”. After all, if I looked like an idiot then that is fair enough and if I said anything that could be linked back to a prior (or current) employer {which, I hasten to point out, I did aim to avoid} then, well, sorry. But I only said things that were true.

However, when I returned to being self-employed, a good friend of mine took me to one side and suggested such talks could harm my career. I argued that it was not malicious and was helpful to people. My friend argued back that potential employing companies would not look so favourably on this, especially if they suspected that they may one day feature.

Hmmmm…. This was true.

So I toned down the talk…

The next time I did the presentation, the sanitised one, it was not such a hit. In fact, it was a bit rubbish.

The question is, should I have toned it down? Hands up anyone who has not personally done something unbelievably stupid at least once in their working life? Can everyone who has worked for an organisation that has not messed up at least one I.T. project please also raise their hand?

I can’t see any raised hands from here :-)

We all make mistakes.
All companies get things wrong at times.

Something you find when you start presenting or organising events is that the talks people most appreciate and learn the most from are about things going wrong.

So why can’t we all be grown-ups about admitting them, talking about them and learning? Personally, when I have interviewed people for jobs, I am always impressed by someone who will admit to the odd failure, especially if they can show what they learnt from it.

Oh, if anyone is reading this before offering me a position, I never made a mistake in my life, honest. I never deleted every patient record from a hospital information system, I was not even on-site when the incident didn’t happen. And if anyone suggest otherwise, it was a long time ago when it didn’t happen. ..

{I got all the data back, anyway. Never start work without a backup…}

Follow

Get every new post delivered to your Inbox.

Join 196 other followers