Many times during the sales process we are asked to give a cost estimation based on our early understanding of an application’s core features. In order to responsibly and efficiently estimate, we conduct a 50/90 range analysis. We use this technique because we want to establish a responsible middle ground between our optimistic and pessimistic estimates. Our estimate is appropriately buffered for the risk we see in the defined tasks.

This spreadsheet is the tool that we use to conduct our analysis. Tasks can be estimated in any time duration that you choose (i.e. hours, days, weeks). At the start of a large project we generally estimate tasks in days or weeks.

I attended the tail end of Startup Weekend at The Factory this weekend. Kudos to Michael Boyink and Aaron Schaap for organizing this in West Michigan. Marc Nager, one of two people who run Startup Weekends all over the country, commented on the energy in the room and the incredible willingness of strangers to get behind ideas and work together. Evidently what we lack in VC we make up for in hard work and generosity.

The final pitches were pretty good considering that some of these ideas weren’t even hatched until Friday afternoon. An app for helping people keep track of things that need to get done even had a pretty functional backend implemented over the weekend. It was great to see eight teams and 40 or so people challenging the economic doom and gloom of our state, putting their ideas out there, listening to others, and taking action to make them real.

For a business that by definition occupies a highly technical domain, we have some relatively low-tech means of conveying information internally. Sure we e-mail, Twitter, Yammer, and even Skype with each other on a regular basis, but we also make use of yarn, note cards, cork boards, and old traffic equipment. I’m talking about our information radiators, objects around our office that align the team by sharing important information in a fun and hard-to-miss way.

Read the rest of this entry

Last weekend I had the privilege of attending a UX Agile Retreat at Cooper. The retreat was an informal event where ~33 practitioners from the UX and Agile fields came together to discuss how we can better create effective and successful products. The event schedule was loosely defined and it self organized based on the trending topics. We used a variety of exercises and discussion techniques to voice our experiences, concerns and ideas to help build a vision of a better, collaborative future.

Where We’ve Been

The UX and Agile communities have been flirting with how they could integrate their practices more seamlessly and respectfully. Both groups respected one another yet remained uneasy about having to alter their respective approaches for an integrated vision and process. UX Designers were worried that some of their practices would be minimized or marginalized due to Agilistas’ strong belief of minimal upfront design. Fear existed that quality design would be sacrificed to the almighty iteration once an agile project was underway. Agilistas were worried about designers doing too much work up front without creating functioning software. Developers were ignorant of the UX Design process and the immense value it provides. Individuals, like Jeff Patton and Lane Halley, have been working very hard to increase knowledge and respect between the two groups. Anders Ramsey organized and dedicated himself to making last week’s event happen. He did an outstanding job. The UX and Agile camps are coming together because they recognize and respect each other’s dedication to the craft of creating high quality products.

Where We Are

Most of our discussions during the retreat focused on vision, values and principles instead of outlining a strategy for collaboration. I’m glad the group was able to remain focused at such a high level because good process stems from alignment and a mutually shared vision.

We took a stand that the “Us and Them” mentality is dead and that we have to move forward as “We.” Management and business processes have kept our groups apart in the past due to a focus on efficiency and a misunderstanding of what it takes to create successful digital products. Management often times does not know how to ask us for what they want, nor do they know how to properly manage creative teams. We believe that we can create better products more efficiently by focusing on being effective. We believe that effectiveness is increased by working together closely.

The Future

The new vision is forming. The retreat group is committed to evangelizing and furthering this vision. I left the retreat with strong feelings of alignment, momentum and excitement. We are the makers of amazing, complex things and we are taking a stand on how we’ll bring the dreams of others into the world. We’re building a case for businesses to employ design thinking at all levels, to focus on the satisfaction of their customers and and to let individuals who understand the creative process to manage it for effectiveness.

We’ve always believed in hiring for brains, attitude, and general skills. This approach has served us very well, and while we’ll often chat with candidates about their specific technology experiences, that’s not what makes the difference in deciding whether to make an offer or not. Until fairly recently we’d only had the opportunity to apply this approach to hiring developers. Last summer we branched out some—I’m happy to report our strategy works for hiring Art Historians as well.

