For example given two drunk drivers going home, the first driver gets caught and recieves a DUI, while the second driver as a result of being drunk hits and kills another driver will get charged with both a DUI and manslaughter. Now both drivers took the same risks and for chances not under their control had two different results, while we can morally blame both drivers for the same actions we choose to punish them differently.  This is refered to as resultant moral luck, are you building your software with it?

Just because you delivered software last time that was on schedule and worked correctly, was it just moral luck? Knowing that there are ways to improve your development process and improve your code quality as to reduce the risk involved in creating software, are you still not using them? Not using them is not calling your friend to drive you home from the bar, yes you know its a good idea but you got home safely last time so you don't need to this time.

Should you be accepting moral praise for a project from the business, when the result was less in your control then it could have been? Clearly building a trivial website for a hobby has minimal risk but if the software you are building for a business is of importance, must you wait for a the dice to come up against you before you try to do better?

When have a deadline approaching, you work all night.
When you work all night, you don't get enough sleep.
When you don't get enough sleep, you turn into a zombie.
When you turn into a zombie, you start eating your co-workers.
Don't eat your co-workers, get rid of waterfall.

When you try to generate an accurate project timeline you start guessing.
When you start guessing, you start grasping at straws.
When run out of straws to grasp at, you look for more.
When you look for more straws, you go looking through trash.
When you go looking through trash, you find yourself in a dumpster.
Don't go dumpster diving, get rid of waterfall.

When you plan too much, you can't make decisions later.
When you can't make decisions later, things will need to change.
When things need to change, you need to change directions.
When you can't switch directions, you drive off an oncoming cliff.
Don't drive off a cliff, get rid of waterfall.

When you estimate a feature wrong, your boss wants you to improve.
When your boss wants you to improve, you practice estimating.
When you practice estimating, you estimate how many tacos you can eat.
When you practice eating tacos all day, you spend all night in the bathroom.
Don't spend all night in a bathroom, get rid of waterfall.

When requirements can't change, the customer wants to change them.
When the customer can't change them, the customer gets mad.
When the customer gets mad at you, you get mad.
When you get mad, you go home mad.
When you go home mad, your mother in-law stops by.
When your mother in-law stops by, she tells you everything you are doing wrong.
When she tells you everything you are doing wrong, you punch her in the face.
Don't punch your mother in-law in the face, get rid of waterfall.

“Will you be able to bid by the 20th, so we can accurately plan the project timeline, budget and compare all bids?”

“Please include SDLC phases, a project timeline in months, your roles for this project, total hours to complete the project and grand total price.”

I had imagined that the dysfunctional days of the RFP (Request For Proposal) in software development were gone. Man, was I surprised to see an Executive-level IT Manager still committing the irresponsible mistakes that have driven software development projects to failure over the last 40 years.

So who uses the RFP model? Where did it come from?

1)      Construction industries – who have known, repeatable processes with supposed predictability but who still have a 90% failure rate on estimates.

2)      Sleazy sales people – who are not interested in software value – only their commission.

3)      Government – whose addiction to waste should never be used as a business model.

And we all know this negligent game – toss out the lowest bid, toss out the highest bid, haggle on rate, fabricate timelines, pad estimates, rush to an arbitrary deadline, work 80 hour weeks and then celebrate project survival.

But what are we really bidding on? A contractual guarantee that change won’t occur or that punishment should ensue? And what if change does occur during the project?

An RFP will guarantee you fixed time and cost, but here’s what else it will guarantee you:

Waste. 68% of IT projects are NOT completed on time and budget. (Only 32% of IT projects are completed on time/budget, 44% are completed late and over budget and 24% are abandoned. Source: Standish “Chaos Report” 2009.) You are not exempt! Your RFP will ensure your inclusion in this statistical failure – despite your belief that it’s the remedy. The RFP is part of the continuing cause of these wasteful company practices. Can you really afford to be a statistic in this economy?

Disgruntled Developers. The inability to move a timeline or cost means employee overtime to meet what was well intended guesswork on software that hasn’t been created before. Good developers in the .Net space are a rare commodity. Treat them well. They are almost as recession proof as beer and can work almost anywhere they like. Managers/owners who view them as replaceable commodities will deservedly incur the cost of knowledge loss and replacement learning curves.

