Slashdot Mirror
Do You Buy Into Management Methodologies In IT?
albert_tam asks: "I don't appprove of 'management methodologies' and I feel that things like ISO, TQC, Kepnor-Tregoe, CMM, 6 Sigma, etc., aren't worth the time it takes to learn them. There are also those self-proclaiming-MBA-bearing IT experts, who spout off about these everyday in our office and earn big paychecks. The result? It's not important. By the time everybody in the office is forced to get started with these management methodologies, those 'so-called' Quality assuring IT consultants are already gone. The thing is, do you buy those management methodologies? How do you draw a line between IT & management concepts without hindering your daily work? Let's hear what you have to say."
I haven't encountered any purely management methodologies. But I have come across, and used, several development methodologies. Every single dev meth has had a lot to say about the management of a project (some more than others).
Development methodologies are superb. If you can get everyone in the team in agreement on a methodology, then you can create software quicker and better. These has been shown academically, in the workplace, and in my own experience.
What you don't need are bureacratic methodologies. If you spend your whole time writing documentation, drawing diagrams, tracking your time and other morale destroying tasks then the methodology sucks.
If you spend all your time writing high quality, self documenting code with repeatable tests - that pass - then your methodology is good, although I suspect you're lying about the 'all' your time bit
Personally I prefer iterative methodologies (DSDM, FDD, XP) and my current project is using Extreme Programming in anger (for the first time - it's scary). XP does tackle a lot of management issues - not least of which is, "What does the manager do?" question. It points out where traditional project management tasks are handled by the methodology and where managers can add value. It deals with measuring and tracking project progress, and using those measurements to determine future project progress (thus allowing better estimation and hitting release dates). It also covers testing, including unit tests and functional/acceptance tests.
So even those I would describe it as a development methodology, it is also to a large degree a management methodology, and more importantly can greatly add value to your team.
So methodologies are essential in any business type development. What you call them isn't important, but having them, and making them easy to understand and easy to use, is.
Of course, if you have political managers (i.e. they're in the game for their own benefit, trying to promote themselves all the time, not working together or for the company) then any methodology could run into problems. So pick decent places to work where people are motivated and committed (which doesn't mean 70 hour weeks - you can be committed and go home at 5pm every day - especially if you use a good methodology to control your projects).
In the open source world something like XP could be hell to implement. Something like DSDM probably goes out the window too - how do you prioritise requirements when people send in the code that meets the requirement at the same time as they send in the requirement. But successful open source projects have their own methodology too - they have mechanisms for reporting bugs, they have source control, they usually have a single person (or committee - but either way, a single point of responsibility) for determining what goes into the next release. How much of this constitutes management I leave to the Slashdot audience; that it is a methodology (however primitive) I will state with certainty.
~Cederic
ISO9000 done correctly is usefull, done badly it is worthless. Far too many managers think that ISO9000 is all about labeling things and having lots of documents - it is nothing of the sort.
Take a bug tracking system, can you:
Say with certainty that if a bug has been reported than you can find the report?
Know whether the bug has been fixed or not?
Know who fixed it (or is supposedto) and when and what they did to fix it?
Say which versions contain the bugfix and which do not?
If you can answer yes to each of those questions then your bug tracking system is fundamentally ISO9000 compliant.
Imagine that you are developing some software, do you know:
What is to be implemented?
Who is supposed to be implementing each feature?
What the design is?
What changes each person has made?
If you can answer yes to each, then your development is fundamantally ISO9000 compliant.
Quality has become a management fad, but at its heart, it isn't. It is about being organised, taking pride in your work and having a professional attitude.
If you build a system, is it a black hole that your sucessor will curse you for or is it well documented and well run, something your sucessor will thank you for.
ISO9000 tries to codify a professional attitude. If you have done chemistry, you will be familiar with the report format, Title, Aim, Introduction, Materials, Method, Results, Interpretation, Conclusion. It is simple, but it ensures that you say all you need to say and don't waffle. The idea is that you should be able to give the report to another chemist and they should be able to follow what you did, why you did it and be able to replicate the experiment without any surprises. The same holds true for other quality methdologies, your documentation should answer all the questions that a skilled professional might have.
ISO9000 as it was intended is very good, but ISO9000 as management fad is as bad as any other management fad.