Don't Go There

A few years ago, I worked for a company that had a pool table. It was cool and different. A lot of edgy companies had Foosball tables and Ping Pong tables, but a pool table is a different beast altogether. This baby had three or four huge slabs of slate over an inch thick apiece that were laid out on a bed of stuff -- mud, clay, something -- and carefully leveled over the better part of an entire day. Then the stuff was left to set over night before the felt was applied.

We played pool to ease tension, introduce new employees to the company and, finally, to determine who was the "best". That is, we started a ladder.

As we played, we realized that we regularly getting ourselves into situations that were just tough to work out of. We didn't know what to do. Sometimes we tried to force our way through, sometimes we tried to finesse our way out. Usually, our efforts were too little and too late and our opponent trounced us.

So we got training. We brought in an instructor. A Pool Shark. The movies had nothing on this guy.

He wowed us and explained many aspects and strategies. At the end of his session, the inevitable question came up; "What do you do when you find yourself in a situation like this?" Then we would layout some of the most challenging plays in which we found ourselves.

He looked at the table and the balls laid out on it and a pained expression crossed his face. "I wouldn't let myself get into this situation," was his reply. "Never."

He knew enough about the game to know where the danger areas lay. He had played and practiced enough to know how to keep is game in the area where he can control it.

This story occurred to me as my colleagues and I struggle to stand up a large and complicated release that was pushed into production too soon. We know better. We know where the danger areas lie and how to avoid them. But we were pushed right onto them. A mandate was given and we did our best to march to it. Sometimes you just have to do that. But if and when you do, it is helpful to remember that you chose to ignore the evidence that it probably wouldn't work smoothly.

Just don't go there. Don't set things that aren't highly likely to succeed, especially when lots of dollars are on the line.

The Perfect Engineer

For reasons that should be shortly entirely obvious, I have been thinking about job interviews. It was so bad that instead of typing "routes.rb" while looking for a file, I typed "resume.rb". Heh.

And, in thinking about this I realized what I think companies want out of the perfect engineering candidate.

We've had a good deal of changes where I work. Let me state right now that I have a tremendous amount of confidence in the leadership, their vision and the work that we're doing. However, when things change, folks get all shook up. First, after a sizable push to get new infrastructure up and running on an accelerated schedule, we lost a bunch of folks. Some were contractors that wrapped up and others were stalwart members who accomplished something really great and felt it was time to move on to new challenges.

Then, we had a change in team leadership. This caused more unrest and another flurry of departures. Although we're looking for replacements, they are hard to come by and a linear extrapolation of our head count over the past year shows no one left by next July. We mostly look at that downward progression as gallows humor.

So, thinking about my departing colleagues and having had to do due diligence myself, it occurred to me that companies seem to be looking for an engineer with the following qualifications:

• Amazing Abstract Thinker: Software architecture, design and algorithms
• Rock-Solid Concrete Contributor: Code structure, comments, testing, source code control, branches, merging. Master of multiple languages
• Top-Notch Manger of the User Experience: Site flow design, UI design, HTML, CSS, JavaScript implementation
• Unshakable Foundation Provider: Schema architecture, database configuration, SQL wizard across multiple databases both commercial and open source
• Deployment Master: development, staging and production system configuration and management, deployment processes and scripts
• Systems Genius: Unix, OS/X, Windows, Networks and OS internals
• Unparalleled Business Analyst: Business needs analysis, specifications, requirements documentation, feature prioritization, cost estimation, ROI projections
• Zen Guru: personable, calm, professional, communicative, approachable, polite and respectful, unflappable
• Project Management Prodigy: team management, task estimation, assignment, prioritization, budgeting, conflict resolution, risk management
• Strategic Wonder: project current business realities into future business needs and align technical infrastructure, staff and supporting resources to meet tomorrows needs today.
• Workaholic: Put in a solid 40 hour week plus full time availability for emergencies and fire-fighting
• Hero: Take critical business needs and urgent projects, pull out all the stops and deliver them ahead of all expectations
• Inexpensive: after all, we're just talking about friggin' writing code for a web site. How friggin' hard can that possibly be? Plus, there are a ton of engineers and they're easy to please. Give 'em a fast computer and lots of free food and they're fine.

Ja, this is pretty snarky. But as I review it, I'm gonna stick by it. I recently realized that I started managing folks when I was 16 and ran a ballet studio for the summer while the owners were traveling out of the country. I've been doing this management stuff for over 30 years. Holy cow!

BTW, I can lay legitimate and concrete claim to most all of the aspects identified above and feel darn good about that. However, I've worked with a lot of folks and know that really good engineers are really hard to find; may be 1 out of 20. They have the ability to sustain an entire company and turn it around on a dime as needed.

Like I said, I feel good about where I am. I know the value I bring and know that I continue to work with some very talented engineers whom I respect tremendously. I also know that I would be hard pressed to replace them and hope I don't have to any time soon.

Customer Relationship Failures

Here are a few instances of where companies are failing to meet my expectations. For each company and product, I am actively looking for acceptable alternatives.

Bank of America: I just downloaded my recent activity. I had been royally annoyed that BofA signed me up for paperless statements and then claimed that I had requested that. Never. I rely on the monthly statement to remind me to reconcile and I like the security of holding onto paper records for this purpose.

So, I logged on and searched and searched and searched until I found where I turn OFF paperless statements.

Imagine my surprise when I saw monthly maintenance fees on all my checking accounts.

A new payment schedule now declares that because I am not a eBanking customer, because I get a paper statement, they are charging me nearly $30 in monthly fees. And, I couldn't even call them at 9:20 pm to ask about it, because their customer service centers were closed.

I hate surprises from Bank of America. Bank of America; you suck.

Verizon Wireless: I hate my phone. It's an HTC Droid Eris and its just underpowered, weak and pathetic. As a software engineer, I hate using it, especially since I did some iPhone development and had an iPhone for a while. But phones apart, I hate Verizon Wireless more.

At one point a few years ago, while doing iPhone development, I was also helping get a start up off the ground (shout out to Star Street Sports!) and my wife and I blew away our minutes. Me on AT&T and her on Verizon. We had over $1000 in additional fees.

I called AT&T. They asked if I would upgrade to the unlimited minutes plan (only $20 more per month) and, if so, they would waive all the overage fees. I agreed in a heartbeat.

I called Verizon. They asked if I would upgrade to the unlimited minutes plan (only $20 more per month) and, if so, they would -- are you ready? -- give me a 30% discount. What? Excuse me? Your competition waived all the fees and left me feeling really great. You gave me a sucky deal and I had already been a customer for over 14 years, plus added four more additional lines.

Then I discovered that they have a policy that they won't discount more than 50%. So why did I only get 30%? I called back. You see, it's up to the representative who takes the call. So, for what ever reason -- I'm a jerk, the rep was having a bad day -- I got 30% off of the egregious over charges instead of 50%. And I'm still seething because they didn't give me nearly as good a deal as AT&T.

Verizon Wireless; you suck, too.

