As the software development manager and chief architect for a mid size financial firm, a regular part of what I do is translation between business and technology management.
Despite the fact that more and more is possible, and engineering staff are increasingly productive, the gulf between business and technical management remains one of the most difficult gaps to bridge.
This gulf in understanding is destructive. Business management often views technology projects as opaque and unmanageable ( high risk) Couple that with the expense and it should be no surprise that managers often prefer outsourcing of software projects for cost reasons as well as risk management- an outsourced development which goes awry is a problem for legal..an insourced project is a managers direct responsibility.
The reality, of course is that actually delivering and building software is a complex and difficult game. Doing it across continents, timezones and language/culture barriers doesn't make it easier. If we add in the element of magical or unrealistic thinking coupled with a general ignorance of how building software works...well it starts to be clear why so many software projects fail. In this post, I'd like to touch on my favorite management fallacies. These are in no particular order however they are all favorites of mine.
1) Technical people are fungible
Huge mistake. Most projects are built by 1-5 people, and the best results are generally achieved by several areas of expertise working together. The right team skillset mix makes or breaks a project. Very often, the wrong skill on a task can bring a whole project down.
Projects should be self contained, and if possible all the skillsets required should be present on the team, or assigned for the duration of the project.
2)The project can be completely defined up front
This might be true given enough time and money, however in most cases software evolves over time. The understanding of a business problem at the beginning of a project is often changed by the time the solution appears. This is true of almost any invention - look at bicycles, for example..but in software it happens over the course of its development.
Iteration, and continuous refinement will happen, and should be supported by the management model for projects.
3)Technical people are fundamentally lazy
I sometimes believe that nontechnical managers really believe this, based on the way that project schedules are negotiated. There is never a willingness to consider that maybe the people who have the most direct involvement in writing and testing code are the people in the best position to understand what a given project takes. The fact that a non or semi technical manager has an understanding of the design and implementation does not immediately translate into a true ability to assess the overall difficulty. I have never been in a project schedule review meeting where a non technical manager accepted my schedule. Thus, by long indoctrination, I always pad my schedule.
If anything, in my experience what actually happens is that projects which developers find interesting or believe will be used are underestimated..projects which the reverse are overestimated. Heaven help you if you are a lead and have a boring but mission critical project to get done.
The most important thing you can do to get high performance is to identify work which is truly meaningful to the business and the users it serves, and to keep developers engaged on it in areas that they are good at and if possible mostly interested in.
4) Having QA as part of a development team is letting the fox watch the chickens.
This is one of my favorites, because the underlying assumption is that developers like to ship crappy code. Good developers HATE defects. I have rarely met a developer who, through laziness or a general lack of interest was content to consistently ship defective code. I don't believe developers who operate this way last very long, anywhere. In my experience, most developers are very concerned about testing, and have a deep desire to ship solid code that works and is easy to operate. What they need is help in getting there.
An external QA organization isn't that help..organizationally, its a setup for non stop conflict. Metrics get developed which are used against development and an excuse culture sets in. QA cannot be efficient unless it is staffed by at lease junior caliber developers who can effectively automate tests. Effective automation starts at unit testing and code coverage, so in essence QA starts in development and grows outward as components are integrated. In short, the fox and the chickens are on the same team and likely have very similar technical skillsets in an effectively managed development organization.
Build a product team around developers and testers working together, consistently, around the same code base over time.
5) Putting high pressure on target dates and development managers is what makes projects ship
Or "the beatings will continue".....this is perhaps the worst assumption. You can rarely get good quality work output during the bataan death march.
A business manager can ALWAYS get project schedule concessions through the whole first half of a project from a development manager - through a variety of bullying techniques including -
"If thats the date the project will be cancelled" - it never is...
"Your job is on the line for delivery" - it always is...
"If you can't do this, I'll find someone who can" - possibly, but you'll treat him or her the same way, and nobody is superman
Or my favorite - You gave me an answer i don't like, so I will poll your whole team looking for someone willing to undercut you.
Or last, thats the date, and we'll work the team continuously including weekends to hit it. - never really works.
This approach trains development managers in a technique I refer to as "incremental dissapointment". At the start of planning, a development manager is asked to assess the timeframe for a project. If hes dumb enough to just provide one which is realistic, the bullying will commence.
If hes really dumb, or just starting out in his or her career, he'll hold firm.....in which case he has created an opportunity for a third party consulting firm to quote a better date, or for someone else to lead the project. The smart move is to compromise on a date which the business manager will accept, with conditions that the business owns and will completely undersize (requirements/design review) in terms of time.
This all sounds horribly cynical, but it is a survival model for dealing with dysfunctional business management..remember, the starting assumption coming in is that you and your team are lazy, so you have to be "motivated" properly.
SO my advice to non technical leadership. Trust your technical leadership as a partner..if you don't, find a new partner.
These are just a few of my favorites..next post, I'll be focusing a whole entry on "why do we need developers once the code is written?"
-- Post From My iPhone, typos included
No comments:
Post a Comment