Archives

…or the telephone game

photo credit: tallkev

Last weekend I was watching a movie with my kids. In the movie there was a chain of monkeys that needed to pass on the message from one character to one on the other side of the chain. The message went something like, “Don’t throw us over the wall. There must be another way. We will all be killed.” As it went through the chain and the receiver heard, “Throw us over the wall. It’s the only way. Banana.” The scenario seems ridiculous, but its roughly equivalent to how many companies approach software product design. Often times companies don’t realize they are creating a product at all. They think they are just running a project and focus only on delivery of that project as if it is the only artifact of their work.

The problem stems from the fact that when organizations reach a sufficiently large size they must focus on consistency of delivery and efficiently using people’s time. For large organizations this is part of the mix that makes up their competitive advantage. However, the sheer size and number of moving parts required to enable clocklike consistent delivery leads to the most knowledgeable people about the customer never directly speak to the people responsible for building the product. Or translated into a traditional SDLC, the definition/high level design team isn’t communicating with the build team. In my experience they are usually two different groups of people. I’ll give you an example:

A while back, I was leading a software development team creating a product to be used by all 170,000 of my customer’s employees on a daily basis. They happened to have a team of user experience designers and wanted to take on the “big picture” part of the design themselves. This company could afford the best and the brightest talent – and was able to attract them. Individually the folks on this team were talented and knew their craft well. I actually learned a lot just from my brief time with them. However, once we got the design in hand it was obvious that the usability team’s artifacts weren’t going to work for the project. They didn’t meet the end user’s needs nor were they implementable within the time we had available for the project. The client’s design team literately spent months of time showing users lo-fi prototypes, running focus groups, and understanding usage statistics from similar applications. But, the simplicity the end users craved didn’t match the complexity of the business rules required. Upon further investigation the customer’s design team never was given a business level view of the problem to be solved. We tried to merge the business requirements with good usability, but ultimately the franken-design didn’t work. We had to throw out the big picture design and use them as ”guidelines” instead. Clearly it was a waste of talent and a haphazard way to build a product.

In hindsight the design team should have been presented the complex business rules so that their design could incorporate them from the beginning. However, the customer’s SDLC only allowed the design team to be engaged in the definition/high design phase of the project. Once we got to the design phase they were hard to find. By the time we got into the build phase the development team was simply a distraction from other work for these designers. A better model would have kept the designers on the project as each piece is built. I’m not suggesting full dedication to the team – 40 hours a week. That would be nice, but that’s not likely possible in most organizations. I’m suggesting a small time commitment over a long period of time.

Most of the time projects are actually building products. If you are building a product, but focusing SDLC metrics and efficiency, keep in mind that your phases are likely making walls around teams and causing ineffective communication between them. As Matt from 37Signals points out, “Inefficiencies are what make you special.”

Well-well look. I already told you: I deal with the god damn customers so the engineers don’t have to. I have people skills; I am good at dealing with people. Can’t you understand that? What the hell is wrong with you people?
– Tom Smykowski

photo credit: sdminor81

I get a lot of grief when I talk about agile practices and how it ends some inefficiencies, i.e. less personal activity during work hours by developers. One commenter on my last article on the benefits of pair programming put it thusly:

It is amazing how insulting people can get when waxing on about the benefits of Pair programming. It is one thing to make the business case to an organization that Pair programming can be beneficial to an organization, but it becomes downright mean when developers get classified as being lazy because they are not paired up. As someone who has spent many a night working (alone) for as long as it takes to complete a project on time without anyone noticing, I seriously disagree with the notion that by not pair programming, developers are lazy.

He’s right, but not for the reason he states. Pair programming is still better than solo programming in almost all cases. Treating developers like children, however, is a sin that is pervasive in many businesses. In my advocacy for pair programming, I was subconsciously pitching my message to product and development managers in large organizations.

Q: What is the NewNet?

a) The increasing prevalence user-generated information on the Internet
b) Push-web triumphs over pull-web
c.) Social media
d) An attempt to sell subscriptions to Om Malik’s new “research” service

Answer: d. GigaOm Pro: Fresh Internet buzzwords, unsullied by the taint of the latest crash. Can I have my Web 2.0 back, please?

All the good stories in agile software development start “three manufacturing efficiency experts walk into a bar…” But seriously, I think it’s clear that software development has a greater affinity to manufacturing than to construction. So, its good to see the Lean and manufacturing folks get a little blog buzz over at AgileSoftwareDevelopment.com with Jack Milunky’s post The 7 Software Development Wastes – Lean series Part 5 – Motion:

Waste #5 in manufacturing is defined as Motion. And motion can be compared to “task switching” in Software Development – as defined by the thought leaders applying Lean thinking to software development.

[...]

I have found in many organizations, especially software companies where there is a real casual atmosphere, it’s easy to always interrupt developers. Interruptions are prevalent with requests. All this interruption only serves to add to the Motion bucket of waste. This is where the importance of a Product Owner, ScrumMaster and Backlog come in. These roles and any artifact are there to buffer the development teams from the noise and chaos outside of the current sprint activities.

Sometimes being able to reference another discipline, like manufacturing, lends credibility to discussions with a stakeholder. More often than not, many consider themselves to be an expert on software development but wouldn’t dream of challenging an expert on manufacturing.

Related Services: Agile Development, Custom Software Development

I’m approached by people every week that think they have a great “new” idea for a web startup.   The ideas run the gamut from those that aren’t yet technologically possible to those “new” ideas that I have received 10 similar calls on over the past year.   Here are some things to consider:

Think about the business need and revenue model first.  Who are the users (your “customers”), what is the application or service worth to them, how many of them are there, etc.   If you can’t envision generating a million dollars plus a year in SaaS (Software as a Service) revenue or in gross margin for an eCommerce business, it’s probably going to be an expensive hobby, not a business.