Yes, the Atomic art collection had really become unmanageable. From our original piece (an early nuclear-inspired gift from an aspiring artist who was a friend of my partner Bill’s mother) to a cast off (and semi-scandalous) discrete nude painted by an anonymous GVSU art student, we were really in a quandary as to proper display, cataloging, and preservation of our art. Oh, and pretty much everybody was grousing about answering the phones, greeting visitors, and watering the plants, too. So we decided to go looking for someone to help with a few of these things. The trouble was, we almost certainly didn’t have enough work for a full-time person, yet we needed full-time coverage. [Nerdy sidebar – we recognized that this position was all about response time, not throughput. Since our profit hinges on high utilization, this took some getting used to.]

Read the rest of this entry

In the article What Really Motivates Workers, the January-February 2010 issue of Harvard Business Review reports on a multi-year study of top performance motivators. Between these five contenders:

• Instrumental support
• Progress
• Interpersonal support
• Collaboration
• Important work

progress was the top motivator by a large margin.

(Unfortunately, when the researchers surveyed 600 managers they found that most of them believed that “recognition for good work” was the top motivational factor.)

I think the study explains why test-driven development (TDD) is self-sustaining once mastered. Large software projects done in traditional fashion may go for months without finishing or delivering anything. That’s a hard situation in which to see progress, and hence un-motivating. The same project done with TDD results in a smaller system becoming functional more quickly, daily progress as you integrate your working code and tests with others, and even hourly progress in the form of the “green bar” of passing tests. Progress is more visible and more reliably and regularly experienced.

The author also found that the most de-motivating days were those where people experienced the opposite of progress: a setback. Anyone who’s worked on a body of un-tested legacy code knows how common it is to make a change and break something. Setbacks are a de-motivating experience made more common by the lack of any test control.

Developers are motivated by the progress TDD brings and shows them.

A long time ago, in my first career as a professor, I started a file of nice words. The file had compliments, positive comments from evaluations, thank-yous, etc—nice words people had written about me. I never found a use for the file, but it seemed like a good idea to collect the raw data. In 2005 I resurrected this practice for use at Atomic, with a slight twist: when a client says some nice words about someone at Atomic, I distribute these words to the whole company. I don’t know how important this is to individual Atoms, but it seems smart to acknowledge when clients go out of their way to say someone did an exceptional job.

The nice words are typically about extra efforts, smooth deploys, great communication, effective project management, personal caring or dedication, creativity, predictability, or responsiveness. Very rarely they contain a technical compliment (“awesome algorithm”, “great tests”). But those nice words are much less common than the actual frequency of technical excellence in our projects.

I think this is because the benefits from our technical work tend to accrue long after the work is done. By the time our testing has resulted in no downtime or no user irritation, everyone has moved on and takes quality for granted. No one thinks back to the root cause of the pain they don’t feel. There are new problems to solve, new features, or new projects. It’s very easy to miss a critical element of what got you to this point in the first place. Think about it. When was the last time you stopped and appreciated a piece of software that’s run smoothly for years?

By contrast, the stuff that does attract nice words is much more immediate. When you get a prompt mail or return call, you know it immediately. When you see a project managed effectively, you feel it right now. When someone makes an extra effort to hit a deadline, you’re aware of it. Creative solutions to problems shine as soon as suggested.

Something that accentuates the under-appreciation of technical excellence is that many of our customers are business people, not engineers or developers. The people who generate POs and sign checks might not even be able to directly evaluate the technical quality of our solutions. It’s an act of faith, unless they’ve been burned before, that good software design and testing will make their projects more successful and their lives easier.

Ironically, less disciplined developers who commonly let bugs out into the world may be more likely to get the technical kudos. After all, they’re performing the software heroics of late night, last-minute debugging and patching. It’s their technical ability that a customer is held hostage to and rescued by. Just like the actions that engender our nice words, these efforts are highly visible to customers. I suspect some developers even get addicted to the opportunity to be a hero and save the day through their technical prowess. This isn’t really in the best interest of customers, but if you’ve headed down the path of undisciplined, unpredictable development, you’re probably thankful for the effort.

Heroics are great when they’re needed, but it sure is better to not need them at all. Guess I should go spread some nice words about all this great code I’m surrounded by.

One of the most important questions at the start of a project is how much it will cost. It is vital to make sure that enough budget is available to allow for the development of a viable product.

The difficulty with setting a budget at the start of a project is that everyone is at the point of maximum ignorance. At the beginning of a project, all of the requirements have not matured. Scope may not be fully defined, the market approach may be a bit hazy, or the technical requirements may still be in flux. It is okay to move forward with a loosely defined project as long as the scope and budget are refined at several steps along the budget roadmap.

How big is the pie? After a project has been loosely defined, the profit generating, or cost savings, potential should be estimated. Refining scope and budget will cost time and money. Knowing the potential reward will ensure that the research, design and planning effort stays within perspective.