Callpod Keeper: I used to like my Callpod Keeper. I found it while using an iPhone. Callpod offered a free mobile password safe and I needed a replacement for my old one, which was open sourced and no longer being maintained. For $30 I could buy the desktop and then sync between mobil and desktop. Sweet!

When I switched to my sucky HTC Droid Eris (seriously, this phone is crap), I found Callpod has an Android version, which I installed.

Not long thereafter, having upgraded the app, the app kept asking if I wanted to try a 30 day trial of their premium service, wherein I could sync to the cloud instead of my own desktop. No. No, I don't.

Finally the friggin' pop-ups stop and I get around to syncing my devices. But I can't. Because now, without telling me, Callpod changed the rules. Now, I have to upgrade to their premium service to sync at all. They hid this change -- it was never mentioned anywhere I could see in the upgrade summaries. Now I can't sync my mobile password safe with my desktop safe and the two have inevitably drifted apart.

Callpod: you suck too. I'm chucking your ass out on the street as soon as I find another password safe.

So, there you go. Three examples of different companies pissing me off so royally that I actually spent my time to complain about it publicly.

This is why it was so important to me to make my Hold-it! Game Card Organizer an outstanding value. First, it is great to use and really helps make dozens of games play faster and better. Second, it is seriously sturdy -- I had a 400 lbs. fellow stand on one at a game convention without damaging the unit at all. Finally, I offer an unconditional -- yes, without any conditions -- guarantee for your money back if you don't like my product. Return it for your purchase price.

OK, so the Hold-it! hasn't made me wealthy and it really sucked that the hobby-game industry was deflating at the time I was trying to get my product into the marketplace, but it taught me tons about how to make something that customer will value.

I do no marketing or advertising at all. Nothing. And the Hold-it! continues to sell from my old, ugly website all on its own. Word of mouth. Because the folks who have purchased it (and I've sold it to nearly every continent on the earth) know they have a really good product.

If I could do it, then I really expect Bank of America, Verizon Wireless and Callpod to figure out that pissing off the customer is not good business.

Join.me is a winner

We have a contractor who works remotely and I was chatting with him on the phone about the project to which we are both assigned. I was trying to talk him through some of the specifics of our administration tool when he said that this would be a lot easier if he could just see my screen.

First thought was iChat, but I already had Colloquy and Adium running and last time I tried iChat it wouldn't connect to the AIM server. (I've since fixed that by connecting to the AIM server on port 443).

Next, I remembered getting an email from LogMeIn about a new service for free screen sharing. I went to the LogMeIn site and found Join.me and clicked on it. It started up Java, and I downloaded some Java code and a small tool bar appeared at the top of my screen. It didn't seem to take even a minute. I pasted the link provided in the tool bar into my Colloquy chat window and my colleague clicked on it.

He didn't need to down load anything. The Java code runs on my system, pushes my screen data to the server and he got a Flash driven experience, complete with zooming and screen resizing right away. We never had any lag, though he was working from home quite a few states away.

Fast, Easy, Free, Unobtrusive, Highly Functional: Join.me is a winner

How to Get Real in Corporate Development, Part VI

This is the sixth part of a series of essays on how to leverage the concepts of Agile software product development from Getting Real from 37signals in a corporate development organization. Part I introduces the concepts of Getting Real, part II looks at the idea of building less, part III is on focusing on one idea, part IV is on getting something functional out quickly and part V talks about focusing on how your users will use the application.

Now it's time to look at:

Focus on fulfilling business stories, not big specification documents.

In my 20+ years of technology experience, I have seen this as being the biggest and most pervasive problem. And I understand that it comes from a very valid perspective from the engineering community.

Engineers can not easily manage huge amounts of change to requirements. Imagine building a bridge if the length of the span changes weekly, the material under the footings shift regularly and the sponsor wants the bridge in steel; no, titanium; no, wood; no, aluminum; no, steel -- you get the point. Therefore, engineers seek to define the requirements and get agreement and sign-off on those documents so they can build something once. Plus, we all know that change gets more expensive as a project progresses, especially if you have a waterfall or spiral approach. All that inflexible foundation work is very expensive to change. (Another reason to stay light and agile!)

Because of the cost of constant change, engineers push to define requirements up front so that they know what to build and where to start. They require definitions, use cases, scenarios, storyboards, and so forth. From this collected material, they define the grand scheme, break it down into delivery phases and get agreement and sign-off. Again, they want to build something once.

The flaw with this approach is that the requirements cannot be entirely known in advance. Therefore, just as soon as the project starts, the huge requirements specification is out of date. I once worked on a project with over one thousand distinct requirements. Because we were inventing new science and technology while producing a commercial product, the requirements churn was huge. We touched every single requirement dozens of times; the requirements churn topped 1000%!! That's like writing over 10,000 requirements! It was nuts!

Here is the fix: Focus on business stories. Start with the most important story. It works like this.

The business problem is, "We have to generate an inventory spreadsheet daily by running a report in our inventory management software (IMS), copying the date and transforming it into Excel, then cleaning up the data by re-arranging the columns and saving it as a semi-colon delimited file so it can be emailed to the web services group so they can update the inventory counts on the website. Errors and delays in the process can mean displaying products as in-stock when they are currently back-ordered, which annoys customers."

The business story becomes, "We want to automate the daily inventory reporting from our IMS to our web server to increase accuracy, decrease information turn around time, and free business resources for other work."

I can immediately see a number of ways to do this, from using whatever automation exists within the IMS to generate and send that report, or accessing the IMS database directly with a custom report, or using the IMS database programmatic API to write an automated application to pull the data and update the web database, or to make the web database read its data from the IMS database live, or on a daily batch bases, or exposing a web service so the data can be pushed into the web database. I bet you have a few more options.

The take away is that solving the technical problem isn't usually the problem. The problem is solving the correct business problem. Getting bogged down with a huge requirements document doesn't make solving today's problem go any faster and doesn't produce a solution to today's problem any faster.

So, how would I apply this advice to that huge 1000% churn project? Well, the biggest constraint was that we had to produce a commercially shippable product. A goal was to create a single architecture that could be leveraged along the future product line. However, since we were creating new technology and a new command and control system, we set the bar too high.

The immediate business story was to operate the machine and provide a sufficiently flexible control system that would allow for the scientific invention to continue without requiring huge software re-writes. Today, I would drop the goal that we create an architecture that could handle future demands. The project was already very challenging without that goal and we ended up pulling out all the infrastructure that was built to handle that goal anyway, just to get the first product to ship.

We made the classic mistake of solving tomorrow's problem before solving today's problem. You can avoid that mistake by focusing on the business stories that you have today and not creating that huge, over-arching requirements document that will doubtlessly saddle you to a very sizable ball and chain.

How to Get Real in Corporate Development, Part V

This is the fifth part of a series of essays on how to leverage the concepts of Agile software product development from Getting Real from 37signals in a corporate development organization. Part I introduces the concepts of Getting Real, part II looks at the idea of building less, part III was on focusing on one idea and part IV was on getting something functional out quickly.

In this essay we look at:

Start with the UI design and focus on how your users will use your application.

Lots of experienced engineers like to start with the UI. A new project brings a geyser of ideas and concepts that make the fingers itch to start writing code. So, mockups, prototypes and proofs of concepts are often the first things to come out.

