Kevin P. Taylor

Conversations over RFPs

I had a conversation recently with a friend who also runs a software development company. During the conversation, the topic strayed (as it often does), to how we each find new clients. I was shocked by his response. His relatively successful company finds many of its new clients by responding to RFPs.

For those of you who haven't had to deal with them, RFP stands for Request for Proposal. Companies write RFPs that explain a problem that needs to be solved and then the company invites one or many vendors to respond with proposals describing how the vendor would solve the problem and how much it would cost.

It sounds wonderful for a client company. The company has an opportunity to compare multiple proposals against each other and choose the most appropriate one. And, in fact, RFPs are used successfully in many business situations, such as building out a new data center or replacing a roof.

But, when a company is looking to purchase custom, creative services such as software development, RFPs become an obstacle. We all know that one of the primary determinants of a successful software project is the cooperation between the different members of the team. The product owner, business stakeholder, developers, and designers need to be pulling toward the same goal. There must be trust and collaboration.

How are potential trust and collaboration measured via an RFP process? Well, they aren't, of course. So, a critical aspect of the client-vendor relationship is left eerily unaddressed during the RFP process. The crucial question of, Can we successfully work with these people?, is left unasked and unanswered.

So, instead of responding to RFPs outright, we always attempt to engage the company in a conversation. We do this because, quite frankly, we don't want to take on doomed projects. Only through the series of conversations and brainstorming/planning sessions that happen during the sales process can we get a read on whether we think we can trust and collaborate with the potential client. And, I want them to take that same read on us.

Ultimately, if the company is unwilling to discuss their problem with us outside of the RFP process and iterate with us over possible solutions, we disqualify them from our sales pipeline and move on to prospects who are looking for a relationship based on trust and collaboration instead of a relationship based on commoditization.

Software Craftsmanship Spikes

Over the past year, we've had many people drop by the Obtiva software studio for short volunteer stints of codesmithing and geekfesting with us. The visits lasted for a few hours or a few days.

Some of the notable visitors (in no meaningful order):  J.B. Rainsberger, Amanda Laucher, Uncle Bob Martin, Corey Haines, Paul Pagel, Jim Suchy, Obie Fernandez, Jeff Patton, and Brian Marick. Thank you, all!

But, we also get a second type of visitor. These are folks who are not necessarily well known. They are apprentices and journeymen who are eager to come pair with passionate fellow craftsmen and share their knowledge with us. And hopefully after a few hours or days, they leave with new tools, techniques, and experiences to power their careers forward.

We've taken to calling this second type of visit a Software Craftsmanship Spike. Just as we do code spikes to gather more information before proceeding with a course of action, visiting craftsmen come here to gather more information about themselves and their careers. Information about technologies, about agile practices, about apprenticeship, about what it is like to work in a craftsmanship environment, or about what they want to do next in their career. 

For example, pair programming might sound cool but if you haven't done it full time for days or weeks, how do you really know you want to take that new gig where you'll be pairing full time?

Or, maybe you've been doing TDD for a year or two. But, you have lingering doubts about whether you are really enjoying the full benefits from it and you want to see how it is done by other practitioners.

In fact, we just had a Software Craftsmanship Spike take place last week.

Interested in participating in a Spike? Contact me. Or, leave a comment below and share your ideas on how this concept can be evolved to become more useful to the participants and more widespread in the craftsmanship community.

SICP Study Groups

One of my favorite outcomes from this summer's Software Craftsmanship North America conference, which Obtiva co-organized, is the SICP study groups. SICP refers to the MIT computer science textbook, Structure and Interpretation of Computer Programs, which is one of the most lucid, and challenging, foundational texts on the subject of computer programming languages.

The reason I am so inspired by the SICP study group phenomenon is that it highlights what I love most about programmers, and more specifically, software craftsmen. Even before we used that label, passionate hackers have been forming user groups, book clubs, IRC channels, and mailing lists, to gather, discuss, and challenge each other's ideas. And, through that, refine their own.

SICP itself is a walk through the esoteric Lisp dialect called Scheme. While on that walk, readers learn about abstractions, objects, closures, recursion, meta-programming, logic programming, and interpreters and compilers.

In fact, there are no mentions of any of the exciting new technologies, frameworks, or languages that will help land a gig. Nothing learned in the book will immediately increase the value of a resume or cause said resume to trigger a recruiter's keyword search on Dice.

So, why are dozens of experienced programmers, many of them the alpha-geeks on their teams, spending their time working through this difficult textbook together? They want to understand. The fundamentals. The whys. The history. The art. The craft. They want to understand the field.