Disgruntled Employees. Change is inevitable and it’s a naïve manager who believes that employees won’t go directly to developers to secretly request changes to their original scripting in that almighty RFP. It just means the developers will have to sneak it in and work longer hours to help out the users. They both know they’re on the same team… Why don’t YOU?

Disgruntled Accountants. Sure, you’ve made the accountants happy up front with the RFP temptation of “set-it-and-forget-it” budgetary “predictability”, but experience should tell you that you have created an inherently wasteful, poor quality product that will have ill-effects beyond delivery….perhaps even before delivery. The accountants will ultimately be disgruntled because what they thought was a finished product is not. In fact, many more maintenance projects will amount to many times more than the original RFP. The cost of that original RFP will also spill into other projects in the form of Technical Debt.

Disgruntled Customers. Fixing project cost creates measureable business cost in the form of customers who prefer to use your competitors’ products. It doesn’t matter if your customers are internal (employees) or external paying customers. Your “internal customers” will pass on a poor software experience to your paying customers. (How many times have you had that experience passed on to you over the phone? “I’m sorry, the system isn’t able to …”) You will pay for it either way. RFP’s ensure that customer-driven requirements will take a back seat to the time/cost commitment of the almighty RFP. A company’s inability to adapt “the plan” and pivot/respond to real business customer feedback cycles guarantees poor quality software and a poor client experience.

Disgruntled Ownership. Antagonistic relationships between developers, employees, accountants and customers make for disgruntled Ownership. Creating a company quagmire from an RFP seems at odds with good entrepreneurship. If you are a business owner, and your IT manager is proposing a model like an RFP – understand that it is at odds with the very nature of software.

Fired Managers. Managers playing the RFP game are not interested in value…only cost. They are interested in following the plan – not the ability to respond to change. They are more interested in comprehensive documentation – not iterative working software. They are more interested in contract negotiation – not customer collaboration. These are all things that the Agile Manifesto addresses. Do yourself and your career a favor. Learn better software philosophies. It will save your job.

RFP is NOT the right model for software development.

And it never was! IT professionals have always known the irreconcilable disconnect between guesstimates and the reality of coding. Listen to them!

Let’s stop this awful, wasteful practice. We’ve learned so much from the failures of this system to be perpetuating this harmful, wasteful approach to software development in this economy.

I have an idea. I’d like to redefine what RFP really means to companies. Here’s a handful of options – feel free to add your own.

·         Requesting Failure Please?

·         Recreate Former Problems

·         Ready For Pain?

·         Request For Panic?

·         Request Flawed Performance

·         Request Flatulent Product

·         Run For Parachute

·         Randomly Formulated Plan

·         Really Faked Projections

·         Reassess Failed Philosophy

·         Restart Failed Project

·         Random Firing Permitted

·         Repress Future Profitability

·         Rewrite Forced Programs

·         Rework Fanatical Projections

·         Remember Former Pain?

·         Recently Failed Project

·         Refund Financial Profit

·         Regret Faked Promises

·         Richly Formed Prank

·         Relic From (the) Past

Let's take a quick look at a scenario that happens all too often in the business world…

1.       Company has process/culture problem.

2.       Consultant brings in new process.

3.       Company loves new process.

4.       Process fixes problem.

5.       Consultant becomes hero.

6.       Company thinks Consultant IS the process.

7.       Company becomes dependent upon Consultant.

8.       Company doesn’t want to let Consultant go.

When it comes to software developers, we live in a town that gets attached to individuals.

Often we start as consultants and over time bleed into staffing models.

It’s somewhat revealing about what clients truly want.

And it’s cultural. It has to do with trust and execution. After being at a client for awhile, the Consultant's messages – and what their Company stands for – become replaced by the hero culture of the individual.

There is a portion of this that’s knowledge work and we fear that change of personality presents a loss of that knowledge. We worry that it will create uncertainty in our daily continuity. That’s understandable. We start to imagine that the daily operations of the new process can’t operate without the Consultant on hand to make it tick. But other individuals have knowledge too, so perhaps the real fear is that we might be losing someone who can save us in dire circumstances.