Early Estimation We use the early project requirements, historical data from previous projects, and our experienced intuition to initially estimate cost. At this point the estimate will have the broadest range. We might estimate that the project will definitely cost $50,000 but probably not go over $100,000. If the estimate is much higher than expected, we can revisit the requirements to make sure that scope expectations are aligned. We can redefine the scope and estimate again.

Research, Design and Planning If the initially estimated cost range is acceptable, we’ll move forward into a research, design, and planning (RDP) phase. This phase provides further definition of the product’s users and functionality. We will create a story map to define the user activities and tasks and use that map to define a minimum viable product. We then estimate the development effort, in ranges of days, to implement the features that allow users to complete the defined tasks. To aid in our estimation effort, we may create sketches or wireframes that roughly define the features. We’ll also qualify each feature as supporting the context or core of the product and how high or low the frequency of use may be.

More Decisions Our refined estimate coming out of RDP usually falls within the range of our initial estimate. Sometimes the estimated cost increases because we have learned more about the product. A higher estimated cost is okay. Money has been spent to gain knowledge. Risk has been reduced and we’re more certain about the cost of chasing the reward. At this point a decision is made to move forward with development or not.

Predictable Delivery We start development with the estimated budget from RDP as a constraint. We create a backlog of development stories. Stories to be completed in the near future are more defined than stories in the distant future. We track our progress through the backlog of stories on a weekly basis. We give weekly updates of the projected final cost. We define stories further when appropriate and negotiate scope to keep the project on budget. At the end of the project, we deliver a final release within a predictable time and budget.

No wonder we’re all a bit tired at the end of this year. A little digging through our CRM tells me that sales opportunities are up 30% and our success rate is identical compared with 2008. With revenue basically flat and spot-on with what I was expecting, it means we’ve sold and worked on 30% more projects this year than last.

The nice thing about this is all the new customers we’ve met and helped. But I hope everyone has saved some vacation time. I think we could all use a rest.

Last month Shawn Crowley and I attended the Business of Software Conference in San Francisco. This was one of the best software conferences that I have ever attended. It was unique because it brought together a strong collection of software company founders and top management. Most of these companies worked in B2B vertical markets that did not compete with each other. This lack of direct competition helped facilitate great conversations in which conference attendees openly disclosed company success and failure stories.

My favorite part about the conference was a key note talk given by Geoffrey Moore. Moore is widely known for his successful book Crossing the Chasm. During Moore’s talk he discussed a few types of software projects. I believe that the same principles apply to features of software products.

Differentiation – A differentiation project does something different than the competition. If done correctly it gives the organization enormous bargaining power.

Neutralization – A neutralization project focuses on meeting the market norm. It is not about outperforming your competition. The goal of this project is to make your organization competitive by offering a similar feature set.

After describing these project types he went on to discuss how it is very common for both of these types to lead to organizational waste. Moore used a similar image to the one below to describe this concept.

Differentiation Waste – A differentiation project becomes wasteful when it is not taken far enough. Since these types of projects require innovation and lead to high bargaining power they come at a high cost. Moore’s advice for these types of projects is that an organization should be willing to spend twice as much as they anticipated to really make this type of project a success.

Neutralization Waste – A neutralization project becomes wasteful when the project goes too far. Moore discussed that adding additional bells and whistles to a neutralization project will gain applause, but until it reaches a certain level of differentiation the customer will not pay more money for the extra effort.

An example of how a neutralization project can be wasteful could be a simple login feature in a web application. Most modern web applications have the ability to login and reset the password. In order for a product to compete it must invest in login functionality. Once the development for the login is complete it becomes very tempting to improve the feature. Perhaps, adding avatars would be interesting. Before investing the development resources in this additional feature the project team should consider if adding the avatar feature is a differentiation, or if it will take more than just the avatar feature to make the product more valuable to the end customer. If the team is not willing to take the feature far enough to differentiate then maybe it makes more sense to have the team work on something else instead. The area after neutralization but before differentiation is waste.

Understanding the difference between these two project types was very enlightening for me. Knowing what type of project or feature you are currently developing helps answer the question of how much is enough. Challenging our customers on this idea helps us provide maximum business value.

A surprisingly small number of developers ever get to actually meet the end users of their software. Even at Atomic, with small teams and direct customer contact with the team, it’s not so common that we meet, much less observe, the actual people who consume the software we build. Chad Fowler makes the point that closing this loop is a critical part of software craftsmanship.