Make sure you can create a sustainable competitive advantage.  What are your differentiators?  If you have to say I want a site like “xxxxxx”, you are probably starting off on the wrong foot.   You already have at least one competitor with a customer base.  

Software Development is difficult to get right. According to the latest figures, only 32% of software development projects are successful, and 43% of the features developed are not used. We’ve been successfully developing software for over 10 years, and have put together a list of 10 successful patterns (what works) and antipatterns (what doesn’t) based on this experience.

The first installment covered #10, Tools and Infrastructure.

#9 on the list is Respect the Process.

As a custom software development company most of our projects involve building new software that no one has built before. There are many things that are being done for the first time. Having a repeatable method is essential to making this less risky, and having the right one is critical.

In our case it’s a method that’s evolved out of agile and user experience design best practices, and includes lightweight, just in time requirements gathering and design, test-driven development, pairing, daily scrums, weekly demos, two week development iterations, agile estimation and velocity measurement. It encourages releasing early and often in order to get real user feedback, which we use to guide further development.

Daring Fireball had another insightful article on the contrasting product strategies of Microsoft and Apple last week. Well worth a read in it’s entirety if you’re thinking about your own product strategy.

A few observations were particularly trenchant and relevant to me in light of my own recent experience:

Microsoft is no longer ignoring Apple’s market share gains and successful “Get a Mac” ad campaign. But the crux of these ads from Apple is that Macs are better; Microsoft’s response is a message that everyone already knows — that Windows PCs are cheaper. Their marketing and retail executives publicly espouse the opinion that, now that everyone sees Apple computers as cool, Microsoft has Apple right where they want them.

They’re a software company whose primary platform no longer appeals to people who like computers the most. Their executives are either in denial of, or do not perceive, that there has emerged a consensus — not just among nerds but among a growing number of regular just-plain users — that Windows PCs are second-rate. They still dominate in terms of unit-sale market share, yes, but not because people don’t recognize Windows as second-rate, but because they don’t care, in the same way millions of people buy metric tons of second-rate products from Wal-Mart every hour of every day.

That’s the business Wal-Mart wants to be in — selling a zillion cheap low-margin items and turning a profit on volume. That’s not the business Microsoft is in.

The truth of this was particularly relevant to me because just a few hours before reading this, I had spilled a full glass of water all over the keyboard of my laptop. An occupational hazard of talking a lot with your hands, but one I’d successfully resisted for the last two years, since my last such incident. It’s a still rather painful memory.

This last weekend, my wife was sitting at the computer and laughing.  I asked what was so funny, and she showed me a youtube video by Sons of Maxwell, a band from Halifax, Nova Scotia, called “United Breaks Guitars.”   The song tells the story of how United Airlines broke the lead singer’s guitar, and the 12 month saga of trying to get reimbursement:

The video does not have a lot of production value, but its got humor, harmony, cheesy mustaches and sombreros. And it’s gotten over 2.6 million views over the last six days. Not bad for a band whose previous top video got about 25 thousand.

What does all of this have to do with software development? 

Some of the same things that make the video a runaway success will help you in developing software that’s a runaway success:

1. Solve your own problems. They’re their own target audience.  They know the subject, what’s important, and what’s not.  own subject.   They know they’re not alone, so lots of other people have this problem.  They’re passionate and that’s the best way to get others to feel passionate about it too.   As it turns out, their problem is shared by millions, and their solution literally strikes a chord with millions.
2. Be yourself. If they had been lawyers, they might have looked to start a class action lawsuit.  But they’re a band that plays whimsical, fun country music, and so they made a song about it.  They’re talented, not pretentious, and the song is catchy.
3. What’s the big idea? It’s pretty simple – United breaks guitars, and they don’t care.  The song has a simple vision, and it takes sides.
4. Have an enemy. Pretty self explanatory in this case, but it’s equally applicable to software:  “One bonus you get from having an enemy is a very clear marketing message. People are stoked by conflict. And they also understand a product by comparing it to others. With a chosen enemy, you’re feeding people a story they want to hear. Not only will they understand your product better and faster, they’ll take sides. And that’s a sure-fire way to get attention and ignite passion.”^*
5. Essentials only. The video production qualities are low, the marketing budget was probably nil, but the song is funny, the tune is catchy, the harmonies are sweet, and the message is dead on.

None of this is a guarantee of success, but it sure helps.

Sounds a lot like Getting Real, doesn’t it?

^* Have an Enemy, in Getting Real by 37 Signals.

Although I’ve seen so many players rise and fall over the years, what has inspired this post is the irony of what is happening to Microsoft. In the early years of my technology career it was Microsoft’s ownership of the PC O/S market that primarily allowed other compatible hardware manufacturers to create innovation and eventually marginalize IBM’s dominance of that market.

In the early years of PCs, the applications on top of the O/S weren’t even Microsoft applications. It was only later that Microsoft started developing their own applications and with them the predatory practice of squeezing out other application providers to rule the desktop.

photo credit: Marco Arment

Whenever I hear the plan uttered (and in my Wall Street consulting days, I heard this a lot), that we should build an HTML (or Flash) prototype, impress the client and then fill in the back end, an unwanted image comes to mind. We’re digging a hole (the missing 80% of the back end) and covering it with leaves (the HTML prototype) in the hopes that the client will fall in (impressing the client).

No, this isn’t a rant about HTML, Flash or paper prototypes. Those have their place, to be sure. We use them every day in our own software development practice, but they have a short lifespan — usually less than an iteration on the way to delivering the actual feature that it is prototyping. But when the prototype takes on a life of it’s own and becomes a long-term deliverable, that’s when you run into problems. What are these problems? They aren’t as numerous as fall leaves, but there are plenty.