Good! Almost.

Don't let your engineers close themselves in a room for the four weeks that they have and create something they love. The rest of the sentence is the key -- "focus on ... your users ..."

In "Getting Real", the folks at 37signals assume they are writing an appliation for the outside to use. They don't have an opportunity to sit with their most important users when creating something new. But you do! This is where the corporate environment make Getting Real better than the original. You're making software for your business, you and your users are the domain experts. You don't need to go outside. Lucky you!

Get your engineering team (2 really good engineers and a kick-ass business analyst) in the same room as the key stakeholders -- the folks who will use this new system. Understand the business problem (Focus on One Idea) by talking to the users and examining the problem they need solved.

Have the team work through what they need to do. What tasks are grouped to gether logically? What actions are done most of the time? What actions are done only a small fraction of the time? Make the application fix the problem elegantly. That way, the team has to Build Less and will be able to Get Something Functional Deployed Quickly.

Start light. Whiteboard and sketches. Wireframes and light-HTML. Test the process. Can the users do their important tasks quickly and easily? Can they see how they get to the additional features that they don't use every day?

Put the most important information right in the middle. Make sure that new state, the populated state and the error state are considered. Ensure the engineers make the application behave appropriately when it encounters something unexpected. Leave out what doesn't belong to do the task (who cares if it's a "standard" menu item?). Put in everything important. Leave out everything else.

Match and support what the users need to do, then go and make it happen. Start with the UI. Not the UI and the database, just the UI. Not the UI and the object model, just the UI.

The engineers will have a clearer idea of what's important. They will have proven the work flow that they are about to implement. The users will have increased confidence that what will be produced will really help them.

Can you just imagine the response when the first version comes out a few weeks later? Hey, please write and let me know! I don't want to do this in a vacuum!

Thanks again for reading! In the next essay, we'll talk about how to use business stories.

How to Get Real in Corporate Development, Part IV

This is the fourth part of a series of essays on how to leverage the concepts of Agile software product development from Getting Real from 37signals in a corporate development organization. Part I introduces the concepts of Getting Real, part II looks at the idea of building less and part III was on focusing on one idea.

Next, we talk about structuring the project to quickly produce working code. So here it is:

Get something functional and usable deployed quickly. Plan on your next release right away. Make a choice and go with it.

Constraints are what drive a project. If you had unlimited time and money, you would probably never produce anything, as ironic as that may sound. You need limits to focus you on getting something done. My triathlon training buddy and I like to say that we "train to race and race to train" because without the race date, it's too easy to sleep in instead of hitting the pool at 5:00 AM. Constraints drive us.

So, pick one of your projects and give it to a small group of good engineers. Tell them they have four weeks to produce the first version that the business can use, but then they'll have four more weeks to produce the next release. And close the door.

They will focus on building less and implementing one idea. It's all that they'll have time for. Meanwhile, let the business know that the first iteration will be ready for use in four weeks and that the engineers will need their feedback to produce the second iteration.

Your job is to get out of the way and make sure the engineers have the tools, access and permissions they need to do their work. Herein lies additional opportunity.

Perhaps there are procedure and process documents in your organization. Perhaps there is a PMO and a review committee. Perhaps you have strict regression testing requirements for deployments. Perhaps, under normal circumstances it would take your small, Agile group of engineers four weeks just to get permission to connect to the database they need to fulfill this project.

Your opportunity is to fix this. Yes, security and access control is critically important. But, we're in the 21st Century, aren't we? Network directories with access control list are mature technologies and are probably in your organization. Are your Oracle databases set up to take advantage of your LDAP infrastructure? They should be. And no one better exists than you to make it happen.

Your organization should have four environments:

• Development -- open and flexible for the developers to do anything. Developers should work in both Debug and Non-Debug environments. Don't accept "Well, it worked on my machine."
• Test -- mirrors production, but allows developers to see everything in the system.
• Staging -- mirrors production as closely as possible
• Production -- full security and access controls.

Using virtualization, farms, and similar techniques can keep this from being a horrible amount of overhead. The key is that you need to unlock your most productive engineers. Now is a good time to note that not all of your engineers are your most productive ones. Make sure your less productive engineers are fully supporting your most productive ones. There are opportunities for training and mentoring, which build employee satisfaction and loyalty, but let's get back to getting functional software out.

How many times have you already read that a skilled and senior engineer is many times -- 10 times, 15 times, 20 times -- more productive than a junior engineer? So, we don't need to say it again. Nope. Not going to say it. Na-uh.

So then, just how will this work? Well, let's start off by looking at the typical process. The business has an urgent need. Something like, "they spend a huge amount of time running end of month reports and small errors in the data cause regular heroics."

In the typical process they fill out an Application Enhancement Request or New Application Request or some such like that. This gets reviewed at the next Application Review Committee meeting and goes back to the requester for more details. Two weeks go by for the out and back trip and the ARC approves the request. The next week a project manager and business analyst are assigned to it. They take two weeks to gather requirements, another week to create a Statement of Work and one more to have that approved by the stakeholders. The following week, a project team is assembled while the analyst writes the Functional Specification. The stakeholders don't even bother reading that.

We're up to, um, nine weeks. The team takes two months to write the application, three weeks to test it, one week to slot it into deployment and, lo and behold! More than five (5!!) months later, the application is first released. The users try it and file a new Application Enhancement Request to get it to do all the things that they need and eliminate the stupid things that crept into the application. Time to happy users: 9 months.

Here's how we want it to run:

First, you've addressed the infrastructure, you have the governance in place to enable rapid development and you've now paired your best engineers with the business users we just talked about. They meet for one day and use up another afternoon or two. In four weeks the first release is out and in use. In four more weeks the next version comes out and fixes the big problems with the first release and adds a few more features. One more four week period and the business has something that really works for them. Time to happy users: 3 months.

Even if you give this team another three iterations -- that would be a total of six (6!) releases, it would still be 66% of the duration of the Same Old Way, which would have produced 2 releases. Which application do you think would be better? The one that had six tight, focused releases, or the other one? There is no doubt in my mind.

You need to have really great developers to do this. But then again, nothing outstanding was built by mediocre engineers. You need an infrastructure that enables these really great engineers. You still need to have proper governance, SOPs, checks and balances to put software into production, but you can get the work done much, much faster by Getting Real. And this will generate real value for your company.

Thanks again for reading! In the next essay, we'll look at starting with the UI.

How to Get Real in Corporate Development, Part III

This is the third part of an essay on how the concepts of Getting Real from 37signals can benefit development groups in corporate environments. Part I introduces the concepts of Getting Real and part II looks at the idea of building less. To build less, you need to select one problem to solve and focus just on that. Part I introduced this, so let's continue to look at that aspect.

Focus on one idea. Start with the big problem, build the large scale functionality and don’t sweat the details.

One challenge every development effort has is where to stop. That is, where to define the edge of the application. Otherwise stated as, "how far out from the core idea is it reasonable to extend?" For example, should the document handling system not only import PDF's, but generate PDF's and fax them?