I had this opportunity last week. Our customer, the International Finance Corporation (part of the World Bank Group), held a partners conference in Cape Town, South Africa. Local partners of the SME Toolkit came from all over the developing world to train on the new features in the Toolkit, share their stories, and make suggestions for future features.

Hearing the stories from the partners of how the Toolkit helps their local SMEs was inspirational—there’s a lot of leverage in this project, and it’s one I’m particularly proud to be part of. (Receiving all the compliments on our team’s work is always fun, too, and a nice payback for the 15+ hour plane flights.) I’m returning to work inspired by the great people I met, excited to help specify new features, and proud of the work we do to support the Toolkit.

Some clients prefer vendors to offer fixed bids for their projects. The perceived benefit of a fixed bid is that it appears to remove uncertainty from the cost, timeline and scope of the project. The contract controls three of the four variables outlined in Kent Beck’s Extreme Programming Explained. Clients are happy to have control over these aspects of the project, unaware that in so doing they may be relinquishing control over the fourth variable: quality.

What does it take to produce a high-quality product? First, we find that the best products are the result of the collaborative efforts of clients and vendors – business and development – because you need the expertise of both parties. Second, a project needs to be able to adapt to the inevitable changes that it will encounter along the way. All features don’t have to be fully defined at the beginning of the project. Both clients and vendors are in a better position to work out the details of a feature or set of features as time moves on.

A fixed-bid contract works against these principles of quality. It does not easily adapt to changes because the contract determines the scope of the project and straying from that contract involves time-consuming renegotiation, which detracts from the working relationship of clients and vendors. Second, the contract does not align the incentives of clients and vendors. The focus is not on producing high-quality software, but on fulfilling the said contractual agreements. The development question is no longer “what will be best” but “what does the contract stipulate.”

The picture described here is one of competing interests on opposite sides of an inflexible document (i.e. wall) between clients and vendors that prevents effective communication. In the long run, software produced on this model is more costly, and we’re not just talking about cost of maintenance. Even adequately functioning products that fit the contractual requirements can have additional opportunity costs: a software product may miss its intended market, or an internal system may fail to address inevitable inefficiencies.

How AO Works

At Atomic Object, we bill for time and materials at regular intervals throughout the lifecycle of the project. But this doesn’t mean we simply dive in headfirst with no concern for budget. We are very budget sensitive, and recognize the long-term cost savings of owning well-built software. Our project estimate, while accurate, does adapt over time to fit the needs of the project. The following three practices work together to create an increasingly accurate budget and satisfying project.

• Prioritizing Features
• Tracking Velocity
• Working in Weekly Iterations

Prioritizing Features. While in the planning phase, we help our clients produce a list of all the features they desire of their product, ranking them in order of importance. The developers then use this list to structure development. (Clients can change the priority of any feature during iteration meetings.) Once established, this list can be used to estimate how long the project will take. Rather than assign an arbitrary amount of time to the feature, we measure the tasks according to their relative complexity. If adding a feature has a complexity level of one point, another that is twice as hard will be allotted two points in the schedule.

Velocity Tracking. Once each feature is estimated using a relative scale, we can make an iteration budget (e.g. ten points this iteration), and then measure our progress. If ten points takes us one week, we now can estimate that a one-hundred point project will take ten weeks. By tracking our velocity, we are able to produce an increasingly accurate estimate of the project’s completion time. Clients are part of this process—they know exactly what our velocity is, how it compares historically, and how it affects the future of their project.

Working in Weekly Iterations. We release tested, functional software to clients in weekly iterations, offering them a good sense of where the team is and assuring them that the released features match their expectations. The weekly iterations provide clients with a platform to change their minds without needing to renegotiate a contract. Rather than dropping off a contract and returning three months later for the finished product, clients can see the progress as it happens, mitigating the risk that the product isn’t what they had in mind. Moreover, these weekly checkpoints assure clients that their developers are using their time as efficiently as possible. Because clients collaborate with the developers on a weekly basis, the progress is completely transparent. Tracking our velocity and breaking up projects into smaller tasks incentivizes developers to work more thoroughly and efficiently, quelling any concerns that billing for time discourages developers to use their time wisely.

The advantage of billing for time and materials over fixed-bids is that it removes the wall that a contract creates, promoting communication and collaboration between clients and developers. Everyone shares the responsibility for the project’s success when communication is open—and that means higher quality software.