The fear of losing the hero as our "Ace in the hole".

The intention of having a consultant should be to help companies course correct and become self-sufficient with new approaches.

If you’ve had a rock-star IT consultant come in to help with your internal pictures, at some point he or she should be able to put themselves out of a job. But the opposite invariably happens and Dependency situations arise instead.

Companies lose sight of the original intention, and the consultant gets swallowed up in the process they’re attempting to correct and the message is lost. The Consultant becomes a daily grind "fix-it-all" super-hero – strapped to the process they’ve been hired to provide assistance with.  

We get tied up in the achievements of the individual, and not the philosophies they brought to the table. We start treating him or her as a great developer who can get more work done than their peers, and the Consultant turns into a “Butts in Seats” contractor. We lose sight of how they were able to achieve success. In fact, we don’t really care. Ultimately, we just want it done for us. We want the hero to arrive to save us from the very same poor decisions we were asking them to originally help us with.

We want the Consultant to save us from ourselves.

Focus instead on what the Consultant is telling you – the process improvement and self-sufficiency. Not the hero that made it happen. Listen to what he or she is telling you. Don’t just watch them execute and absolve yourself of the responsibility of learning what they are attempting to teach you.

Instead, up your own game. After all, that’s what the Consultant was originally brought in to do, right?

Every day I see more and more developers becoming agents of positive cultural change in their own organizations and IT communities. Either by nature or occupational hazard, we enjoy problem solving. It’s just how we tick.

Because software touches every aspect of a modern organization, our opinions are being sought to help solve larger systems pictures. As we do so, mentors and thought-leaders have become an indispensible part of that transformation to better practices.

Developers are in a constant learning culture and it can be an overwhelming experience for new developers to even know where to begin. Given the pace at which new technologies and practices arrive and the breadth (and depth) of knowledge we’re expected to retain, ours is an industry that benefits immensely from mentoring.

Mentoring assists with technology, practice and process learning curves, team cohesion, software delivery, stakeholder engagement and employee retention (something that all IT departments face).

Rather than tread ground that’s already been walked before, a mentor will show you solutions that have already been formed and help you avoid technical dead-ends that have already been taken. It can also help a company avoid Technical Debt born of rookie mistakes.

So what are the qualities you should seek in a mentor?

1. Seek out a subject matter expert (if one exists) in your area. Someone who has invested the time it takes to understand something deeply.

2. Seek out someone who actually practices what they preach and who can explain why alternate approaches might fail. But beware of a mentor claiming subject matter expert status in a technology that’s 10 years old… We call that archaeology.

3. Seek out developer mentors who are the communicators in your discipline. The ones who publically speak and blog are excellent choices because they’re brave enough to publically stand behind their facts and convictions.

4. Seek out developers who are trying to address larger industry dysfunctions like Agile, Lean, Kanban. These are your thought-leaders. They are the ones attempting to make this industry a better place to work in. They are the culture changers – the ones who can help with larger company pictures.

5. Seek out a mentor who is also focused on community. We’re fortunate in Kansas City that the developer community is so actively collaborative in nature.

Good developers love to learn and share it. Good mentors show up.

Here’s a quick list of groups and events that you might think about checking out. This list is not exhaustive, but a great starting point if you’re wanting to find a mentor or simply become more active in the community. 

Kansas City Developers Conference – A yearly event not to be missed. Mentors, MVP’s, speakers, bloggers, experts galore.

Limited WIP Society Kansas City - A monthly meet up for developers interested in the Lean and Kanban software development. A great roundtable on topics suggested and voted on by those who attend. Moderated by Troy Tuttle.

Kansas City IT Professionals – Run by community advocate Mike Gelphman. Mike also runs the most active IT LinkedIn group in Kansas City.

KCNext – Recently merged with SITAKS serving as a regional advocate for KC Tech companies.

8:00am:    Phone rings – You’re asked to help a new employee who doesn’t understand the system you were part of implementing a year ago. You take an hour and a half to help out because a departmental manager who believes training is “an IT thing,” has conveniently passed the buck and absolved himself/herself of the responsibility.

