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.
Bugs, enhancement requests and user stories each play a specific role in the development cycle. They each have a writing style suited to their purpose, and NONE of them should read like a work request. As a manager, you cannot possibly know the scope of the work required to fix a bug or implement a feature. Pretending that you do will cause you to make bad decisions and wreck team morale. Your time should be spent on sorting out requirements and priorities and you can not afford to be involved in work scheduling.
You should be using “Why” at least 10 times more often than “How” and “Who” in your daily conversations.
You should have a vision for the product. And all the requirements and user stories should include an explanation of how a particular feature fits into the vision. It’s hard work and your vision will probably need readjustment a few times during the course of the project, creating even more work. But somebody’s gotta do it!
Attack of the stakeholder from hell
Some end users or stakeholders like complaining a lot more than providing feedback. You can easily identify them as the ones who have no time to review your proposal or to test the software before it goes live, but who are shouting “I told you so” when things go wrong in production when, in fact, they never told you anything. Do not let your team deal with these end users! Yes they need end users to create requirements and validate the product, but bad end users are worse than no end users at all.
Finding useful stakeholders, or converting the pesky ones into useful ones, is like herding cats as my old boss liked to say. It is a hard and thankless job, but its crucial to the success of your team. If you feel that you are not in a position to refuse a belligerent stakeholder in your project, you better work on converting him or her!
Isn’t the manager supposed to be the “people person” who deals with that?