How many of you have heard a developer say this at one point or another:

“Why on earth would they want it to do that?”

Modern requirements gathering has become a very sterile task- identify what must be done.  Don’t get into the weeds.  Describe the problem.  Let the developer solve the problem.  Where this goes astray is that, like the worker on the assembly line who inserts tab A into slot B and passes the item down the line, the developer is simply pulling a lever to make it exactly as described.  They have no idea what the goal is, so they can’t troubleshoot, they can’t add value, they can’t even tell if it does what the user intended- which is often different to what the user said to the business analyst.

A good business analyst can get at what the user’s intentions are.  The problem that I’ve found is that often the business analyst may know what the user’s intentions are, but he has no idea how the existing system is solving the user’s problems.  What the business analyst usually has is how the user thinks the software solves the user’s problems.  There may be large, significant chunks of logic hidden deep in the system that have broad implications, none of which the user or the business analyst is aware of.

 It’s LOLcode!

While pondering this, I’ve run across a few articles that summarize things very well:

On identifying a great programmer:

http://www.inter-sections.net/2007/11/13/how-to-recognise-a-good-programmer/

On recognizing, hiring and keeping a great programmer:

http://outofthetriangle.wordpress.com/2008/02/03/hiring-the-best-coders/

On some great theory that can help you understand the type of thinking you’re looking for:

http://outofthetriangle.wordpress.com/2008/01/31/600-line-design/

and last but not least, for those out there who’ve bungled a developer hire in the past:

The 10 Most Serious Hiring Mistakes and How to Fix Them

http://peeyes.spaces.live.com/Blog/cns!9D867CC7936D3E20!716.entry

That being the case, how easy is it for your partners to get rid of you? If they were unhappy with your product, what would they have to do to change roads?

This sounds like a suicidal thought to consider. Why would you want it to be easy for customers to go to the competition?

Hear me out before you get the tar and feathers. Strong business relationships are built on trust and mutual advantage. Customer relationships are equally built on trust and mutual advantage. Both of these are reasons to make it easy for your customers/partners to walk away if they need to do so.

Not good enough? How about your reputation? If you want to scare away new customers, just let one horror story about how bad it is to migrate away from your product to get out. Never mind just getting out. In the current era of the ‘blogosphere’, one story can turn into 10,000 seperate articles and opinion pieces blossoming on the internet inside of a week. Nevermind that it’s all over five cases of a problem. When customers research you, they’re likely to do something like this:

1) Open web browser.
2) Go to google.
3) Type in your product name.
4) Hit enter.
5) Read an entire first page of hits from websites that sound like unhappy customers and/or bad reviews of your product.
6) Click an article at random.
7) Read a horror story about how your product is a nightmare to uninstall and/or get the customer’s data out of and how badly your product is engineered, complete with at least one link (probably to another blog) promising more horror stories.
8) Close browser and call your competitor.

Sound like a problem you should worry about now?

 No one wants a customer to leave their product line. The fact is, though, that if a customer chooses to leave your product line, they will probably do so anyway. Someone else’s saleman is going to have sold them already on how easy it is to migrate to their products. When it’s not so easy to do, they’re going to blame your product and feel relieved that they left you. They will use this as justification for their decision, and thank the new vendor for saving them.

If you are compliant with the latest standards, have good export tools, and otherwise think through how to migrate away from your product if needed, then you insulate yourself from this. Maybe the customer trying to migrate might not understand, and maybe they’ll believe the competitor’s salesman, but once the story starts to float around, some experts are going to get ahold of your product and the exports, and they’re going to come to your defense. Ease of migration will become a reason to praise your product.

This is also a sell point for you.  Fear of lock-in is a real problem for your sales force.  Everyone’s bought at least one technology product that they hated.  They also went through the pain of getting their data out of it.  Fear of lock-in and painful migrations will keep them from buying. Being able to show your customer how to get themselves free if they are unhappy is a marvelous sell point. Demonstrate your migration tools, show them how you make them safe from you, and you will remove the number one ‘but’ against buying your product. This automatically puts you way ahead of the competition.

Third, this makes life easier for you over time. Need to overhaul your product line? Do the new features of your next product generation require a complete reinstall? Sticking with standards in migration tools keep your options, and the options you offer your customers on upgrading, more flexible. If your customers can get their information out easily, you can do more radical things if necessary to upgrade your product lines, and it will be easier for your customers to stick with you.

The ability to leave your product is in fact a strong trust-building tool. Trust and credibility sells in today’s economy. Don’t sabotage a terrific tool for yourself with your own fears about your customers’ plans.

At the same time, Gantt Charts *can* be used in Agile Development.  Like in Agile Development itself, it’s all about adaptability.

The key is to learn to build your project plans in a modular way.  Within every project, even an Agile Development project, there are some tasks that simple must depend on one another and must be completed in order to complete a given goal.  To meet a specific business requirement, for example, you know that you need to develop function X, Y, and Z.  You know you must write requirements, you know you must write test plans, you know you must test, you know you must release them.  If you intend to deliver a complete solution for this business requirement within a single release, then that’s your module.  The number of iterations within that module, the order within that module, is not as relevent as the fact that you are going to do all of these tasks, and must do all of these tasks, in order to deliver a solution this business requirement.

So now that you understand something about a project ‘module’, how do you manage with it?  Try these steps:

1.  Develop your project’s task list as normal.

2.  When you create your project plan, organize your task list into modules.  Assign modules to software releases according to your current estimate as to what order that these things will be delivered in.

3.  When your project team, or your management team, shifts, then shift the modules within your project plan.  This WILL sometimes wreak havoc with your plan, particularly levelling and dependencies.  You will learn ways to adjust so that it’s easier (I could give pointers here, but really, I’ve learned that it’s heavily dependent on your style of PMing).

4.  Communicate, communicate, communicate!  You will need to constantly put out updated projections and updated task schedules when doing things this way (Agility does not come without a cost).  Your team must always know what’s coming next, so that the preparation work needed for it can be ready (for example, requirements for the next phase of development must always be ready before the developers finish the current phase).  Your management must always know how the delivery dates change, so that they can manage to the new schedule.

There is more to it than this, but again, it’s heavily dependent on your management style, and so your mileage will vary a bit.  Once you get used to it, it’s extremely effective- think of it as “Planning to not have a plan”.

By planning your modules carefully, and watching your dependencies to always keep the right ground work queued up, you can be ready for anything.  Your team will be ready to change directions on a dime, and be truly Agile.

There’s a saying I heard in a college psychology class that has stuck with me for life- “The most flexible part of a system controls the system.”  In the business world, the most flexible company in a market is capable of controlling the market (just look at Apple and Google).  Planning for Agility is tough- get used to it.  If you can pull it off effectively, you have a massive advantage.