9:30am:    You get a coffee break and vent to a coworker that training was not part of why you signed up. Your manager has seen and condoned this 1.5 hours, but still expects you to commit to the "deadline".

10:00am: You get an email that a self-important departmental manager would like changes to an existing system. He has escalated it to all departmental heads because the competition is doing it and it’s the latest priority #1. He is a predictable squeaky wheel, but he generates fear so well that IT is forced to drop everything and respond.

10:01am: You check in with your boss, and indeed, find out that this has been deemed “an emergency.” You both question the need for a steering committee governing best business interests, but realize that the company should have the ability to change its mind… And they do – often.

10:15am: You both hurry to meet the departmental head to understand this dangerous threat to the stability of the company and experience a venting session about how your software is non-competitive. The specifics are short, but the emotions are high, and IT is to blame for a sudden marketplace inequity.

11:00am: You decompress with your boss and attempt a course correction to help out Mr. Needy and his attempts to sully the credibility of the IT department.

11:30am: You’re still in the dark as to what the specifics of marketplace advantage translates to, so you go to lunch and spend an entire personal hour discussing and interpreting his needs while two tables over, he has a relaxed meal with the competition.

12:30pm: You check email and find there’s another departmental head with an operational crisis. It turns out to be something that’s happened repeatedly before, but your past help hadn’t championed any advocates – it had only created a technology (help-desk) dependency situation. You help the user find the ALT key, resize a window and listen to them talk for an hour about their fear of pressing the wrong button.

1:30pm:   You try to redress where your day has gone and what project it started out being. You start getting back to the project that you’re meant to be working on. You view the code, attempt to assimilate it back into to your memory and get on track. The conflicting needs of departmental heads predominate your thoughts and concentration and effort seems a joke if your priorities are forced to change tomorrow.

2:00pm:   You start to question your priorities with your manager. Your manager attempts to run interference but is conflicted by whose political needs will help his own cause. Everything seems to be Priority #1. There seems to be no visibility to the department or company on your ever-changing work schedule.

2:30pm:    Things go quiet for a while as if the drama might pass and tomorrow might be a set of new priorities. You feel like a pawn in a game with an allegiance to a department rather than a company. Because no new priorities have actually been set, you go back to your scheduled development work with a tinge of guilt because you’ve not really received any true guidance and instead, feel like you should be providing some.

3:30pm:   You get back to the code you were meant to start at 8am this morning.

5:00pm    Your boss stops by to ask about the progress of “the project”. He reminds you of "the deadline" while your mind wanders more consciously where your subconcious has been all day…..thinking about finding a new job. 

At the end of your 8-hour day, you’ve lost 6.5 hours against that project “deadline” (not including your personal lunch time) and are still expected to deliver a miracle. You wonder how tomorrow will look. You know it’s not predictable, and you know that the work you did today will not be accounted  for against the project. It will become invisible to your boss, the department and the company.

All they will see is the looming mythical deadline…and a false perception of IT incompetence. 

We like to educate. In fact, we even have a board game we use frequently to help clients visualize workflow and facilitate collaborative systems thinking.

We recently introduced this game (created by a fellow New Zealander, Heaven forbid) to a selected group of cross-functional internal change agents.

They seemed extremely engaged and excited by the benefits of Kanban and receptive to the collaborative approach required by each other’s input.

It was a great session on software delivery, where the players identified bottlenecks in process from a full systems picture. Amongst other things, we discovered that optimizing one functional area did not ensure better throughput of software.

Important lessons and great stuff if you’re in to that sort of thing. We are, and so too was this group.

Here’s something interesting, however: In order to represent the productivity of a developer in this game, dice are rolled…

This is always an interesting conversation topic and uncovers a host of questions like the ones below. Take a look and let us know what you think: 

1. Is it realistic to portray developer productivity this way, on the randomness of a 1-6 scale?

2. Is the daily life of a developer really that unpredictable?

3. If it is, then what does that mean for project planning and estimations?

