Seth Godin is a bit nonsensical in some of his arguments for why small companies can compete against and even outperform larger ones (i.e. he cites the growth %’s of small companies compared to larger ones as evidence). Even though his latest book: Small is the New Big is just a compilation of his articles and blog posts, and does not have a unifying message (which I consider essential in a book) he does makes several good points regarding the effectiveness of small teams and I wanted to discuss a few of them here:

Small means the founder makes a far greater percentage of the customer interactions. Small means the founder is close to the decisions that matter and can make them, quickly. Small means you can tell the truth on your blog.

This may be the biggest benefit of smallness and is one of the key advantages Refactr has over traditional digital agencies and consultancies. The entire company is focused on the project during its engagement. There is is a real relationship between the entirety of Refactr and the client team. And yes, we don’t have to try to sound bigger than we are because we are not ashamed of our size.

Small means that you can answer email from your customers.

Another benefit of small is that you don’t have communication channels. Or more correctly the channels of communication are a circuitry connecting each team member with each other. No bottlenecks, no games of telephone.

Small means that you will outsource the boring, low-impact stuff like manufacturing and shipping and billing and packing to others, while you keep the power because you invent the remarkable and tell stories to people who want to hear them.

We are small enough to not have to worry about many of the things with which large companies must deal - administration overhead, interviewing, hiring, payroll, accounting, marketing, sales, we outsource any of these services that we need. Online payroll and benefits, external accounting and sales resources, and very low administrative costs all add up to more time and energy we can spend doing what we are passionate about, building great software.

A small law firm or accounting firm or ad agency is succeeding because they’re good, not because they’re big. So smart small companies are happy to hire them.

To succeed as a small company you have to be good. You are not afforded the “luxury” of being able to hire B, C, and D-teams to do the “less important project work”. Every project we take on is important and every project warrants and receives our best efforts.

The kind of project that’s “interesting” is now very different. It doesn’t have to be strategic or scalable or profitable enough to feed an entire division. It just has to be interesting or fun or good…

That is good news for us as we like to work on fun and interesting work and are able to choose work based on these merits and how they fit within our model, but it is equally important for the people who’s projects of which we are a part. Now entrepreneurs with a great idea are on an equal footing with large companies wanting to outsource a smaller project - each can take advantage of small, talented teams like Refactr and come out of the process with a great result. We have already had offers to take on additional resources or join larger organizations, but we have made a conscious decision to remain small for the foreseeable future for precisely some of these reasons above.

Kerry Buckley wrote a great post that made me laugh and think.

When people talk about large organisations making major changes to their core processes or values, sooner or later someone will compare the process to steering a supertanker – if you turn the wheel now, you’ll have travelled quite a distance before there’s any noticable change in course.

This analogy falls down when you’re trying to introduce agile software development. If you want to be agile, a supertanker just won’t do the job any more. It’s time for small teams to jump into the lifeboats and set off in their own directions, leaving the heavy old legacy systems to continue their progress on their predictable course. The lifeboats are far nimbler and can react much quicker to changing conditions.

I rather like the visual of agile teams racing around in swifter craft (though I would perhaps not have chosen the lifeboat, perhaps a hovercraft?) encircling and aiding the larger, more lumbering ships. We have been drawn to work with smaller companies and less entrenched processes because we saw good opportunities to connect and create some early successes. What Kerry’s analogy made me think about, however, is that nimble teams and new perspectives can be welcome in any fleet and that there is opportunity for cooperation and accomplishment in large companies looking to react and perhaps capitalize on speed just like the little guys.

This is pretty much the best description of how the Web works that I’ve ever read. REST makes sense, the Web has proven that; why is there even a debate about this? Sure, maybe there are a few places that would benefit from SOAP, but the vast majority of the time REST can’t be beat.

In Cargo Cult Network Administration, Esther Schindler in her weblog for CIO Magazine discusses an interesting problem that is similar to that of hiring and Interviewing Programmers. This is by no means a new idea, but it did get me thinking again. The example has to do with network administrators, but I’ve seen exactly the same behavior in developers - as I’m sure we all have.

… the dangerous stage of career development is the the cargo-cult sysadmins, who don’t know why what they’re doing works (or doesn’t work). But, because the magic worked in the past, they continue to repeat the same actions, under the presumption that it will continue to work.

