Fog Creek Software
Discussion Board




How do I get my Boss to have process?

I am a firm believer in Joel's ideas about process. Especially after working in a company that used SEI techniques and experiencing the benefits!!!

Now I work for a company with 0 process (3 of 12 on Joel's test). Our manager is a nice guy but doesn't have a clue about technology or software process. Every time I try to suggest to add some basic process like Specs or a bug tracking database, I am viewed as "complaining" or an "upstart" threatening the manager's position.

Anyone have any thoughts on how to get a company to use Software Process without hurting anyone's pride?

KenB
Thursday, February 13, 2003

You don't.

Do your job really well and look around trying to understand your new environment. When you do understand how things work, start fixing the small process problems you encouter while you do your daily job. This is what you've been hired for to begin with.

With time, you'll gain recongnition for a job well done ++ and you'll have more of a process and less of a chaos around you. Finaly at that point, your Boss may have a better understanding of why a development process is needed and may listen to you. But think years, not months before you see a change in attitude.

Right now his assesment on you is that you whine and talk to much about things you don't really understand.

Remeber  "A closed mouth gathers no foot".

Cheers
Dino

Dino
Thursday, February 13, 2003

Read "Software Project Survival Guide" by Steve McConnell and then repeat over and over to everyone a summary of the material covering how process variability compromises quality and defeats your ability to effectively plan.  Even better if you can get responsible parties to read the book themselves.

http://www.amazon.com/exec/obidos/asin/1572316217/

His other book, "Rapid Development" is also useful because it is more comprehensive, but will take longer to read, and there's more material to cover.

Also, take baby steps - find your biggest problem (typically the problem closest to project inception) and attack it.  Once a stable solution is in place, repeat the process.  Good luck.

in the trenches
Thursday, February 13, 2003

Mr. trenches,

Thanks for replying - Actually I have read Steve McConnell's book "Rapid Development" and have been preaching his and Joel's ideas! (That's where I started to get into trouble)

The other 3 devs on my team totally agree and we want the process. The problem is that our pointy haired boss is an old school Mainframe prog who doesn't understand Windows Dev or J2EE Dev or UML or any sort of process. But he has all the power - we are just the workers.

I keep track of all of my code and changes so I know exactly what I have done - but how do I take it a level up and get the manager to implement some sort of formal spec instead of phone calls, emails, im's, and hallway meetings where the requirments change on the hour??????

KenB
Thursday, February 13, 2003

[realizing there are people with whom this won't work]

Get "forgetful"

"Hey Ken, what happened to the color scheme changes I asked you for?"
"Gee, Bob - I forgot about that. Can you put it in the bug tracking system? I check that several times a day."

"Hey Ken, I sent you an email about those color scheme changes - where are they?"
"Oh man, Bob, I never saw it. Could you put it in the bug tracking system?"

If you can get *all* the developers onboard doing this, it's got a good chance of working. Manymany mainframe programmers I've met like you describe have an underlying lack of self-confidence (they know they're lost). If you can guide them to where you need them to go without being confrontational or suggesting they're wrong, you've got a much better chance of success.

Once you can get a boss started with a bug tracking system, so long as you keep up with it then he should take to it like a duck to water because [ta da] it's an instant metric for him - he can SEE work being done.

Philo

Philip Janus
Thursday, February 13, 2003

>The other 3 devs on my team totally agree
>and we want the process. The problem is
>that our pointy haired boss is an old
>school Mainframe prog who doesn't
>understand Windows Dev or J2EE
>Dev or UML or any sort of process

In your shoes, I would start by writing my own specs and using a bug tracker.  And I would start doing estimates in excel. 

Then you extend the bug tracker to include feature requests.  Do you use version control?  CVS is another easy win.

Pretty soon, people are going to start to notice that you don't have the problems you do, and asking for help.

Don't preach.  Show them it can work, and they will come ...

Matt H.
Thursday, February 13, 2003

http://www.joelonsoftware.com/articles/fog0000000332.html

Ricardo Antunes da Costa
Thursday, February 13, 2003

Good answers all round.

Firstly, you could just leave. Probably isn't as easy as it sounds in the current work environment though.

What I'd recommend is create your own little pocket of excellence, which is exactly what I've done. I've introduced automated builds, specs and bug reporting system. Gradually, over time, people start to appreciate the small changes - the testers here are now amazed I can do a full rebuild in 5 minutes! - and people will start asking you how you do these things.

You have to be patient and prove your methods are better than others'. And the only way that usually gets recognised is by continually releasing product on time and to budget. Don't go blazing in with your ideas, cause you'll just annoy the boss. Get him into a situation where he thinks he's thought of the good idea. Of course, then you might get miffed the boss has "stolen" all your good ideas.

At the end of the day, you have to weigh up whether or not the effort of getting it all fixed without getting your head ripped of is more or less than the effort of finding a new job...

Better than being unemployed...
Thursday, February 13, 2003

Another thing to add to the previous posts that you touched on is to track your data.  Data is the most powerful weapon you can bring to bear on problems like this, in most cases.  For instance, record the amount of time a function point takes without a spec over a few function points.  Don't forget to include rework!  Next, start writing your own specs and developing based on that spec.  Track the time you take to write the spec and the development time, also including rework.  At this point, you can go to your boss and say, "Hey, look, when I have no spec, development is taking me this long, and when I do have a spec, it's taking me this long.  See how much development time writing a spec saves?  We can develop three features with a spec in the same time it takes to do two without.  Also, there were this many defects, costing this much time, without a spec.  Using a spec improved this situation by this much..."

If the data is compelling, your boss should say at this point, "That's great.  From now on, always write specs first." 

Then a little while later, you go to him and say, yanno, writing specs is taking me this long... I think this other fellow can write the specs just as well as me, if not better.  If we get this guy Bob to write the specs before I start developing, we'll free all that time up.  Based on the development numbers, that means we'll be able to get four features in the same time it takes to get three now.  I think it's a good idea."

At this point the boss should say, "yep, good idea.  I'll talk to Bob later and we can get the ball rolling.."

Obviously, this is an optimistic scenario, but not unrealisticly so.  Data is an excellent tool to bring to bear on any improvement effort since it is objective.  This is especially true when you back it up with logical arguments.  It takes some work to collect, organize, and present the data, but it's a high yield investment in a lot of ways.

in the trenches
Thursday, February 13, 2003

Thanks for the posts!!!!!

They've been really helpful.....

KenB
Thursday, February 13, 2003

KenB:

I know it's a little late for this ... but why did you take a job there if it's such a mess?

True, it's not very easy to find a job these days (compared to the late 90's, say).

My advice is threefold:

* Phase things in. If there are four developers, there is no reason why you can't use bug tracking software (e.g. bugzilla, fogbugz) amongst yourselves. Do *not* force the boss to use it. But make it a point for all of you devs to say how helpful it is.

* Find out *why* your boss opposes these ideas. Maybe he had bad experiences with them in the past. Maybe he has some misconceptions about them. maybe he doesn't understand exactly what you're asking for. Maybe he doesn't realize that bugzilla and CVS are free and won't cut into his budget.

* Most importantly -- maybe it's you! I'm not saying you're a jerk or anything; you probably aren't. But you say the guy is pointy-haired and knows nothing about technology, yet admit he has programming experience on mainframes! Perhaps your approach/personality is all wrong, and despite being "right" and a nice guy, you come across as a jerk. For this, I recommend "Getting to Yes", a great book on negotiation (formal or otherwise).

Regards and good luck. It sounds like you've got good goals; maybe you just need to adjust your strategy for reaching them.

Joe
http://www.joegrossberg.com

Joe Grossberg
Thursday, February 13, 2003

I don't think anyone has said this, some people might consider this wrong....

1.) Do a great job of whatever you have been assigned.

2.) Make sure other developers trust you, when you say things like "we need a bug database", and explain it to them, earn their respect.

3.) Make a list of all the responsibilites your Boss has, and work on those areas as well