4. When you ask a developer how long something might take, how do you account for interruptions, daily “emergencies”, or the business demands for their knowledge? What’s your “padding” for those factors against that guesswork – surely padding itself is guesswork game too? Now your project planning is nothing more than a game of predicting padding on top of other guesswork.

5. Can you really keep a developer in a productivity bubble away from the demands of the daily operation of a company? Does that solve any problem, create more or just move the problem to others?

Deadline: Originally a Civil War term for a line that marked the distance a prisoner could go before being shot on sight. (source: http://www.thefreedictionary.com/deadline)

When I see an employee who is asked to guess on a timeframe, be held accountable for such random number theory, and then forcibly held accountable to that speculation – I become concerned.

When I hear an IT department say, "We need to identify these timeframes so we know how much overtime we'll have to put in to make our deadline"  -  I positively cringe.

Many companies still have an unhealthy "adrenalin-junkie" addiction to deadlines because they confuse them with results. The truth is, and what many companies repeatedly fail to understand, is that they are actually incurring larger costs in the form of waste, technical debt, staff turnover, disengaged employees, and eroded company culture.

As this self-induced erosion occurs, these companies get a reputation in the community as a place to avoid, both from consumers and job seekers.  

This tired practice of using wartime models for peacetime business practices is both misplaced and corrosive. Comparing workers to soldiers, projects to D-Day beach landings, and acceptable losses/collateral damage to the greater cause……all of this modern day nonsense eventually erodes the very business continuity and productivity gains they were trying to obtain in the first place!

If the goal is productivity – deadlines will guarantee the opposite. Forcing your staff to meet arbitrary timelines doesn’t build morale; instead it builds an unhealthy camaraderie of mutual hatred, resentment and distrust toward management.

Steady, predictable output, determined from actual metrics, gets you there – and more accurately. Agile principles, when applied correctly, have the ability to turn the tide of the deadline culture while simultaneously creating better work environments.

What company in their right mind WOULDN'T want that?

This year, why not change the way you've always done things? Let your employees enjoy the holidays without the threat of looming deadlines born out of someone’s need for their bonus or misplaced desire for a neatly packaged project completed at year end.

The deadline isn't what's most important.

Approaching things in an agile and lean manner is a philosophy, and as such it's not something you do only while at work or even during a certain project. Some people will always run and be comfortable with a waterfall project because that is their internal process. 

Planning

If you are an inherent 'planner' then being agile to you will feel very chaotic and out of control, however it is mearly about only planning as much as necessary and delaying decisions until the last possible responsible moment.

You might be a waterfall-ist if:

• When planning a family vacation are you the type that planned on Thursday 4 days from now at 1:15PM you will be stopping by the worlds largest Starship Enterprise?
• Instead of going to the grocery store every 2 or 3 days to food for what you feel like at the time or do you buy 10 lbs of beef at a time from Costco and commit yourself to eating it all that week even if you find out Wednesday that all beef was a bad choice?

Being agile is not making so many plans that you are heavly invested in them not changing, instead you should be able to switch directions quickly enough to respond to changes or unforeseen obstacles. As valiant as it seems sticking to your orginal plans no matter the developments along the way, it is actually not good decision making. Unless your filming National Lampoon's Business Vacation, then you can go crazy Clark.

Constraints

Another attribute is how do you handle failures or other undesired results. If you have seen huge process maps with seemingly endless hoops to jump through to get work done, its most likely the result of over compensation for failures. Everytime something has gone wrong in your process, it is not an immediate invitation for extra constraints, contstraints in a process should exist to provide benefits not to just stifle flow. Sometimes the cost of a failure is less than the cost of the constraint, in which case it makes more sense only to work on lessening the impact than to implement a prevention constraint. If you don't know the cost of the failure or the constraint then it's irresponsible to implement one.

To put this into everyday perspective… car wrecks happen everyday and people get seriously injured and even killed. This is obviously a very bad result that can be solved by constraining car speed to 5mph. While this will work the cost of this constraint is quite massive and not ultimately beneficial. A better solution than simply slowing traffic to a crawl would be to develop smarter and safer cars to make wrecks less dangerous.

So before you go out and try to do an agile implementation do you think you have the mindset for it?