Seeing people in action can help to reduce the possibility of hiring one of the Cargo Cult, but it’s sometimes difficult to see the difference between someone using a pattern or rule of thumb because they understand it and because it works and those doing the same without understanding any of the underlying principles. Often times, you really only find out which one you have is when something doesn’t work and they need to dig in and troubleshoot the problem. Just knowing where to start looking can be a good indication.

As an (only somewhat related) aside, I’m reminded of developers that have little to no understanding of general web principles, such as HTTP. They can do a fine job, but sometimes tracking down what is happening and why that something is happening (whether in your code or in a web framework), it helps to think about the actual interaction between the web browser and web server. Now, this isn’t even fully necessary to be a good web programmer, but I think it distinguishes those who understand what’s going on from those who just guess at (or just take on faith alone) why certain parts of code are being executed.

The other day I heard a piece on NPR about American Airlines involving their mechanics in making decisions about how to run a maintenance facility.

At first, [VP Carmine J.] Romano was wary of the idea that the only way to avoid bankruptcy was to start sharing his power with his union workers. But a deal was worked out. The 6,000 mechanics in Tulsa agreed to a significant cut in salary, benefits, and vacation. In exchange, the workers would have equal input in running the operation. Two years into it, the veteran company vice president is a true believer.

What was a dysfunctional relationship between management and the union has become a very collaborative one and brought the facility back from the verge of bankruptcy. To stay competitive, the airline needed to cut the time it took to do a major overhaul in half. The mechanics went to work and completely redesigned the way their work was organized.

This reminds me of Mary Poppendieck’s thoughts on Lean Programming - a term she coined after applying the principles of Lean Manufacturing to software development. Especially relevant to this story is Lean Rule #5: Empower Workers (Decide as Low as Possible)*:

A basic principle of Lean Manufacturing is to drive decisions down to the lowest possible level, providing both the tools and the authority for people “on the floor” to make decisions.

The thought is that those closest to the real work are in the best position to make decisions because they are the ones with the most information and they fully understand the implications of all the tradeoffs involved.

The idea of empowering workers to make decisions helped Toyota improve quality and productivity at a GM manufacturing plant. For American Airlines, it helped to involve workers in a plan to improve productivity at a maintenance facility, which reduced time and cost, while increasing quality. In addition, it saved the plant from having it’s work outsourced to South America and instead turned it into a profit center for the airline - in fact, airlines from South America are now flying planes to the US for maintenance at this facility. By sharing decision-making with workers, management was able to win concessions from the unions, which was also a big factor in saving the facility. Though people were initially skeptical of the plan, this agreement has turned out to be a win-win for both the union workers and American Airlines.

Hearing the story on the way home, I thought it was a brilliant move by the airline - and really smart for the workers to accept the plan as well. What really struck me was that management was willing to release full top-down control. It’s one of those things that makes a lot of sense to me - if you have competent employees, let them do what they know how to do.

_{* Apologies for the lack of a direct link, but there are no html anchors in the article.}

Jason over at 37 signals has a great post about the difference between trying something and using something.  This ties in nicely with something that I’ve been thinking about recently which is: what is the best way to interview potential new hires.  I started thinking about this after reading about the idea of bringing someone in to work with you instead of interviewing them.  This makes sense to me for a lot of reasons, not least of which is I’m a bad interviewer.  I never prepare enough in advance, I rarely have a set of questions ready to ask the candidate, and last, but not least, I never trust that they can do what they claim.  All of these problems can be alleviated if you just bring the candidate in for a day and work with them. In this case, interviewing the candidate would be like “trying” them, where bringing them in would be “using” them (I’m fully aware that the trying and using thing applied to people is starting to sound bad at this point, but I think you get my drift).

I would propose that once you’ve got your potential hires list whittled down, you should take your top candidate and ask them to come in and work for a day with you.  Don’t be cheap on this either, offer them something like $500 for the day, because if you find out that they are a bad fit now it’ll be worth far more in reduced headaches in the future.  Have them pair with a few different team members over the course of the day and then let them know (preferably right away at the end of the day) if you want to hire them. This would eliminate the risk you face and the worst case scenario for the candidate is they make $500 for one day of work.

Join me and the rest of the Refactr gang for the holiday edition of MinneDemo on Monday, December 11th at the Acadia Cafe near downtown Minneapolis. It should be a great time with a great lineup of demos and and a great lineup of beers on tap. Please feel free to come up and talk with me. In fact, you may not have a choice as I will be manning the check-in desk before the event.