One helpful concept is the constraint of time and budget. However, it is not uncommon in corporate development shops to have projects loose the continuity of effort that makes a strict delivery time or budget tracking approach overly challenging. Here is where having one focus pays of immensely.

The thinking is: We are going to solve only the problem at hand (Today's Problem). Building less gets us a solution more quickly. Focusing on the problem helps us meet the goal of solving only the problem at hand.

Engineers with are much easier to keep focused and on-task when they have a delivery due in only a few weeks. Assigning a single, short-term purpose accomplishes this. Part of the standard challenge in corporate development shops is that the an engineer wears many hats as she maintains existing applications, develops one or more concurrent projects, and concurrently designs and plans future applications.

Switching between different types of tasks is a known productivity killer. The well-known blog by Joel on Software lays out the trouble with human task switching. You know it yourself, having your concentrated thought process interrupted is, literally, disruptive. For your team, this means that they need quite, private work spaces, few meetings during sprints, and very long periods of uninterrupted time. It also means you need to keep their plates clear of other tasks.

When you do this, your engineers will be able to stay focused on delivering that one idea.

"Hmmm, good," you say, "but what is the correct one idea?" Good question. After all, "solve global poverty" is one idea, but it's obviously not at the right level.

You're looking for an idea that represents a specific business pain point with a solution that can be produced by a small team in a few quick iterations. Since your team of three engineers can't bang out a solution to global poverty in a few three-week sprints, it's not at the right level. (But you already knew that -- this was an illustration :-)

Let's try some on for size. "Create a portal that allows secure transmission of documents from customers to service representatives." Or how about, "Replace a key paper form with an internal website." Here's what each of these have going for them:

• Each of these have a good change of being produced rapidly in only a few iterations.
• They both address only one problem.
• They require one small application to successfully meet the business need
• They both are probably very well understood by stakeholders and engineers.

Given all this, there is very likely little risk of implementing the wrong software. Even if the end product doesn't work out completely, you have only invested a small amount of time and effort and you're team has more clearly illustrated the business need.

Are you thinking that you don't have any small, simple problems to solve? Are you thinking that you need complex applications to solve complex business problems? Are you thinking that there isn't any opportunity to do something small and elegant like this in your shop?

If you have any of these thoughts, or thoughts similar to them, please try an experiment. Find a key stakeholder at the line level. Perhaps a manager of customer service, or a project manager who executes key services repeatedly. Take them to lunch and ask them about the most challenging aspects of their work and the work their team or group does.

You will probably learn some things you didn't know. And some of what you learn could very well fall right into this camp of creating high-value for the business with a light, flexible, low-risk and low-cost development approach.

The next part is to work with wide brushes and big strokes. You're not looking for a whiz-bang gizmo that does everything. Get the big pieces right first. Now that you know about some business pain points (if you already knew some or knew the ones you talked about over that lunch, then kudos for you!), you're looking to address just that need. Nothing else right now, just that one need.

Yes, the fund accounting deals with mutual funds, 401(k)'s of mutual funds, annuities, closed-end funds, etc. But the bulk of the work is mutual funds. Or the bulk of the time is 401(k)'s. Or the bulk of the revenue is generated by something else. It's up to you to figure out, with your key stakeholders, what the most valuable problem to solve will be, then it's up to you to focus on that one factor.

The mandate you give your team is to fix just that one piece, make it better for the business and don't worry about the details. You will re-work and re-engineer as you dig down into the next set of priorities on upcoming iterations. But you will be providing a high-value solution in very short order, and that is worth more to the business in the long run.

Thanks for staying with me as we continue exploring the approach of Getting Real in your corporate development shop.

How to Get Real in Corporate Development, Part II

This is the second part of an essay on how the concepts of Getting Real from 37signals can benefit development groups in corporate environments. Exploring this mash-up is worthwhile because at first glance, there seems to be very little in common between the web-application, small-team, product bootstrap philosophy in Getting Real and the realities of corporate development teams. These realities include governance, oversight, processes, controlled systems and similar best practices. But pull the covers back a bit and enough similarities appear to make for a compelling argument. Let's dive right in and take a closer look at the key concepts from the first essay.

Build less. Build smaller applications with only the most important features and delivery it quickly.

This is sage advice because the corporate development life cycle is typically beset with serious birthing pains. Life cycles are heavy with process, stages, gate reviews and sign-offs. The corporate process inevitably includes requirements gathering and documentation, which involve meetings, drawings, documents and reviews. The requirements themselves transform from stakeholder statements to business requirements to technical requirements to design documents. After all that, there is finally the build, test, deploy, train, support and maintain functions. All to get one release to the business users.

Some problems with this model is that it takes too darn long and is too darn expensive. Half a year can pass filled with stakeholder interviews, document drafts, reviews, modifications and so forth that will ultimately produce a few dozen pages of specifications and diagrams. One team of stakeholders, business analysis and engineers can easily spend multiple person months or even a person year (or years) producing 60 pages. If you have a blended team salary rate of $90K, then each page costs $1,500. And you haven't built anything yet!

"No" you might be answering resolutely right now, "but we know know what to build! And we have a plan to build it."

True. I've worked this way too and I know that it helps to reduce the risk of development in the long run. You can plan for a three-phase development effort, get the budget lined up and all that. However, please consider an alternative.

Your team knew -- on day one -- what was the most important functionality needed. You, and they, don't need 6o expensive pages for that. Here's how it would work for you when you Get Real.

Two good engineers and a business analyst -- your development team -- meet with the key stakeholders. The stakeholders are asked to identify their top problems within the problem space. Then they have to choose only one. The top problem. Your development team ask enough questions to fully understand that problem and how it relates to the other top problems.

Then, they go away and produce something small to fix that top problem and only that top problem. This takes three weeks. After all, they are focused on only one key important problem.

Next, the key stakeholders begin to use the new application. After one week, the team reconvenes and the development team learns what works, what doesn't and what the next most important problem to solve is.

At this point, you've spent a tiny fraction of the expense and effort of that functional specification we taked about earlier and you have an application that, hopefully, solves an immediate business problem. If it doesn't, it has shone a big, bright light on that problem. How much longer do you think it will really take your development team to get it right? One more iteration? Two? Fine; because at that point three months will have gone by and you will have a demonstrable ROI. Compare that to a functional spec that takes six to nine months to write. You are seriously ahead of the curve.

OK, another valid concern is that when your development team learns about the next problem they will have to throw away a lot of what they've done. And they might. This is why we focus on solving one problem within the context of the larger scope. However, it is critical to solve only one problem at a time. Fix the problem you have today, not the problem you anticipate having tomorrow.

The way to do this is to build only what you need to fix that problem. Build less. What is the smallest, most elegant solution to the business problem?

Keep in mind that the business problem might not be the problem the users report. They may be unhappy with emailing spreadsheets around and want the population, generation and transmission automated. However, what they really need is a way to exchange and store information centrally instead of relying on spreadsheets.

Thanks for reading. We will continue to peel back this onion in the next essay on Getting Real in your corporate development shop.

Using Getting Real Concepts in the Corporate Office

The talented and intelligent folks at 37signals have created some great applications. As major contributors to Ruby on Rails, they also have been fundamental in building and leading a revolution in rapidly developed, high quality web applications. 37signals is successful because they think creatively about the problem that they are trying to solve. Fortunately for all of us, part of that thinking is that they should be open and transparent with many aspects of their process and business. Therefore, they often preach about the practices that have helped them attain success.

Anyone can read their preachings online. For free! It's a great concept, and one that is often encouraged by industry leaders -- think Seth Godin for one.

You can also purchase a high-quality bound copy of their book “Getting Real” from Lulu.com. I have because I like being able to read when not in front of the computer. It’s all laid out in their book (the exact same copy in the web pages, downloadable PDF or book) – their philosophical approach to clients, development, hiring, customer service, and so on.

When I became aware of 37signals , I was developing Ruby on Rails web applications. Because I was creating web apps, which is clearly the focus of the book and philosophy, I found myself agreeing with just about everything they were saying. And hey, I’m a software development veteran.

I’ve done this for years and years and have focused extensively on managing complex projects to successful deliveries. I’ve been through waterfall, spiral, iterative, agile, ad hoc, chaotic, random and panic-driven development models. I agreed with what they were saying because it makes sense and I was able to make it work successfully on my projects without any pain or difficult transitions. There aren’t many “new” development philosophies about which that can be said! For light, flexibile web apps, “Getting Real” made total sense and, more importantly, it worked.

But what about corporate environments with ongoing development efforts? These shops have a different set of starting points and different base assumptions. What if you aren’t developing a web app? What if you aren’t focused on revenue generation with your app? What if your users are waiting for their application and have expectations about how it will help them?

Can your corporate development efforts also Get Real? Yes, I believe that they can. let's look at the components of Getting Real that will help your corporate development teams use the principles from Getting Real to improve productivity and stakeholder satisfaction levels.

Let’s start with some of the key concepts of Getting Real that are directly beneficial for all development efforts. (Links are to the essays on those concepts)

1. Build less. Build smaller applications with only the most important features and deliver it quickly.
2. Focus on one idea. Start with the big problem, build the large scale functionality and don’t sweat the details.
3. Get something functional and useable deployed quickly. Plan on your next release right away. Make a choice and go with it.
4. Start with the UI design and focus on how your users will use your application.
5. Focus on fulfilling business stories, not big specification documents.
6. Keep your developers on the front line of support
7. Be willing to radically change the application to make it better. Resist the urge to make one monolithic tool to solve everyone’s problems at once.

Notice that these nuggets are completely environment, tool, and technology agnostic. There are some radical ideas that will doubtlessly shake up the “way things are done”, but these are the right ideas to grab onto and the right changes to make.

Fortunately, there are some components of Getting Real that an internal corporate development group can safely ignore right off the bat. For example, you’re probably not looking to generate revenue with something like an internal workflow enhancement tool. Not that you can ignore development costs or the value proposition of the development effort, but at least your users won’t be facing the prospect of paying a monthly fee. (Although, there may be something here….)

You can safely ignore the need to market and promote your application extensively. Please note the qualifier. The new whiz-bang tool you’ve developed for Operations is straight sunk costs if end users aren’t using it. Therefore, they do need to know about it and they should be excited about its arrival and feature set. But that should come from good communications and interactive product development and not from promotional marketing campaigns. Trumpeting successes is always allowed, however, so some allowance is made, but we’re not talking at all about the same degree of importance of marketing discussed in the book.

Most importantly, as you – the development lead, manager, director, VP, CTO, Whatever – read Getting Real, you can insert your favorite technology du jour whenever the book talks about web applications. The thrust of web apps in Getting Real is their rapid deployment and instant accessibility to customers. No CD burning, no distribution efforts, no retail operations, etc.

But let’s face it, how long does it really take to deploy a new version of an internally developed application in your shop whether it was written in C++, Java, Lotus Domino, C#, .NET or Ruby on Rails? If you’re thinking “weeks”, then you’ve got another problem, don’t you? You can quickly push out new applications through automated corporate update mechanisms, internal web sites and internal installers with the exact same degree of responsiveness that is the base assumption in the book So don’t sweat it that you’re not making a web app. The underlying philosophies in “Getting Real” remain pertinent, applicable and valid to you and can revolutionize your development centers.

The next essay will look at those seven take-away concepts in greater detail and will focus on how you can leverage these concepts to make high quality software faster.

Desperation in the business world

I see things that strike me as acts of desperation.  Yes, the economy is bad, bad, bad.  For an indication of just how bad, you should really spend some time viewing The Crash Course at ChrisMartenson.com.  

However, I've noticed some things that are real strong indicators that marketing and product folks are getting desperate.  Here are two of them:

Trader Joe's.  I love Trader Joe's.  I get really good quality food at great prices.  For example, we try hard to eat organic when it comes to raw foods; milk, eggs, veggies, fruits, etc.  As an example of the great deals, TJ's sells a gallon of organic whole milk for around $5.98.  Shaws and Stop and Shop also sell gallons of organic whole milk, but for around $8 a gallon.   

TJ's used to sell a pound of organic romain lettuce in a bag of three heads.  It was a great deal and in the Summer, my wife and I would go through two of those bags a week.  However, a while ago -- could be a year, could be longer -- I noticed that the bags were lighter and were now being sold in 12 ounce packages.  Same price, but we were now getting 25% less.  That's a big increase. Last fall I noticed that some of the bags felt noticably lighter yet again.  That's because they now sell "Three heads of organic romain lettuce"  No weight indicated.  I promise you, some of these bags have three scrawny heads of lettuce in there that barely top 8 ounces.

Same bag, same big title, a tiny fraction of the value.  

Here's the second thing.  One of my credit card companies called me and I finally answered -- I hate being interrupted during family time.  Ms. Dublin politely identified herself and thanked me for being a long-standing member.  Then she asked my permission to read a paragraph and record the remainder of the conversation.  I initially assumed that she had to notify me of some change in the terms, but was puzzled why it had to be over the phone.  Since she was simply reading a paragraph, it didn't seem like she was trying to sell me something.  But there was that recording part.  Hmmm.

In the paragraph she said that they would be enrolling me in a program that would monitor my credit reports and notify me of any changes or threats and that after some introductory period, they would bill my account $9.99 a month.  It seemed that the company was trying to say that by listening to the paragraph I implicitly accepted the terms of this service that they were foisting on me.

I said that I wanted it clearly understood that I do not want any such service and that I am not agreeing to accepting any such program.  Ms. Dublin replied that I have the choice of opting in, but by accepting enrollment, she would simply send me the materials.

Really, what kind of malarky is this?  You want me to look at the materials?  Fine.  Send them to me.  However, you don't need me to agree, on tape, to have you send me the materials.  

So, I felt it necessary to state again that I was not accepting any enrollment in any such program and do not want any charges to be applied to my account for any such purpose.  Furthermore, it seemed that by accepting enrollment in order to get the materials, the company was equating that enrollment with accepting the automated billing of this service and I wanted it clearly understood that I was not accepting any such service levied to my account.  

I'm glad they were recording that.  :-)  Ms. Dublin thanked me and hug up.

The lesson here is that both of these programs are tricky and underhanded.  I love Trader Joe's a good deal less now and I do not trust this credit card company at all.  

Is that really the way we want our customers to think of us, our products and services and companies?  Nope.  It's baaad policy.  Baaad products and baaad practices.  

Don't surprise the customer!

I recently purchased a replacement toner cartridge for my laser printer.  I really, really wanted an OEM cartridge.  My experience with compatible ink jet cartridges were unsatisfactory and even though OEM was significantly more expensive, I believe that's the way to go for the best quality results.  Since I use my laser printer for business correspondence, it is important to have crisp, clear copies.  

Furthermore, as a toner cartridge for a SOHO printer ages, the light sensitive imaging tube becomes less sensitive and the copies start to come out grey.  So, simply refilling the toner powder won't do either.

However, I was horrified to see the prices for the OEM cartridge.  Nothing less than $75, some over $85, and then there's shipping! Yowza!  $120 for a cartridge -- I could practically purchase a new printer for that!  I seriously thought about it, but knowing that my wife would kill me for such blantant consumerism, I went back to looking for a replacement cartridge.

I Googled, and Googled.  Seriously searched for an OEM cartridge that would be less.  I would have been happy with $60 shipped.  I was delighted to find a site that was selling a cartridge for $32 shipped.  That's was the same price as the compatible and refurbished cartridges.  I check and double checked to make sure that this was an OEM cartridge.

The product ID was the same as the OEM ID -- "ML 1210D3".  Check

The product description was the same as the OEM -- "Samsung ML-1210 D3".  Check

The description did not say "compatible", "refurbished", "refilled" or any such thing.  No where did it use those words on the product page.  I even searched for them. Big Check.

I placed my order satisified that I had finally done it!  I found a site that was selling OEM cartridges for deep discounts.  I was ready to trumpet the value of this place.

However, when the product came, it was clearly a knock off.  I called and emailed the company.  I pulled my receipt.   Yep, "Samsung ML-1210 D3"  I was not expecting a knock off.

I got a response in less than 24 hours.  Here is the first line:  "If you would have read our paragraph about what we do on our homepage you would have read we provide toner replacements for expensive name brands(OEM)"

I never saw the home page.  I came to the product page from a Google product search.  I never saw -- and I looked for -- something that said I was purchasing a knock off brand.  In my mind, this is a complete failure on behalf of the company.  It's folly to assume that your customers are (1) going to enter your site on the home page and (2) read it if they do.  

This isn't right.  I will not ever do business with this company again for any reason whatsoever. There isn't any need to.  They have so much competition and their products and their service is an absolute commodity.  Plus, they surprised me and then blamed me for it.  By the way, I did look at the home page.  It does say that.  Right in the middle of a paragraph of text that I never would ever have ever read ever.

Here's the take away lesson:  Don't do this!  Do not suprise your customers unless it makes them very, very happy!

If you are in the product industry, you must make sure that your customer knows what they are getting and are satisified with the value of the product.  If you are in the service industry, you must ensure that your customer knows what they are getting and are satisfied with the value of the service.  Unpleasantly surprising the customer is the very best way to kill your up sale potential.  

But, Peter, you say, I can't spend all day hand-holding every customer.  Sure, OK, I'm good with that.  However, you can -- and you must -- ensure that your customer knows what they are getting.  Period.  Your promotional material, your descriptions, your literature needs to be complete and honest.  Because you can't afford to acquire a new customer for every single sale.

You might be interested in which company it was.  I was initially going to reveal that, but I decided not to make this a "bash the company" posting because I really want the lesson of good customer relationships to come out.  So, I'm not going to say.

A great demo movie

Boy, I wish I had an active project RIGHT NOW. Because I just watched the FogBugz demo at FogCreek.com. This was the most enjoyable and informative demo movie that I have ever seen. Bar none.

The CEO, Joel Spolsky, and one of the programmers, Babak Ghahremanpour, talk casually about FogBugz, which is a hosted or in-house project management system. Their dialog, which is friendly (except for when they rip into poor Milton Richie), informative and interesting, told me everything that I could want to know about FogBugz's functionality.

I am so excited about this that I have even done my normal due diligence of looking for reviews and independent assessments. I'm ready to start my free trial, just because I can!

Hmm, maybe they need a really great product manager. Gotta go.

Three really good product management blog postings

While researching various aspects of the health care industry, I came across this very excellent blog post by George Van Antwerp and decided to post it along with some others that I've enjoyed reading.

First, Mr. Van Antwerp's Lessons Learned. This is a delightful essay with which I found myself nodding enthusiastically throughout.

Next, his sub-post on Product Management 101. One take-away is to always have your elevator pitch ready.

Finally, I'd like to shout out to Sem-Answers on his Niche Market Research posting. I like the list of research resources provided here. (Also, by putting the link here, I'm confident I'll be able to find it in the future :-)

People and organizations who have helped us

I mentioned in my open letter that my family has received unanticipated generosity from our community. I would like to publicly thank the specific organizations that have helped us and, in doing so, promote them as well. I would also like to thank and mention some of the people who have been so helpful.

I would like to start with the Stoneham Public Schools. The schools have supported us in lunches for all our children who have lunch in school (three of the five), as well as supplying gifts for the children. The elementary school children received toys for the holidays and the middle school children received winter clothing and toiletries. In gratitude for the support that we have received from Stoneham, any resident of Stoneham may purchase a Hold-it! Game Card Organzier for 1/3 off the retail price. If you live in Stoneham, enjoying playing board, card and/or roleplaying games, please contact me through the Innovatium web site to receive your Hold-it! at this special price.

The Winchester Community Music School has been outstanding in providing scholarships and grants so that our children, whom we think are very talented (but we may be biased), may continue studying music. The programs at the Winchester Community Music School are simply outstanding and the teachers are inspiring and nuturing. If you or your family are local and study music, you deserve to examine this organization and considering studying there.

The Little Gym in Woburn, MA was unhesitating in offering full scholarship to our four younger children who enjoy gymanstics there. When we decided that we needed to drastically cut expenses, we informed the folks at The Little Gym that we wouldn't be able to continue bringing the children. They asked us -- yes, asked -- to please continue bringing the children because they enjoy it so very much and are a positive addition to the class. And our kids do so enjoy it. Our six year old son does not stop cartwheeling and handstanding around the house. He has been practicing his counting by doing some 200 cartwheels each weekend and announcing his progress throughout.

Our oldest daughter, who enjoys performing, wanted to audition for the Winter Show with the Stoneham Theatre Young Company. The Young Co. made it possible for her to participate and perform with a significant scholarship.

There is also the Burbank YMCA in Reading, MA. As with other organizations, we informed them that we were not going to continue bringing the children for swim instruction and the Burbank YMCA responded with generosity. They have dramatically cut our family membership rate and has provided full scholarship to our children for their choice of swim class. Our older daughters are getting more serious about swimming and are now able to participate in the swim team preparatory course, which had been financially out of reach.

But wait, there is more! John Conserva gave us free piano tuning. John has done amazing work in maintaining and restoring our old, second-hand piano for as long as we have had it. He has kept it alive and tuned so that we have a means to teach and practice music in our home. John does all sorts of piano repair and maintenance as well as piano sales. Please, please, if you are local and have a piano, give John a call at (781) 438-7649. Let him know that the Degen-Portnoy's recommend him highly.

Alicia Gordon, of Gordon Lower PR, arranged for my wife and older girls to participate in a fund-raising event and raffle for the Turtle Lane Theatre. Because they were able to participate in the raffle, they won an amazing gift that includes head shots, voice lessons, and scholarship to the summer workshop and camp.

Erin Barry, of Stoneham, arrived with a gift card for food, an anonymously given (and sizable!) check, plus spent a significant amount of time calling the Toys for Tots program so that my wife could select some presents for the winter holiday for the children. Mrs. Barry already has eight of her own children, but nonetheless spent a great amount of her time and brought a tremendous amount of warmth and joy to our household. Thank you and blessings on you, Erin.

Martin Kruse, one of our neighbors, brought over one of his amazing holiday cheesecakes. Martin has been perfecting his recipie for years and perhaps will someday let the public at large enjoy this glorious experience. I can honestly say that I am saddended that my teenager now really enjoys cheesecake.

There are many more people to mention, such as family and other friends. My sister and her sons, my nephews, have asked that my family receive the gift money that would have gone to them. The even sent us a check to help us directly. My parents have been unhesitatingly supportive and generous, as have my in-laws. My best friend, for whom we often sit his dog while he and his family are away, has quietly slipped some cash into his thank you cards.

Those are organizations and some of the people that have, to date, helped us. We are meeting with additional groups that offer support for utility bills and food. Of course, we are supported by the Massachusetts Unemployment Assistance program and the Medical Security Program as well.

The value of these gifts are far beyond their monetary worth. The children understand (to varying age appropriate levels) that these are hard times. They were prepared to not have the opportunity to study music or performance or to participate in sports. Now they understand more about the value of these activities in terms of the personal growth and experience that they bring.

Hopefully, my next opportunity will arrive soon and we can begin our recovery and look toward returning the generosity we received. So in that light, if you need someone outstanding to lead the development of your software or web products, please get in touch with me. From me and my family to you and yours: we wish you a beautiful and wonderful 2009.

Re-examining Assumptions

Last Friday I met with someone who surprised me in a way I've not been surprised in a long time. This experience has sat with me since then and is inspiring me to re-examine my assumption model.

You see, the meeting was a first conversation about a position in a company and, truth be told, I was very unsure about the prospects and viability of the company. It has been in existence for over a decade, has a good size staff, but, although a web company, did not have significant traffic and, although established, had significantly lower revenue (and higher percentage overhead) than I had expected and with which I am comfortable. In short, there were warning flags.

My assumptions were that the company was not fully executing on its potential, or that perhaps the competition caught up to it and surpassed it. So that is where I focused my pre-conversation research.

The person with whom I met on Friday impressed me. First, he wasted no time in spelling out that he expected significant growth and he laid out the core thinking to his expectations. He made sense and had a fresh perspective on the problem, which is that the company's traditional domain is no longer its current domain, or more accurately, its current growth opportunity domain. The company has to move from one focus -- let's say "newsletters and messaging for the on-line widget industry" is what the company believes is its current domain -- to a new focus -- let's call that "automated marketplace for connecting widget manufacturers to widget consumers" as its new domain. This person's thinking is revolutionary for the company.

Unfortunately for my "pre-screening interview", it was also revolutionary for me. I assumed that we would be talking about one thing -- the company's market position, brand, existing product line, and immediate growth strategy -- so I didn't scour the information I had sufficiently to anticipate where the conversation would go.

From my project and program management experience, I know that it is critical to identify and document the personal and project assumptions for efforts. One of my favorite books on risk management, "Risk Management, Tricks of the Trade for Project Managers" by Rita Mulcahy is a canon that embodies the assumption identification in the processes. I've used assumption identification to pull out critical risk factors in my product management work; it's been a huge differentiator that has helped me get past personalities and focus on functionality, opportunity and risks in new product development.

So I am more than chagrined that I slipped on this. That made me wonder if assumption examination is part of the professional zeitgeist. It doesn't seem to be. Looking around for conversations on how assumptions are recognized and incorporated into various processes, I found an article from EE Times Asia on Re-examing Assumptions, plenty on assumptions at the software engineering level, a little blurb on program risk management from PgMP by Paul Sanghera in Google Book Search, a news article on SEI from 2003. Much more on the engineering side than the business process side, in my opinion, although New Product Forecasting by Kenneth B. Kahn has a section on assumption management that caught my eye.

There is opportunity here. Seemingly there is need for some assumption evangelism -- how are you going to check into your working assumptions about the important things in your life? I know what I'm going do about it in mine.

How to stay postive when unemployed

Oy veh, have you read the paper? It can drive you meshugga!

Seriously, Fidelity, which had laid off 1,300 announced another 1,700 jobs will be cut. JPMorgan will be cutting jobs. Citibank lays off some 75,000 people over the past few months -- that is three times the size of my suburban community!

So there are a lot of folks who are looking for work. I met a woman who has been looking for another position as an office manager since last July. She wasn't very positive at this point.

No one argues that times are hard. A lot of experts believe that they are going to get harder before they get better. So, no one would fault you for feeling sorry for yourself should you be in the position of needing to find a new position. However, it's the worst thing you can do for yourself.

In just the same manner as sound business theory dictates that one should save cash when times are good and spend when times are bad, one must stay positive when one is in a tough position. If you are depressed, you will simply not be doing the things that you should be doing. You simply cannot afford the luxury of staying depressed.

In the hopes that someone benefits from seeing that they are not alone in tough times, here are some of the things I do regularly to keep myself positive and recommend them enthusiastically:

1. Count your blessings. Seriously. Daily. I do. My wife, my children, my health, my skills and experiences, my well-trained dog. Everything. And I do it vocally. Here is what I said to my wife this morning "Good morning, my love. I am so glad that you married me." That wouldn't be too hard for you to do, would it?
2. Enumerate your strengths. Call 'em out. Your years of experience. Your doggedness. Your perseverance. Your ability to judge people. Whatever it is that you know gives you power and ability.
   
3. Mitigate your weakness. Whether you feel you procrastinate, or you do not negotiate well, or you do not follow through, or you loose your temper, or whatever, there is a way you can mitigate these failings. First of all, you are in control of your life. You can make amazing things happen. These things you do not like about yourself are not fatal characteristic flaws -- otherwise you would already be dead! They are risks to your positive life style that you can identify, mitigate and control.
4. Write down your Values and Goals. List your Abstract Goals (long, healthy life; financial security; etc.), Concrete Goals ("A position as such and such earning so much annually") and your Immediate Goals (Two high-quality job applications today and four follow-up calls). Read daily out loud.
   
5. Exercise. Yes; take time for yourself to do whatever you need to do as exercise. Whether that be walking to the library for a new book, going for a jog, or swimming a mile, get yourself out of the house. There are tons of reasons why exercise is good for you, so only a great fool would deny themself such easy benefits, and you are no great fool, so what are you waiting for?!

We are here on this earth for such a short period of time and our opportunity to create things of wonder and beauty that outlast us shoots quickly by. So don't waste a moment. Your dreams are converted to goals as soon as you make a plan and start following it. The first step to achieving those goals is to be positive and believe that you can accomplish your goals.

I would very much like to hear what you do to get yourself positive when you're feeling down. Please take a moment to click on the "comment" link below and send me your ideas and practices.

Software Development Process and the Start Up

Start ups are great places, if you like that sort of thing (and I do). Small groups of individuals infused with the entrepreneurial spirit working intensely on their Next Big Idea is invigorating. Strong, smart people can make a huge difference, albeit sometimes with herculean efforts, but at some point (more on this later), you launch.

Then you go right back into it the next day.

Which will eventually burn you out.

But greed and excitement are wonderful things, so you muster your energy, take a deep breath and dive back in. The launches are satisfying. The acknowledgment from your peers and management are satisfying. The accolades, press releases, funding efforts, and the promise that you are contributing to the Next Big Idea are all satisfying. But you know that it can't continue forever; that at some point the company will need to cross over from Commando stage to Infantryman stage and then eventually to Policeman stage (use what ever stage names you prefer here).

So here's the question; What do you need in terms of process at each stage?

Let's work our way backwards. No one would be surprised to find a mature CMMI and ITIL led organization at the Policeman stage. Some degree of CMMI maturity would quite natural for a company at the Infantryman stage, say CMMI maturity level 2 or 3; repeatable and documented process, improvement processes and some feed back capability.

But what about Commando? What about start ups? Eventually the commandos will move on and the company will be taken over by Infantrymen, but that could take years. For how long will the Commandos be running on their own gumption?

Those who live by process know the value it brings; reduced flailing, more reliable delivery, lower defect rates, greater alignment to business objectives. However, there is the challenge of perception to overcome. Perception that process interferes with creativity, introduces bureaucracy, hinders agility and is too expensive. Especially within the start up environment, which is often Cowboy development. "We have smart people, we don't need all that process stuff"

Poppycock and balderdash.

This is a simple case of "enough." Just enough process to deliver effective products. Just enough framework so that everyone knows that stages. Just enough practices so that a repeatably effective cycle can be created. Just enough monitoring and feedback to that mistakes are not endlessly repeated. Just enough borders to ensure that goals are repeatedly redefined to the point of ineffective thrashing. The basic check list is short:

• Short, but effective cycles -- this allows for flexibility and redirection without throwing away effort.
  
• Clear deliverable at the end -- the thrill of victory is a strong motivator
• Clear success factors -- New features in this build? Then only new features. Bug fixes? Then only bug fixes. One new feature and three critical bugs? Fine; do only that. What is the least amount that you can do to be successful in solving todays problems.
• Blessing and direction from senior management -- no sponsor, no work. The stakeholders decide what is the most important thing for them to have.
  

It is quite possible to respond to the short-cycle real-time demands of a start up. After all, the start up is first an idea. That idea will be tested by your customers, who will then tell you what business you're in.

All that stated, you have product to deliver. There is time pressure, and although there are unending pressures to constantly change, tweak and improve your product, you simply HAVE to launch. You HAVE to get to a launch date and the product MUST be released. Never loose sight of that.

So then the next question is "How can you manage the exchange of endless pressure with the real-time need to deliver?"

This is the job of product management. Product management starts with industry and market knowledge, time to market and market opportunity, cost to develop and return on investment. The funnel of endless ideas must be quickly and efficiently evaluated by a capable product manager. The value of the idea needs to be quantified without romanticism. The cherry picking becomes much easier at this point.

In summary, enough software process in the start up will produce superior products more effectively than ad hoc or heavy handed models. Focusing the development work on valuable efforts comes for successfully vetting the opportunities and defining the critical success factors.

There Is No Box

Here is a concept that came to me a while back when I started my own product development company, Innovatium: "There Is No Box"

The reference, of course, is to "out of the box thinking." That was practically a mantra at a previous company. At the time it was a good mantra. Engineers had a tendency to look at a problem from their perspective and apply to it their known solutions. The Out Of The Box mantra helped to express that, as engineers, we needed to push ourselves out of our comfort zone for more creative solutions that would benefit our customers.

For example, did we really need a $24,000 multi-card computer when two $4,000 PC's networked together would do the trick? We came up with all sorts of new things following that mantra.

However, it's not enough.

The typical problem we encountered (and I lived it at multiple companies and through multiple projects) was that we were thinking outside of the engineering box, but within another box. We often failed to understand our customer, their business, their priorities, their fears, and other critical factors.

What I learned from running my own company is that there is no box, so don't go climbing into one. You are not beholden to following the "way things are done". There are problems to solve and there is creative thinking to solve those problems. Ignore good experience at your peril, but don't limit yourself to doing things the way they worked last time just because it worked last time.

Remember, remarkable things are not often accomplished by mediocre people. If you want to accomplish something remarkable, you need to be willing to risk yourself in the pursuit of that thing. Just stay focused on the goal -- creating something remarkable for your customer -- and don't get fettered by someone else's ideas about How It Must Be Done.

Getting Pulled in Two Directions

OK, I admit it. This is all new. After many years in customer software development, consulting and contracting, I needed to build something. I started Innovatium to be able to build things that I believe folks will like.

Well, maybe I've exaggerated a bit. After all, I've been building things for years; working with vendors, making schedules, backup schedules and contingency plans. So it isn't all new. But back to the point.

I recently came across two very different pieces of advice. One comes from Ali Summers, at Specialty Retail Group. She wrote a rant on the Game Industry Network (GIN), which you can read at tribes.net. I can't help but feel that she is speaking directly to me. After all, I focused on getting my product right, not on the marketing of it (things like "master cartons" and a UPC). Not that those are bad ideas, they are very good ideas. And even though I made most of the errors she warns about, there really is only one part of her rant that sticks with me, but it isn't on the Tribes site.

In the GIN version, she recommends that one approach a new venture cautiously (I'm paraphrasing here), and that one doesn't invest all one have into new ventures, but rather us funds that one can do with out -- you know, extra money.

In counterpoint to this, I read at LawLawLaw, the excellent blog of attorney Erik Heels, Eriks advice on Intellectual Property. In this piece, Erik advises "...quit your day job. It's 10% inspiration, 90% perspiration. In order to succeed as an entrepreneur, you have to commit to it 100%."

I like both of these people. Ali is smart and knows what she's talking about. Erik is also smart and also knows what he's talking about. I look forward to following Ali's advice in the future (especially when we develop the next product here at Innovatium).

But for now, I think that I'm going to err on the side of Erik's advice vis a vis entrepreneurial esprit. I think that it is right to dive fully into this.

I am very proud of what I have accomplished in the past few months. Yes, I could have done better. I wish I knew Ali when I was getting started. But as my beloved wife said upon entering this endeavor, "No pain, no gain."

Thanks for reading