The Perfect Project

While dodging cars and fighting the wind (I ride my bike to work), I started thinking about what components make for the perfect software development project.

Valauble Business Problem
Business Problems fall into two categories. Those worth solving are one, everything else is another. What makes a problem worth solving? One of two things happens when the system goes live: Money is saved or money is made. One of these should present itself within the first quarter of the code going live. Asking a client to wait longer than that means the project was likely too large in the first place, it should have been reworked. A perfect Agile project would have the business measuring money saved/made from one iteration by the time the next iteration is lighting up.

Easy Access to the Business Experts
I think this one is more common than people think. If you’re about to solve someone’s problem, they want to help. Now, they’re never keen to help you solve a problem not worth solving (see above). A legitimate problem? Everytime.

An Agile project has different demands on the Business Expert, they are asked to behave differently. I have never experienced the Business Expert shy away from this. You are asking them to help you help them. Maybe this post will lead to me meeting a Business Expert from hell, keen on ripping my head off for not knowing how Credit Liquidity or Risk Management work…

Open, Dynamic Team Members
My current project fits this in a lot of ways. Lots of people wearing lots of hats. Business Experts reading API docs and writing tests, Developers meeting with management to discuss ROI — an absolute pleasure. Everyone has interests outside the project: another key. Work is something you do from Monday to Friday, morning to late afternoon. I’m much happier discussing various hikes or how my Leafs did last night than how some developer worked all night on a problem they could have fixed had they discussed it with the other team members. Leave your ego at the door, we all make mistakes, we all miss stuff. When you stop thinking people expect you to be perfect, you’ve taken your first step in perfect’s direction.

Flexible Approach
If the requirement is moving people from Canada’s east coast to west coast and the year is 1871, yeah, not so flexible. You’re building a railroad and that’s that.

It’s 2005. An infinite number of tools to solve the same problem exist. Try one. If it’s going to work, use it. When it stops working for you, change. If change means going back over work that’s been done and refactoring it, do it. Changing your code doesn’t mean it was wrong the first time through, it just means you’ve found a better way of working the problem.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s