4.) at the right time, go ask your boss's boss for your boss's job, and give him/ her a concrete list of reasons why you will do a much better job.

No offense meant here, but from what you say, your boss might not be one of those guys who listen to good advice, so either the project is screwed and you and your developer friends are let go, or you take over the reins and only your boss is let go, not that simple, but .....

Prakash S
Thursday, February 13, 2003

Joe -- It's also the case that very few places have a really good idea of process.  It's either draconian process that makes it nearly impossible to get anything done or it's no process at all.

So to a certain extent, you can't afford to make that an issue when finding a job.

flamebait sr.
Thursday, February 13, 2003

you CAN'T so live with it.

Jim
Thursday, February 13, 2003

Hey Jim are you by any chance  member of the management team????????

KenB
Thursday, February 13, 2003

Uh, how are your sale's skills? OK, stupid question, because apparently "at least not good enough in this situation".

Basically you have to look at each individual little change you want made as an individual product, and your goal is to sell the whole suite of products, or at least as many products as possible. But you know you can't get the customer to buy everything at once, so you have to work into it.

The simple way to begin is to schedule a relatively short appointment with the boss. Then two ways I can think of off the top of my head:

1) Bring to him your "problem" - the problem which is to be solved by the 'product' you are really trying to sell him on the sly.

Basically you lay out what you think you have identified as a problem, and using the Socratic method (you don't give him the answer, but rather you ask the questions that lead him to the answer) you get him to come to the realization that he can improve his employees productivity and efficiency by doing what you wanted him to do.

We shall refer to this as the Sly Method.

2) You bring to him your problem, and you lay out what you have "discovered" from the work you've been doing there (bonus points if you can tie in your conversations with him as how it is that you came to your discovery). Then you present to him how, from talking to the other devs, you've found out that they too have been having the same problems you've been having.

