I feel that I need to offer up a little disclaimer before we go any further: Discussing project health and management is very difficult to do with some co workers and bosses. Please go careful. Charging ahead convinced that you are right is likely to only end badly. Open ears lead to persuasiveness. Closed ears lead to a pink slip. Reading body language is just as important.
The Roads We're On
I've seen projects that were successful all the way through. Any hiccups were just bumps on the road and even freshly laid pavement's going to have a bump or two. Then there's driving in NYC... you manage to get through, but the going is rough and suicidal taxi drivers seem like they are trying to ram you into the East River. These are those projects that seem to succeed in spite of themselves. Other times, you feel like Roscoe P Coltrain in a Dukes of Hazzard episode... you just know you're not going to make the jump over the creek yet you try because if you don't Boss Hogg is going to tear into you. These are the projects that are going and going, but everyone knows what's coming and yet people keep pushing for whatever reason until finally the plug is pulled and you're all scrambling to not be the one who gets to be one of the ones canned.If life were simple, you'd know which type of project you were on from the get go. If it was all going well, you'd happily keep with it til the end and pat yourself on the back. If it was rough, but survivable, you might stick it through figuring you might get some kudos for pulling it off. In reality, projects rarely stay on the same footing, but you rarely see it trend upwards. Either a project is good all the way through, or it just gets steadily worse. Call it project entropy... unless something else influences it, it tends to degrade over time. However, if we understand what's going on and keep a higher level view of what's going on, we might be able to act to correct it.
What goes wrong?
Phaser Burns
This downhill trend of projects is something I 've seen tend to happen in phased projects. During phase 1, you're primarily focused on getting something done. Proving the basic premise, getting a rough architecture mapped out and executing on the first set of use cases/user stories/whatever you call it. This tends to be busy, but the atmosphere isn't uptight and things tend to go ok. Phase 2 is where trouble begins. Brooks calls it "the Second System Effect" but I think there's maybe more to it. Please go read Mythical Man Month. It may not be spot on all the time, but the observations are still often valid 30+ years later. His main point in Second System Effect, and I pretty much agree with it, is that everything that was highly desirable but not mandatory got cut out for version/phase 1. Unsurprisingly enough, phase 1 goes reasonably well and delivers on time. In version/phase 2, there's a tendency to pull in far more than can be accomplished and failure mode starts to set in. What was once a great example of how to develop software now becomes a boondoggle.A few things contribute to this. Obviously, biting off more than you can chew is a huge contributor. But how exactly does that happen? We're all intelligent adults and most of us aren't too terribly masochistic. Thus, we can cut out the overt psychological oddities and focus on more subtle issues.
The Inevitable Gold Plating - Gold plating is of course a major curse in software development in general. It tends to be at its worst in phase 2. All the 'nifty stuff we didn't have time for' now is in scope and the laser like focus you had in phase 1 diffuses as every 'brilliant' idea someone had starts to get to be a must have. In reality, business value's not there, but resume stacking is.
Good Old 80/20 - Quite simply, there's a subtle mental push that everyone feels even coming from within themselves. In phase 1, where your focus was on what was an absolute must have, you probably were cutting edge cases left and right. This leaves phase 2 with an incredible backlog of 80/20 ruled features. You know the 80/20 rule: 80% of the features are done with 20% of the work and 20% of the features take 80% of the work. Yeah, its just nice round numbers, but it communicates the point... edge cases often consume far more time than the main features yielding a low return on time invested. Contributing to this is that subtle mental push I referred to. Let's call it the Feature Counting Effect. This is brutally simple and goes like this: "In phase 1, we were able to deliver 20 features. Therefore, in phase 2, accounting for variability, we can plan on at least 15 features." Alternately, you'll think "you've learned some lessons" and instead plan for 25 or 30.
Go read that bit about the 80/20 rule again... if that's true you should only be planning FOUR features! After all, you've 80/20 ruled out some hard, but still pretty important, features. Go ahead, tell that to the boss and let me know how it works out... Of course you'll have to use your personal email address for me to reply to you because after they can your rear end, I won't be able to use your corporate email.
Cheaters Get Caught - Little known... err... widely known fact: No software project gets done without a compromise or three hundred along the way. Ok, calling it cheating is harsh, but the reality is that very often, to get past today, you don't have time to polish everything up to the point that you're really happy with it and you know it's going to come round to bite you. Sometimes, this turns out to be Gold Plating and YAGNI. But, almost always, there turns out to be a few features that have turned into dead end sin terms of being able to be extended to accomodate new functionality and you'll have to re-work them. Ok, this often occurs irrespective of what phase of development you are in. However, it's more likely to become an issue when new requirements and scope come into play. At any rate, we should always be willing to refactor to improve the internal quality of our code. Sometimes, it's just a lot more expensive and a lot less optional than others. All of this adds to the investment you need to make in phase 2... the larger the amount of code you have and the more users of the system, the more it costs to make any changes. (One of the prime drivers for refactoring in the first place... clean your junk up).
Your Boss's Boss (Political Commitments) - Let's face it, external commitments get made. Sometimes, to get agreement to go ahead with phase 1, the Boss needs to tell the Big Boss that he's going to get a feature in phase 2. Sometimes it's not Big Boss, but the Other Sponsor, etc. Anyway, there's a reason sometimes that 'not quite mandatory, but we better get it' feature is pushed out to phase 2: it's hard! Or, it's really not a good return on investment. The only value is because someone with a lot of weight to throw around wants it and this is going to drain time away from other looked for features in phase 2. At any rate, the premise here is that sometimes phase 2 ends up 'oversold' before phase 1 is hardly under way. Said another way: phase 2 is already doomed while phase 1 is still a long way from even being code complete let alone tested and shipped. This is all because the idea that "we'll deliver it in phase 2" was the convenient answer to anything that couldn't get put into phase 1 leading to significant overselling. Been there, done that, now you're reading my novel.
Piling on the "Help" - When phase 1 is seen as primarily exploratory, the temptation of the Bosses to throw more people into the mix can become irresistible. Surely, we can accelerate development by throwing more bodies at the keyboards, right? This what I call "World War I" methodology. It is this sort of thinking: if you have to cross an empty field with machine guns at the other end, then obviously the best way is to get as many people to cross the field at once hoping there will be too many targets. Needless to say, it didn't work in WWI and it doesn't work in software development. Sure, there are times to use more people, but I've not seen too many cases where growing the team rapidly works once the project is in flight.
All analogies aside, what happens is that in phase 1, you've usually got a small team where communication, knowledge sharing, group design, etc all happen naturally. During this time, people settle into roles and everyone knows who knows what. The team gets to know one another and start to achieve some level of that nirvana of not needing to talk to one another to know what they will do as a group next (I did say some level). Now, double the team. This is putting new wine in an old wine skin... it will not work. All those connections that have been forged over time will be broken.
Furthermore, I don't care how much time you waste on documentation. There will always be bits of the system that will primarily be stuck in the head or heads of the team. I might be able to document the system I built to the point that when there is a bug, some random person can read the document, figure out where the bug is and fix it. But, take the same random person and ask them to add a new feature. Sure, they can do it, but they will do it by integrating their brand new code into the system. They will not know the 'tweak this, extend that, refactor over there' that will get it done in the context of the system in a fraction of the time. Sure, over time, they will get it. I'm just saying it's foolish to think they'll get there quickly.
It Was All Bad
Sometimes, it's not a downward spiral. It's not even a slippery slope. It always is bad and that's all there is to it. You've probably already decided that the reasons to tough it out exceed the reasons to bail out and are going to ride this horse for what it's worth. But, what's going on here? We're all intelligent adults and most of us aren't too terribly masochistic... wait, I'm repeating myself.
Anyway, usually, you'll see the same factors creep in while you're still in phase 1 or whatever you call it that you see in phase 2+ as factors that doom you. Certainly, over commitment is a problem anytime you run into as is Gold Plating and other activities that don't add value. So, we can put all those reasons on the list.
Above that, there's a few other issues that can come into play.
Analysis Paralysis - When you get so wrapped up in thinking about the problem, you over look the truth in the old cliche "the best is the enemy of good enough". This is so classic, I'm not even talking about it any further here. Go here instead.
This Project That is too Important to Fail - If ever you hear those words about a project you're on, run. Don't walk. RUN! "This project is too important to fail" is a code for "Paranoia, Sloppiness and/or Egotism will cause us to make one bad decision after another." Seriously, I think I've seen at least three projects fall into this category. The project is "mission critical", so no resource will be spared so when there's the inevitable hiccup: the meetings that follow will distract the team and suck away crucial resources. Furthermore, inevitably, "momentum" and "positive attitude" start to take over and it's almost eerie how the decision making process begins to cave in. Add in all the other factors, and you're playing jenga on top of only one block. It's not the importance of the project that causes it to fail as much as the fear of failure. Basically, no one wants to sound like the one that is being negative and contradicting leadership or take on the political heavyweights. So, the small problems grow and grow until they consume the project, and the result is inevitable: Projects that are too important to fail usually do.
Everyone Wants In - These projects often also are the ones "too important to fail." Guess the story here: It's important so lots of people want in on the action. It's going to make the careers of people who are involved, so the proverbial wood work is working overtime. Everyone who can fabricate a reason to be on the project or better yet, 'advising' the project is there. The kindest way of looking at it is that you run into the Piling on the "Help" issue. The unkind way of looking at it (and more true) is that many (not all, or even most) are assessing their political/advancement prospects far more than their actual skill and contribution. At best, they are dead weight. At worst, they aren't content to follow the leader and want to be the top dog. I can't complain too much about someone who is making a full contribution even though their motivations may be bad. What causes problems is when they spend more time on their ambitions than the team and the project.
Now, teamwork really just comes down to mutual interest. Altruism rarely factors in for most people. We all are on a given project because it benefits us to do so. However, when someone is only on the project to reap and cares little for sowing, it's now a problem. What really becomes a problem is when someone's idea of reaping is not even letting the crops grow! Now, it's common to see large, important projects have some level of observer/adviser appointed by senior management to be their eyes and ears. That's ok, if a pain. But when someone places themselves in the role and refuses to budge, you now have a problem. This is the kind of person that makes Everyone Wants In projects bad. They don't contribute, but they sure make noise. When they start degrading other people's ideas simply because they aren't their own, the project is all but doomed. Avoid these folks, and Everyone Want In may not be all that bad. Presumably, it means you get to pick the most talented people available. However, if the talent selection process fails to weed out those who are here to take but not give, it's trouble.
Solving All the World's Problems - Ok, realistically, no one starts up a project thinking it will solve all the world's problems. However, quite often, the project's goals are overextended before it even begins. Honestly? Every project probable has more ambition than it's going to actually deliver on. It really only becomes a problem when the level of ambition turns into expectations that will not be satisfied. One way I've seen this manifest on several occasions is when what I like to call "false reuse" occurs. This happens when you have two or more stakeholders who describe their problem statements in very similar terms. In short order, the impression that everyone's needs can be satisfied with one project begins to get stuck in everyone's heads. Unfortunately, their problem statements may have been "I need to be able to produce a document I can print". They miss out that whole bit about what the document is and you end up trying to build a spread sheet and word processor all at once. We also run into this idea of "false reuse" at a code level, but it's a lot less damaging (still bad though).
We Can Solve Our Own Problems - This one is may be the worst. On one hand, the team may be facing an issue that it can't resolve by itself, but keeps trying to resolve itself. On the other hand, the team may be asking for help, but for whatever reason, the message never makes it out. I identified this in Faces of Failure as the "All Mouth, No Ears" type. There's a project manager who has sold the higher ups on a vision, a time line, a budget, whatever. But, reality and vision aren't lining up and they won't take the message out. Frustratingly enough, when I've run into this in the past I've also seen instances where the higher ups would have been happy to hear about the problem and readjust expectations! The project ends up dying because someone without the brass to look the Big Boss in the eye and say "it's not going to plan" early is in between the team and the ultimate decision maker (this isn't always the Project Manager, they are just in the role where it's easiest to do this).
Of course, if you are the project manager, you pretty much are going to get blamed anyway. Avoid the failure if you can and so read on. Keep in mind I'm not really writing towards PMs, I'm writing towards the everyone involved in software projects which by shear dint of percentages is mostly the developers, testers, implementers, etc.
Throw Yourself a Life Line... or... Go Down Guns Blazing
So, another long article and I've managed to talk mostly about failing again. Wasn't this one supposed to be "Rescuing Yourself?"Oh yeah.
You see, it doesn't have to be a downward spiral. On occasion, I've seen a project rescued. So what do you do when you find yourself in the middle of a project that is dying? Or, what was good starts to become bad?
Don't Go There - I've never seen a project where the team worked well together (at that nirvana of knowing what to do together often without discussing it) fail. Note, that is my experience, I'm sure someone will contradict me. However, I've seen projects where the team that worked well together got split apart by all those other factors creeping in. Working well today is no sign of working well tomorrow. In general though, always keep checking the pulse. It's a truism, but it's easier to solve a problem when it's still small. But, that's not really the answer you were looking for, was it? You're already in failure mode, which leads me to:
Don't just do something, stand there! - That's the old HazMat advice and poking around the interwebs it looks like someone wrote a management book to that effect. I haven't read it and so can't recommend/endorse it. Anyway, if things are looking grim, first thing is to ask yourself "Why?" Look around for some of the factors I've discussed in this series. Some of them have obvious answers. Other's aren't so obvious. But, you need to understand the cause before you solve the problems.
Talk! - I wrote about the Complainer in the post on the Faces of Failure. You don't want to just complain, but you do want to open a dialog with whomever you can. Ideally, you get everyone involved. Often, this won't work. You may have an "All Mouth, No Ears" somewhere in the chain of command. You may have a Pacifist who doesn't want to see conflict, or a Warrior who is spoiling for anything to fight about. But, for the most part, you may be surprised to find out that even if others aren't seeing what you're seeing per se, they really want to talk about it. Lunch is the best team building exercise on the planet.
Blow up the Dam - A bit the opposite of "Don't just do something, stand there". Sometimes, you just need to stop talking and do something! You've ended up in a situation where for whatever reason, the project is just gaining any ground. Once you've identified an impediment or two, get rid of it. The larger the project, the more likely you are to have needless bureaucracy (see Everybody Wants In). Do what you can to get rid of it. Also applies to Analysis Paralysis. Sometimes, the best way to solve the problem is to start writing some code.
Use People Effectively - Outside of obvious things like not engaging people in useless tasks, think of more creative solutions when you need more people. Rather than adding yet another coder, you may need someone just to manage the build process and deployments to staging. You may be surprised how much time this eats up. Rather than having it take 10% of 10 people's days, have it take 100% of one person's day (ok, the math rarely adds up so evenly, you get the point though).
Be Formal Enough - A myth of Agile Software Development is that there is no documentation in an Agile project. The reality is that the Agile Manifesto says only that we should value
Working software over comprehensive documentation.You are seriously misreading the Manifesto if you take that to mean no documentation. One of my Rules Regarding Everything is that "the more people you have, the more formal you need to be". In short, the more people you have, the more you need of things like documentation, task tracking, etc. Add distance into the equation, and it only goes up. Trying to substitue email and Excel for proper tracking doesn't scale, and trying to keep it all in people's heads is just begging for trouble if nothing else. In short, not adding a little formality can actually cause you to do more writing.
All Requirements Are Subject To Change - Seriously. Work on understanding needs not requirements. Lots of times, someone put a requirement down because they were trying to envision a way of solving the problem. If you have an easier, cheaper, or better way, talk to them, and...
Above All, Chutzpah - I have to throw some Yiddish in somewhere, don't I? After all, I grew up in the Borscht Belt. Anyway, Chutzpah is simply "audacity".
Without courage, you are just saying "walk over me". Many failed projects are savable, but someone doesn't stand up to say "enough". If you're the developer and all you do is say "yes I can do that, yes I can do that, yes I can do that." Don't be surprised when you can't do it anymore as work piles up. Meanwhile, you're only transmitting the message "I have more capacity." If you don't have capacity, if you have to work lot of overtime to get it done, SAY SO! This is probably a separate article by itself, but people can work O/T only so much before they melt down mentally.
If you see there are other misbehaviors/malfunctions in the team, you need to step up to the team and constructively take on the issues. If external influences are driving the issues, you need to start talking up the food chain. I've seen it happen many times that people just didn't know how complex etc something was that they were asking for. When I've traced the requirement back to the source (this can take some fighting believe it or not), its very often very negotiable. Talk and be courageous!
Being courageous is not being pigheaded and it certainly isn't being a cowboy. You need to listen to others, be ready to admit you're wrong, etc. However, while I say it's not being a cowboy, it may take some creativity. For example: sometimes your problems are processes that don't make any sense for what you're doing on this project. I've generally been successful by complying, but isolating the impact of those processes on day to day activities. Showing compliance in the battles you can't win also helps you in the battles that you can win. If folks think you're reasonable, they're more likely to listen when you say something is a problem.
Keep Your Skills Sharp, Soft And Broad (Ready to Relocate?) - All statements about courage etc aside... if you have a sense of project failure looming, you better load up the resume machine. You probably don't know what will happen in the end. Most software folks I know who have a hard time getting reemployed have let themselves get over specialized. Keep your skills broad, not just all technical. I've also found being ready to relocate helps a lot, but isn't practical for everyone. Also, keep in mind that changing jobs/projects isn't always the same as leaving the company! One more reason to be courageous, but level headed.
Anyway, this ran a LOT longer than I thought it would. As usually, probably 30 typos that I'll fix tomorrow or something. Adios!
Posts
0 comments:
Post a Comment