The best professional basketball players on a team are also the last to leave the court after practice has ended. They continue to practice their free throw, their lay up, and their jump shot, long after teammates have showered and left the building.

We are practicing our jump shots.

Hackerpreneur's Schedule

The maker's schedule is for those who create. Whether it is programs, prose, or polynomials, makers need uninterrupted time to imagine, build, and deliver.

The manager's schedule, on the other hand, is for those who lead, facilitate, and measure. Their most valuable tool is the meeting. Whether via status meetings, sales meetings, planning meetings, or board meetings, managers must hold meetings to be effective. In his essay, Maker's Schedule, Manager's Schedule, Paul Graham describes these two conflicting schedule paradigms.

Graham points out that meetings are rarely for the maker's benefit. Meetings are organized by managers for the benefit of managers. According to Graham, they are often outright disruptive to makers. A seemingly harmless half-hour meeting scheduled in the middle of the afternoon can derail a maker for hours.

In his essay, Graham describes himself as being on the maker's schedule. But based on his description, it is more likely he is on the hackerpreneur's schedule. Hackerpreneurs, like Graham, intersperse making with managing, managing with making. The hackerpreneur has a company to build and software to build. The two schedules compete for the hackerpreneur's time.

The hackerpreneur's schedule is for the person who refactors code in the morning and grabs coffee with clients in the afternoon; who takes pleasure in designing class hierarchies and organizational hierarchies; who calls Object.new one moment and calls prospects the next.

Understanding and managing these competing scheduling needs has been a challenge for me, also, since founding Obtiva in 2005. During our first eighteen months, I coded on projects 40-45 hours a week. I was on the maker's schedule. Then, we began to bring in new and more challenging clients‚ and the people and complexity required to service them. My manager's responsibilities began to outweigh my maker's.

For the next two years, I did little coding. The only pitiable device I thought up was to black out a few days or weeks a year to devote uninterrupted time to coding. But, as you can imagine that was a bit disruptive to Obtiva. The business demanded that someone manage it.