One of the first things visitors to the Atomic Object office may notice is a lack of walls. This has come to be known as the "Atomic Brain Trust"--an open environment that encourages ideas to flow as freely as the coffee that sparks them.

David Christiansen was one such visitor, writing of his visit to the AO office over at TechDarkside. "It's hard to think of what I saw there as an office--it had more in common with a grad school lab than an IT department. I thought it was awesome."

The open office environment has benefited Atomic Object and its clients in a variety of ways.

Problem solving. Much like our stand up meetings, the open office--wherein desks are arranged into groups with everyone facing into the center--promotes spontaneous brain storming. Employees working on radically different projects can share their collective wisdom and past experiences, to the benefit of other employees and ultimately AO's clients as well.



Productivity. The open office environment holds employees accountable to each other for their daily productivity. Everyone can see what you're working on, so it makes it much more difficult to slip in a quick game of Bejeweled or a lengthy email to your favorite aunt.



Community. Rather than sequestering individuals behind walls to limit their interaction, employees are encouraged to interact. Employees all sit facing each other in clusters, which encourages dialogue, while at the same time allowing employees to remain at their desks and continue working while doing so. In a traditional office environment, employees must interrupt their work and leave their cubicles for any interaction.

Warmth. When visitors walk into the Atomic Object office, they are often times greeted by a big friendly dog--one of several you might find around the office on any given day. If no dogs are present, visitors will at least be greeted by actual faces, instead of a wall of generically carpeted cubicles. Right away visitors see developers hard at work, actively engaged in client projects.



There it is in a nutshell. The open environment is social, spontaneous and productive. It's not just Atomic Object that is discovering this phenomenon. Agile enthusiast Elisabeth Hendrickson over at Quality Tree Software, Inc. is in the process of creating an open office environment after visiting Atomic Object and several others, where she quickly realized the benefits of our way of thinking. On Hendrickson's blog "Test Obsessed", she cites Atomic Object, among others, as a source of inspiration for her forthcoming open environment office space, hoping others with find similar inspiration and follow suit. We hope you do too.

One of the many perks of being an Atomic Object employee is the community snack table. AO keeps a variety of snacks (as well as coffee, of course) stocked and on-hand at all times. This not only benefits Atomic Object employees, it also benefits AO’s clients for a number of reasons.

The table provides employees with a snack break and a chance to clear the mind, but it also is a community area where employees can gather and converse. While typical talk of the weekend or politics can be heard at times, employees have just as often found themselves engaged in spontaneous problem-solving sessions.

Employees engaged with other projects can provide valuable insight and advice based on past experience that can ultimately lead to a solution for the issue at hand. Conversation around the snack table provides a chance to gather input and advice from other employees who may have had prior experience with similar projects or situations. This translates to more value for the client and increased productivity and efficiency for AO.

The snack table also builds community among AO employees. The kitchen surrounding the table is set up much like a typical home kitchen, creating an inviting and warm atmosphere for employees and visitors. Employees bond over conversation and snacks, which leads to a tighter relationships and a stronger workplace camaraderie. The table benefits Atomic Object, its employees and their clients in substantial ways, making the snack table an integral part of Atomic Object’s vibrant culture.

Atomic Object’s intern program is unlike most within the tech industry. Generally, both clients and the company hosting the intern do not utilize the intern’s full talent. However, Atomic Object (Atomic) has worked hard to develop an intern program that provides more value to the interns and clients than a typical internship program.

The Atomic internship program’s model is structured more like an apprenticeship. Interns work under the guidance and care of a “wizard,” one of Atomic’s senior software developers. The wizard finds projects to assign the intern, which can be either projects the wizard is working on or projects other developers are working on. This provides the intern with more experience and variety than your typical internship program as he/she works on whichever projects the developer may be currently involved with. Atomic interns have worked on everything from automated system tests to iPhone games, an assortment which gives the intern an opportunity to contribute in meaningful, not menial ways. Along with the challenge of working on a wide range of projects, interns are often invited to follow their wizard to client meetings—essentially shadowing their mentor.

This model gives the interns a true taste of real world work experience, providing them with an opportunity to experience all the intellectual and creative facets of the development process, instead of just the routine “work” portion of the business. This prepares interns to confidently interact with clients and instills the mores that go with business interactions.

Atomic also benefits from the internship program in a variety of ways. In addition to having an extra set of hands to assist the senior developer, the internship program also gives Atomic a link to a talent pool, by establishing connections with college students and schools. Atomic’s positive reputation among employees and interns has led to a number of new staff members, which is beneficial to both the interns and Atomic Object.