You then request permission to try a solution to the problem on a small scale with some of the other developers ("If they agree to try it..."), and lay out the costs to give it a limited trial run - which should be nearly nothing. And then you note the not too grandious gains to be had (if the gains are HUGE, don't say that, because he probably won't believe you), which "would definately outweigh the very limited expense, and would be a really small risk since it would be done on such a limited trial basis".

Lots of ways to frame the issue and such, but I'd have to know him personally to know which direction should be optimum. With thinking and research you should be able to rough out a good way to go about it.


Either way note the reasons you want to do it: "I think it would help the other developers and me be more productive, which makes us look good, and of course if we start looking better then, since your responsible for our work, you look better, and so on..."

If you can get him to go for it either way - promise to keep him informed and such - then BADABING!

All you have to do is then show it to be clearly a solution to not just stop using and worth continuing, and/or even expanding - you'll want to collude with the other developers here on this part.


Just get one solution done and you've increased the trust and respect you have with your manager, and your relationship can as such improve. Which means, when sufficient time passes and the opportunity arrises, you can then proceed to sell another of your products.

And so on and so forth, until you can get more and more and more things done to the point that eventually, one hopes, your manager would damn near rubber stamp anything you come up with. That's the goal, anyway.


So, that's my advice, and it comes with a 100% Money Back Guarantee :D

;)

Brian Hall
Thursday, February 13, 2003

The methodologists' "productization" of common sense could possibly work against you when presenting new ideas to your boss.  When I read process-related material, I do my best to translate from jargon-words to words my mom would understand.  This helps me to weed out the common sense from the branding, and see the similarities between different methodologies.  It also helps when you need to sell someone on process without them realizing it.

If you start conversations with you boss with something like, "You know, extreme programming/UML/use cases would really help out here...", you're already alienating him.  If instead you can find a way to strip out all the jargon-words and "brand religion" from your presentation so that you're using plain English common sense, you've got a much better chance of him hearing you through to the end of your presentation without closing his mind.

A technique I've found particularly useful when dealing with people above me who have a lot of "ego resistance" to hearing advice is to simply present my case as clearly as I can, without loading it with emotional argument, and only pursue discussion up to the point where I can see they understand what I'm saying.  NOT to the point where they agree.  Just enough to be sure they've really heard my reasoning.  And then back off.  Don't mention it again for several weeks.  Don't get frustrated in the meantime.  And often, if I've made a sound case, I'll hear this person spouting the same case I'd made to them to some other person, as if it was their own idea.  By giving them time and space to make the idea their own, I believe I greatly increase the odds of actually getting there.  Of course taking this approach requires you to trust that you're speaking to a fundamentally rational person.  If you feel you must beat them over the head until they capitulate in front of you, they'll sense your lack of trust, and then you've lost them.  I've found that really treating someone as if they were fundamentally rational beings helps them to be that way.

ODN
Thursday, February 13, 2003

Thanks again guys for those suggestions. I am a programmer, not a salesman so these types of ideas don't come to me naturally.

The problem with the world today is that you can't just come out as say things 100% honestly to fix problems.

Everything  is so political that you need to "sell" your idea to people who don't have a clue.

For example: When I first started this job my boss asked me to take a look at how we do things here and come up with some ways we could do things more efficiently - in coding & in practices.

Then, when I told him exactly how to do it, my suggestions were "duly noted" & ignored. From time to time I would try to bring it up again & that's when I was starting to be viewed in a negative light.

(But my intentions are honest. I have nothing against management or anyone in a personal way - I just want things to be done more efficiently & have more success!!!)

KenB
Friday, February 14, 2003

Rather than look at it like you are "selling" your ideas and feeling like you have to deal with a lot of politics I'd like to suggest you look at differently.

I'd agree that you have some good ideas. I'm all for process. The question is, why doesn't your boss agree? Don't "sell" the idea to him. Stop and listen to him. Find out why he does not want to listen to you.

He is the boss. He got to where he is for some reason. I'd like to think he is not stupid. So find out what he thinks about your ideas. Don't just listen but UNDERSTAND his point of view. Keep an open mind. He does not want process. You do want process. Is there a third alternative?

You may find that he is misunderstanding you or does not see the benefit. Once you have a better understanding of why he is not accepting your suggestions the solution might be obvious. Or you could come back here and fill us in with the details.

The bottom line is that he does not see how your suggestions benefit him or the company. You need to first understand why he has this belief and then what evidence you need to gather to change his mind.

Darrell
Monday, March 03, 2003

*  Recent Topics

*  Fog Creek Home