I was raised Catholic and sometimes a neuron fires that brings back memories. Hence:

An agile reading of The Creation Story from Genesis (King James Version):

[Genesis 1]

Day 1: God said “Let there be light” and there was light. God divided the light from the darkness. And God called the light Day, and the darkness he called Night. And the evening and the morning were the first day.

Day 2: God made Heaven.

Day 3: God made dry land, which he called Earth, while He called the waters the Seas. On the land, he created grass, herbs, and fruit trees.

Day 4: God made the Sun to rule the day, the Moon to rule the night, and the stars to accompany the Moon.

Day 5: God created every living creature that moveth. The waters brought them forth and the winged fowl flew above the earth.

Day 6: God created Man (Adam).

[Genesis 2]

Day 7: God took the day off.

Later God let Adam name the animals, but Adam still felt alone.

With this new information [from God’s newest customer], God created Woman from Man.

In hindsight, it seems more obvious now that God did some of his tasks “out of order”. God wasn’t bothered that he created light three days before he created the the source of the light (the sun) or that evening and morning came and went before the sun and moon were there to mark them. God didn’t care that he made plants use sunlight yet there wasn’t a sun yet. Details. And one would think that since man and woman use mostly the same specs and parts that it would have made sense to make them at the same time, but God, the agilest, doesn’t roll that way*.

God’s process didn’t try to take on everything at once. God didn’t try to look too far into the future. He took each part of His project one step at a time and shifted priorities as new requirements were presented such as all the plants dying and Adam wanting someone to be with. God simply enjoyed each part of the project as it was happening, adding features as the “user” required them.It seems to me that God used a fairly agile approach when creating the Earth and He did an alright job, regardless of what we’ve done with His project today.

It may be a stretch, but it’s still fun for a Friday.

* note: sacrilege added by Ben

Today, Joel discusses how horribly the mainstream media reports on programming tools (and I would argue technology, in general) - specifically how there’s always a reference to a new tool somehow turning programming into something similar to putting together Lego blocks. The most interesting part for me in his post was at the end, when he quoted Fred Brooks from the essay No Silver Bullet (emphasis mine):

I believe the hard part of building software to be the specification, design, and testing of this conceptual construct, not the labor of representing it and testing the fidelity of the representation.

I’m not sure that Joel would agree with all of my own conclusions from that statement, but the way he quotes it, I think we would agree on the problem itself. Either way, it really made me think. Based on my own experience, agile seems to be trying to address exactly those concerns.

If the specification is one of the hardest parts, a fix for that is short feedback cycles. This, of course, is not an agile-only concept, but a it’s a defining quality of agile approaches, rather than just one way to do it. Another is not attempting to fully document the specification, but rather keeping an open dialog between developer and customer / business owner / subject matter expert.

Regarding design, some key ways to minimize “the hard part” include simplicity, refactoring, and the use of metaphor when building software - not strictly agile, but again, key tenets of agile approaches.

To address the testing of software, automated tests and continuous integration (to run the tests) definitely help. Additionally, short iterations make things easier for people to test functionality because there are fewer things to focus on. And an on-site customer helps to have a subject matter expert there for questions during the whole process.

The whole subject is making me give me serious thought to going back and reading The Mythical Man-Month again.

In a recent post, Microsoft employee, ahem… wildchicken hurls some rather ill-founded accusations at something that is near and dear to me. In his opinion (or actually the opinion of several unnamed “respected” UX friends of his) the agile method and effective user experience design are not compatible.

“In the case of user experience people, a friend on mine whose judgment I highly respect estimated that it would take about 2x to 2.5x the number of user experience resources to adjust successfully to Agile. This guy’s a UX director at one of the world’s largest software companies, and he’s been around the industry for much longer than I have, and he’s just an all-around smart, well-read guy. He’s not one to exaggerate. One reason for this estimate is that many UX activities can be done serially, so a fewer number of people can do them and they roll from one thing to another. With Agile, you would need to do many of the same things in parallel, so you would need more people to do them.“

I guess that would be true on very large projects, where one designer is trying to support upwards of ten developers, but in my experience, on small agile teams, iteratively designing the interface with continual customer feedback is far better than the old ways of having an intake meeting, (perhaps) presenting a creative brief, and then going away for 2-4 weeks and coming back with a “completed” design for review. On an agile team, I get to see what the developers are doing - the challenges that they are facing, while my concepts are still forming, and I can adjust to make better decisions with more information and context.

(more…)