Are you a pointy haired software manager?

Ah, managers… We all love to hate management, until of course we join its ranks. Then we like to think we are different from those other pointy haired types, but we fail to see the evidence to the contrary.

If you recognise some of your own behaviour in the anti-patterns in this article, it is time to re-evaluate! Admitting you are a pointy haired boss is the first step toward better management.

What’s in a name?

Like it or not, for humans , names are very important.  When you first start working on a software project,  finding concise names for all the logical objects in your domain is very important. Acronyms and synonyms are bad; their only purpose is to let inept people hide behind them.  Coming up with names that work for everybody in the team is the manager’s responsibility; software architects are usually too bombastic  to be any good at this and they need someone to force some common sense into them.

Software developers and testers use names to put the little piece of the project they happen to be working on into context.  When a person is looking at the code for a class named “InsurancePolicy”, a vast amount of implied knowledge is tied to that name and will influence how the person interprets the code.  If you start referring to the InsurancePolicy objects as Contracts, you will confuse everybody and a whole lot of time will be spent trying to figure out exactly what you mean by Contract and how it may differ from InsurancePolicy.

Don’t waste time and quality by being confusing!

As a middle manager you can do a great job naming everything in your project’s domain, only to have upper management force you to accept really dumb and confusing names at the last hour.  Executives likes to control product names and along with it, the names of the marketecture concepts used to pitch the product.; it is their way to “put their mark” on it. Often the product name and the marketecture are decided as late as possible, to be responsive to changes in the market place. Not much you can do about it: if your software team decided to use the term “node’” to refer to a controller and executives go to market with the term “director”, you can expect every feature request and customer conversation to use “director” and your developers will soon be renaming all instances.

The naming buck stops with you! You should stick with the old naming convention until you decide to switch to the official terms, and plan for a proper renaming cycle.

Changing the wheels on a moving car…

Having an Agile development team means that the time between a requirement rising in priority and its feature being available can be relatively small.  But it can not be days. You are not allowed to make changes to requirements being implemented in the current sprint for a very good reason: reacting to changes can only be productive when the team has at least a few days to plan things.

If “next sprint” is not soon enough, it is not worth doing!

You may think that what you are asking for will only take half an hour. But your opinion on that matter is irrelevant; you really only know how important it is, not how much effort it will take and certainly not how it will impact all the other things your team is working on. Don’t even bother asking your team to look into it; they will under-estimate the effort and impact in order to make it happen.  If it is super important, put it at the top of the prioritized backlog and work on the requirements so that it’s ready for the next sprint planning meeting.

If the environment you work in forces you to be reactive and respond within days, you may want to consider having one ‘SWAT employee’ dedicated to putting out fires. This employee can produce emergency code and later bring it to the rest of the team to get properly integrated into the product in the normal sprint cycle.

Work tickets instead of requirements

Busy, busy, busy! Must tell that project team what to do! I’ll quickly bang out some enhancement requests to get them going.

That kind of attitude will only get you bad software and budget and timeline failure. As a middle manager, it should not be your job to tell people what to do and keep them busy on “important stuff”, you should be trying to maximize your people’s output by clearly defining success, providing everything they need to reach that and then staying out of the way as much as possible.

Page 1 of 2 | Next page