Graham doesn't offer suggestions on how to manage the hackerpreneur's schedule, saying only, "Those of us on the maker's schedule are willing to compromise." (Remember, he is not yet aware that he is on the hackerpreneur's schedule.)

This year, the solution to this common scheduling dilemma revealed itself to me very simply. This year I took on a new project, Eventwax.com, that has yanked me back into the world of making. EventWax is an online event registration application and also a bootstrapped start-up.

Our coding practices at Obtiva (and Eventwax) include pair-programming. In order to ensure I have time available to code with my developer pairs, who tend not to be available at midnight, I schedule blocks of coding time throughout the week and label them "EventWax Pairing" in Google calendar. These are best scheduled in half-day increments. Some days consist of two back-to-back half-day coding blocks, but most often I can only pull myself away from my manager's duties for a half-day of coding at a time. But, just as I don't let myself get pulled out of a scheduled client meeting, I don't let myself get pulled out of scheduled coding time.

Though the amount of time the hackerpreneur devotes to making vs. managing will evolve—or swing wildly—over time, the solution is clear. Schedule time for making. Block it out in your calendar. Set its priority as high as any of your other commitments.

Software Craftsmanship North America, August 26th, 2009

Software Craftsmanship North America is scheduled for August 26th, 2009. Conveniently, it will be held the same week as Agile 2009, also in Chicago. Even more conveniently, it will be held across the street from Agile 2009!

So, what is Software Craftsmanship and why am I linking a Software Craftsmanship conference to an Agile conference? I encourage you to visit the Software Craftsmanship Manifesto and the active Software Craftsmanship Google Group, to form your own opinions.

For me, Software Craftsmanship primarily represents two things: A school of thought within Agile that advocates the quality work and the collaboration that we see in developer-centric Extreme Programming teams; and, a focus on a holistic view of programming as a profession, with a beginning and a middle and an end, that can span a lifetime.

I am proud that my company, Obtiva, in collaboration with 8th Light, is organizing Software Craftsmanship North America. I am also excited to participate in the panel discussion, "The Business of Craftsmanship" with my friends, Carl Erikson and Micah Martin.

Edward Lowe Foundation

I visited the Edward Lowe Foundation this past winter with a group of other entrepreneurs for a Leader Retreat. Though I didn't want to take three days off to attend, I was committed. You see, the entrepreneurs group I belong to requires all members attend the mandatory annual retreats.

As we all know, occasionally getting our heads out of the oven and contemplating where we are and where we want to go is a valuable exercise. Self-retrospectives.

The biggest take away for me this winter? The realization that Obtiva is no longer a startup. We've transitioned to a second-stage company.

In the coming weeks, I'll share some of what I discovered about myself, my team, and my company. In the meantime, I highly recommend looking into the Edward Lowe Foundation's leadership and entrepreneurial programs.

All There is in Life is How You Dance with It

The snow is falling again in the street outside my office window. The flurry of snowflakes framed by the window sill makes for satisfying artwork when glancing away from my computer screen.
 
We've had multiple clients working in the Obtiva offices this week, with plenty of iteration planning and client demos taking place. What a feeling to start off the new year with the buzz of activity and a bright outlook for the coming year.

What bright outlook could there be for 2009? The pain of recession is all around us and it is easy to get discouraged. But, a friend recently reminded me, "All there is in life is how you dance with it." Whatever life throws at you, you only have the power to decide how you react to it. None of us have control over the economy. We only have control over our actions in response to life's dance. How will we provide better service to our loyal clients? How will we create new and exciting revenue streams? Which clients do we focus on and which ones are a drain on our pursuit of excellence and craftsmanship?

I've decided my dance for 2009. Have you decided yours?

The Coin Flip Game

We enjoyed an opportunity to hang out with Jeff Patton in the Obtiva office for a few days recently. He was pairing with Dave on Mad Mimi most of that time. But, we all know that all work and no play makes <fill in name> a dull boy, so being geeks, we took a break to play a new game that Jeff suggested.

The Coin Flip Game (my name) demonstrates the efficiencies gained in a Lean/Agile production environment when compared to waterfall environments. The concepts this game demonstrates are explained by the Theory of Constraints and optimal work queue sizing. The idea is to deliver several coin flipping "projects." The first project is waterfall-style with Requirements, Design, Implementation, Verification, and  Maintenance phases. Running the waterfall project will give us a baseline process cycle time, or the time it takes to send a given batch of work through the process from start to finish.

To run the waterfall project, start by creating stations at a table for each of the 5 waterfall phases. Have one person man each station. Line up 10 coins at the Requirements station, all facing heads up. Start a timer. Each station must flip all 10 coins. Once all the coins are flipped, the coins are pushed to the next station. Each station flips and pushes. Once the last station has received and flipped all the coins, the timer stops. Record the time taken as the process cycle time.

For the Agile project, set up the coins and stations exactly as above. This time, though, each person flips and pushes the coins in units of 5 instead of 10. Again, time the result.

Run another Agile project, but with 2 coins being flipped and pushed at a time, and, finally, with only 1 coin at a time.

The theory is that reducing the size and increasing the frequency of the work unit batches being pushed through the stations should increase the overall efficiency of the entire process. Playing the game demonstrates that process cycle time is directly related to batch size but inversely related to batch frequency. If each station receives smaller and more predictable work batches into their queue, it should be easier to manage, and there should be less time spent on low value activities while waiting for another large batch of work to hit the queue.

We took 26.2 seconds to deliver our coins via waterfall. The last Agile project we delivered had 1 coin iterations and was delivered in only 13.1 seconds.

Evolving the Simplest Tools that Will Work

Our company, Obtiva, is an Agile software development company. But, Agile principles permeate all aspects of Obtiva and go well beyond our software projects. We are an Agile Business. As such, one of the core Agile values that we strive for in our business operations is simplicity.

Simplicity manifests itself in many forms during our daily routines while running business operations. The use of lightweight tools is one obvious example. For instance, we leverage Google Apps extensively for email, collaborative documents, and a shared calendar. In most cases, a new business tool begins life as a Google spreadsheet.

Over time (days or months) those spreadsheets and shared documents become less and less effective. The spreadsheet may have only been conceived of as a business logic prototype. Or, a particularly useful spreadsheet may offer significant business value, and the promise of much greater value, if it only had x (feel free to name x).

At this point, we have a choice: invest time and money in an off-the-shelf tool that we can customize to some extent or build our own one-size-fits-one tool. Using Ruby on Rails and other lightweight technologies, we are surprisingly often able to spend only hours to convert a spreadsheet into a Web-based business application.

Even better, our one-size-fits-one applications start life with only the smallest kernel of high priority features, maximizing ROI. Over time, we can continue to add features, of course, as our business needs evolve. We are not locked into any particular vendor's feature set (not enough, too many, or the wrong mix) nor are we at their mercy for bug fixes or upgrades.

First, view you initial application needs through a minimalist's eyes (What is the simplest thing that will work?). Second, leverage the flexibility and productivity of tools like Google Apps, Ruby and Ruby on Rails to deliver just the right level of functionality vs cost.