I mentioned in my previous post, “The Real World”:

I prefer a short development life-cycle, keeping the requirements for each cycle short and to the point. The smaller the feature set, the shorter every sub-cycle is (design, testing, etc).

37signals recently discussed a great example of this concept with their “Public Contact Cards”. They saw a need, and delivered a solution to it within 48 hours. In order to do it, they kept a very tight focus on the goal of that feature. They solved the problem in the simplest and most direct way possible. They mention several features they could have added and didn’t. Some of them certainly sound like great additions as well, and you may one day see them. But, by keeping the focus on the problem at hand, they can act much quicker to market and consumer needs, keeping their customer base happy, and reducing the risk of implementing new enhancements. They also get a chance to see how their consumers react to the direction of the solution before they have gone to far down the road.

Read more about the Public Contact Cards they added to their new Highrise application.

In a post on their blog, 37signals asked for readers to comment in ten words or less, what the phrase “real world” means. They mention how frequently this phrase is used in IT; in fact overused. The question is, if it’s used that much, does everyone mean the same thing when they use it? Do they even know what they mean by it?

I think that certainly many people who use it have a definition of it deep inside their minds. They may not have vocalized it, and really thought it through, but they are aware of a principle which they refer to when they use the phrase. However, I think there is more than one definition or principle behind it. I think it all comes down to your perspectives and goals.

Some will look at the development principles of Ruby on Rails and think that in “the real world”, Rails can’t cut it. Others believe that Rails is a real world solution, whereas Java is a solution for bloated IT departments. Is either belief correct?

Once again, it depends on the goal. I have been focusing on learning Internet Marketing for the past three years. It’s been great to learn some skills that relate to the Internet world, but from a different perspective than web development. Once you get into the Internet Marketing mindset, much of your thinking begins to change. For one, every minute spent designing, developing, testing, and all the project management, team meetings and team management that goes into a typical IT department, is now seen as costly. When an Internet Marketing entrepreneur sees an opportunity in a target niche, they want their online product delivered immediately, because every day not online is lost money and possibly a lost opportunity. These entrepreneurs talk in terms of days to get some software written and online, as opposed to the months that larger enterprises consider for their project timelines.

It would be amusing to them, not to mention completely unacceptable, to be told that something was going to go through a kickoff meeting, team assignments, UML design documents, development, unit testing, weeks of QA and integration testing before going live. Ten developers, a project manager, three QA testers, a DBA, a system administrator, department managers, tech writers, graphic designers, etc. To these entrepreneurs, this much bloat is not “real world”. It may be considered necessary for a large corporation to be as “safe” as possible, but it’s not agile enough to respond to online opportunities. I’ve seen opportunities to make $250,000 that literally lasted only a month.

On the other hand, if you went to the Java enterprise development team and said, we need to have a web site that manages the following eight sets of data, with user registration (including email verification, lost passwords, etc), functionality for regular email notifications to subscribers, and a nicely designed front end, and we need it in five days, they would respond, “that isn’t the real world!” They probably couldn’t even find time to schedule the kick off meeting that quickly.

In my 12 years of web development experience, I have heard more times than I can count, the marketing department give a timeline from their expectations which the IT department countered was unrealistic and impossible. The marketing department is frustrated with the time it takes to get to market, and the IT department is frustrated with the tight deadlines and long hours it takes to meet expectations. This is the real world. A constant battle between business leaders and developers to get to market fast.

Only you can decide for yourself which real world you want to belong to. Myself, I used to belong to the IT department real world of all the steps needed to get to market, but as I studied Internet Marketing I began to see every minute of my time as cost and delay toward making money. Now I look for short cuts, not in quality, but in process and development time. Streamlining; cutting the bloat that has crept in over the years, particularly, from my point of view, in the Java Enterprise. I prefer a short development life-cycle, keeping the requirements for each cycle short and to the point. The smaller the feature set, the shorter every sub-cycle is (design, testing, etc). I prefer online task management eliminating the project status meeting, where 15 people take turns telling the PM the same information they could have entered into some software in five minutes. I prefer streamlined communications and small teams. Get the product out there, and immediately start working on an update. This provides for more flexibility within the market, and allows businesses to respond to perceived online opportunities quickly. It will also reduce developer stress and burnout. But, it also requires less development technology bloat, that I believe is now a large part of Java web development. Java doesn’t have to be bloated, and neither does the development life-cycle. But it has become that way, and it will take some outside the box thinking, and a different perspective to make the process more efficient, less stressful, more financially lucrative, and ultimately, a whole lot more fun.

According to an article on MSNBC, a study was done which indicated that meetings are not a productive environment for creativity. I could have spared them the money and time for the study. Getting involvement from all your meeting attendees is difficult, because people think in many different ways and in many different environments. Some are confident enough to speak up in the midst of others, and some like to think out loud. But, others prefer to hear of a problem, and then have time to themselves to ponder possible solutions. As well, many people are problem solvers, while others are those who like to shoot holes in everything. While that is a necessary skill set on any team, it is inappropriate in a problem solving, brainstorming meeting, and it discourages the creative thinkers from speaking out.

To encourage input from everyone, I suggest the following. Call a meeting to identify the problem, and warn attendees before hand that no solutions will be discussed. The goal for the meeting is only to identify the problem and any parameters involved. Then dismiss everyone. A good manager, who pays attention to the skill sets on the team, is hopefully aware of the team members strengths. After some time is given for creative thinking, call two followup meetings. The first will be with your creative thinkers. State at the beginning that it is a time for creative thinking and brainstorming and that no decision will be made in the meeting. As well, state up front that time will not be spent to critique the ideas and solutions. This is an idea generating time only, and is for your creative, outside the box thinkers.

In the next meeting, you will have your more analytical members who analyze everything without mercy. Present each idea to them and let them tear into them. If they have their own suggestions listen to them, but do not be surprised if they do not have any suggestions, but only propose reasons why none of the current suggestions will work. Record their objections and send them in an email to your first creative group, but do not identify who objected to their ideas. Give them time to consider them, and then convene again to hear their follow up ideas.

Continue this cycle, until a solution is apparent and can be chosen. Keep the two groups separate. If you are aware that some of your team members do not like to speak up in larger meetings, meet with them individually or in small groups of two. This more private setting will allow the less confident to have their say. You may also tell everyone after the first meeting, that they can email you their suggestions as well, again providing a method for them to participate but not in front of the group.

Be sure to keep every meeting focused on the task at hand, and when communicating between each team do not identify the originators of the ideas or the critiques.

This process works well to involve all team members, and to allow each to use their strengths.

Do you have any other suggestions for making problem solving meetings more productive?

Read the article on MSNBC.