The best way for any software group to work is complete openness and honesty regardless of the development process. Agile, scrum, waterfall, spiral whatever it is, being open about the work being accomplished daily, the road blocks your facing and any concerns you have is the most efficient way for a team to be productive. This has to work all ways though. If a developer is going to be completely open to our management it requires management to be completely open with us, as well as their management. Unfortunately this often is not the case, so what should you do?
Skip the long description of the problem and jump to: How to Manage Your Manager
Management Malfunction
When developer management is a former (or sometimes active) developer, the development teams can mesh and work better as we all understand the concerns, conversations and best practices in the profession. When direct management has little to no development background, the relationship can be much more complicated.
What can happen is developers are open and honest about where they are on their features, along with the risks. Management will often quickly dismiss the risks (or sometimes flat-out ignore them). There is many reasons for this, one of which is they simply don’t understand the complexity of the problems and simplify the concerns we express. Over time management will start to force features to be pushed out sooner. They will start promising the client (or their management) what should be interpreted as very optimistic goals as certainties. Slowly development cycles start to get shorter, peer reviews start to be treated as a commodity and not a requirement, testing time gets shorter, and the development environment is simply miserable.
This is where we should start to consider how to manage our managers. If being 100% open is causing the code to be more fragile, producing less stable products, or even just lowering moral for the developers why should we continue to leave software decisions up to those who are not experts on software? Why as developers do we feel obligated to explain enough detail to make management comfortable with pushing features while letting them ignoring everything else we try to explain?
Managers Don’t Micro Manage Other Pieces of the Puzzle
[quote style=”boxed”]Why does management feel they are capable of making software decisions more so than the developers?[/quote]
Lets consider other decisions software managers make where they are just as non-qualified yet seem to not interfere with the process as much.
The web/application server. System administrators have set up tens of systems and when they set the next one up they will let you know when its ready. I don’t find management trying to cut them short. The SA’s will set up systems to be as stable as possible, keep the web servers running, automatically restart and setup monitoring, then they will let management know its ready. Management doesn’t ask for a day by day, “whats running, ignore the monitoring, I don’t care if it starts up on its own, don’t worry about the cluster today etc.” When the server is running, it’s running, the SA’s are the experts and managers often respect that.
CVS/SVN down? Start working on getting it back up, let me know when its done. You don’t see management forcing half solutions: “Can you get it so they can just check in the next release, I don’t care about past history?” The change management (CM) team are the experts and they will let management know when its running as it should. They are the professionals of the change management process.
When they get their car worked on they don’t ask where the mechanic is hour by hour, “don’t worry about that head gasket its been working fine.” When it’s done it’s done, they are the experts!
Why does management feel they somehow are qualified to make software decisions more than the programmers themselves? I don’t know if I will ever understand that mindset, but more importantly to me, how should we as developers manage this problem?
How to Manage Your Manager
We as developers are the experts. We know whats best for the software, what processes need to be done for it to be successful and to keep it stable as well as maintainable. No one else does. So we have to be responsible for the decisions relating to it. Management asks where you’re at on a feature, use percentages, daily estimates, and quantify resources needed. “I am halfway done. I am estimating 5 more days, and I will need someone from the UI team to help hammer out the details to make that estimate.” That’s it. You’re the expert, you know that you are 1 day away before you feel the code is done, but that undoubtedly there is going to be a bug. You know that a peer review from the UI lead will discover side effects you never considered that you need to further test. You know you will have to merge all your code and write some unit tests for future maintenance. Why do you need to explain to your management the feature works on your machine and give them an opportunity to overlook everything else a professional knows needs to be done? Don’t give them the opportunity to assume they are more knowledgeable than you on what the software needs.
We as developers are the experts that management should be consulting. We should be the ones saying what happens with the software. It can be interpreted as irresponsible for allowing non-qualified individuals make critical decisions in what we are creating. With full control comes full responsibility. Many developers are not confident in making the decision on when the software is production ready and since management often forces our hand we can separate ourselves from the decision and take no responsibility. If we want to say how things are run then we take responsibility for the out comes.
Whenever this comes up I am often told that I am encouraging lying and deceiving management to get my way. I don’t believe this to be the case. Again, we are the experts that are being consulted by management. If management is irresponsible with the open and honest approach, ignores the desires and cries of developers and approaches the problem as if they are somehow more knowledgeable than developers, then they need developers who are professionals and tells them what they need to hear. Just like they are trying to tell their management what they need to hear: “The project is making great progress, were going to deliver early etc etc.” We need to tell them what they need to hear: “The project is x days out and expect these feature sets.”
Wrap Up
I want to conclude by circling back to the intro. I believe daily scrums, with 100% honesty, and constant feedback up and down the chain is the most effective and efficient development environment. See Robert Martin’s Agile Software Development for one of the best development processes (he describes my ideal solution). Sadly many enterprise and government software teams are managed by non developers who frankly are not software experts. They can still lead a successful project but we need to be taking the responsibility as professional developers to recognize our management needs more direction than they realize and tell them what they need to hear. Help manage your management and take ownership of your profession.
