Bootstrapping Lessons from Brooklyn

Before attending an October NSF I-Corps entrepreneurial workshop in Brooklyn, I finished the required reading:

In this post I’ll share a few things I took away from the workshop as an observer, and what I learned from the books.

As a launching point, a startup was defined as:

“A temporary organisation designed to search for a repeatable and scalable business model”

I was struck by the phrase temporary organization, but I suppose the idea is that once you become a revenue generating venture, you’re no longer in the startup phase, rather you toggle the switches into an operational business where success is measured by how well you execute.

National Science Foundation I-Corps

The I in I-Corps stands for Innovation.

There is a shift afoot in the NSF away from funding stand-alone scientific research toward “broadening the impact” of basic research.

One way to broaden the impact of scientific research is to fast-track the science into products and businesses. Ergo we have I-Corps. From the I-Corps website:

The NSF Innovation Corps (I-Corps) is a set of activities and programs that prepare scientists and engineers to extend their focus beyond the laboratory and broadens the impact of select, NSF-funded, basic-research projects.

I-Corps, and the Brooklyn workshop I attended, are rooted in the soil of the Lean Startup movement.

Context: Customer Discovery & Lean Startup

Steve Blank is the de facto graybeard of Lean Startup. Lean Startup was proposed in 2011 by Blank’s former student and entrepreneurial mentee, Eric Ries. While Ries popularized the movement beyond the software community, Blank contributed the essential first step:

Customer Discovery

With the exception of Customer Discovery, Minimum Viable Product, and the novel idea of iteratively testing a hypothesis about perceived customer value, much of Lean Startup is derived from the Agile / XP movement which has been used for over a decade in the software community.

Historical Context: Waterfall → Agile → Lean Startup

Software developers progressed from Waterfall to Agile and, more recently, into Lean Startup.

Waterfall is a sequential design process that was the canonical approach to software development for over 40 years. The stages of a waterfall are an unfortunate but apt metaphor for process rigidity (i.e., a new stage may not start until its immediate predecessor is completed).

Out of the process rigidity of Waterfall came the Agile Manifesto (Snowbird, Utah 2001).

Software developers have lived through the gains and pains of Agile implementations for over a decade (see Bottom-Up Change: The Agile Manifesto at 10). The lighter weight Agile taught us to embrace change, to adapt quickly to an evolving product vision, and to produce working software for the customer. Agile also taught us to iterate over bite-sized chucks of work and to reflect upon what we’d accomplished. We learned the value of incremental development. In short, we learned to

Plan, produce, and reflect.

Much of the Agile mindset is well-suited for starting a business.

The Business Model Canvas

Much of the workshop was centered about teaching graduate science and engineering students how to effectively use a Business Model Canvas. A Business Model Canvas is a template for developing new business models. The primary directive of a startup is to search for a viable business model.

“Startups search. Companies execute.”
Frank Rimalovski, NYU Entrepreneurial Institute.

In the journey to find out if your model has legs, the Business Model Canvas is used to organize your hunches about what will sell and who your customers will be.

Business Model Canvas

Over the course of the 3-day workshop, the Business Model Canvas became both narrative and scorecard. It was used for measuring progress in discovering the essential aspects of the model. Participants were charged with finding and interviewing potential customers so they could test their hunches. They were admonished to

“Get out of the building!”

And participants were urged to,

“Start thinking about the ecosystem…how the money flows.”

Participants were instructed to frame, trim, and hone their product concepts (and the written descriptions of their products) so that the gist of the product was easily and instantly communicated to a less sophisticated audience.

“Frame the description of your product for your mother.”
― Lyndsey Marshall Gray, NYU Entrepreneurial Institute

I observed graduate students, called Entrepreneurial Leads or ELs, struggling to coherently and concisely express concepts like Value Proposition or Customer Segments to a panel of business experts and instructors who grilled them. Several times a panel member blurted out, “Who cares?”

“This is delivery. We learn by doing.”
Jerry Engel, Berkeley-Haas School of Business

A Value Proposition is a promise of value. The Business Model Canvas has a box for Value Proposition, labeled VP. Participants were encouraged to write their value propositions as testable assertions.

A value proposition applies directly to one customer segment or another. The Business Model Canvas also has a box for Customer Segment, labeled CS. The workshop instructors stressed the importance of being able to map a value proposition to a specific customer.

When participants struggled with identifying their customer segments, they were encouraged to be concise and to think about the pointy tip of the arrow.

“Who are the people who will open their wallets first?”
―Lyndsey Marshall Gray, NYU Entrepreneurial Institute

Parting Wisdom

Many scientists, and would-be entrepreneurs, are hyper-focused on technologies or alleged features rather than benefits because that’s what they find most compelling, but the process of determining value, and who might buy a product, has more to do with the Pains and Gains experienced by a potential customer.

Like the Business Model Canvas, The Startup Owner’s Manual and Business Model Generation are dry and formulaic. But who am I to argue with success?

By all accounts, searching for a business model is a step-by-step journey of conquering one of the aspects of business development that might be most uncomfortable to those of us who are socially-inept or analytically minded:

Engaging people to validate your hunches about your product.

Software startups must be able to distinguish between users and paying customers because they’re not always one in the same.

Stripped bare, Steve Blank’s insight is that customer discovery is essential. One personal epiphany worth repeating over and over again for would-be software entrepreneurs:

Don’t bother coding anything until you discover & understand who’s going to buy it.

If you’re attempting to bootstrap a software product or company, The Startup Owner’s Manual is essential reading because I’m betting the formulaic practices will save you months, if not years, of misguided effort.



A Personal Approach to Agility

I will always appreciate the spirit of the Agile Manifesto. I revisit the 12 principles behind the Agile Manifesto on occasion, particularly after experiencing recipe-driven nincompoops who use the principles as blunt instruments to flog me and fellow developers.

I am also increasingly surprised by how disconnected Conference Circuit Agilists have become from producing software. Pithy anecdotes don’t often jibe with in-the-trenches experience.

A Personal Approach

As an itinerant software maker, I enjoy the inter-personal stuff of software teams. I also enjoy the process stuff, but mainly in environments where the process remains in a state of continuous improvement.

Improvement has little to do with output and a much more to do with making software that people like to use. My approach is born from trial and error. I hope my approach remains in continuous improvement. I hope it remains simple.

I try to understand the context of the product challenges. I like to think I have become less dogmatic and grown more pragmatic. I try to be sensitive to the social dynamics of the organization that has invited me in. Some truisms are:

  • Recognize every product is different – There’s no one-size-fits-all in producing software.
  • Build capital by getting stuff done – There are few bigger chits than working software.

Assuming you have banked some capital with your benefactors:

  • Protest & respectfully resist process ceremony – Process ceremony wastes everyone’s time.
  • Practice the things that make sense – If it has to make sense, it’s always a fluid practice.

My approach is a state of mind, rather than a recipe.

“In the beginner’s mind there are many possibilities, but in the expert’s mind there are few”
– Shunryu Suzuki

Commoditized Agile

Commoditized Agile is a market-driven, largely failed, money-making machine. It is a prescriptive approach that metastasized from what began as the agile movement. Behind the guise of agile, ne’er-do-wells seized the chance to make a living lecturing people about The Best way to make software.

It’s the product of opportunists and lazy organizations.

Lazy organizations, seeking the easy pills, threw money at a state of mind believing it would somehow morph into a prescriptive remedy for unhappy employees and crappy software.

  • Opportunists packaged prescriptive service offerings and over-featured software products around a set of principles that were probably never intended to be prescriptive.
  • Organizations seized on something new, so they had to throw money at the something new as proof they were doing it.

Commoditized Agile as troweled out by Conference Circuit Agilists, several of whom couldn’t possibly have time to produce software, is mostly snake oil. Commoditized Agile, as represented by a host of crappy software products targeted at organizations who are “doing agile”, is poorly conceived.

The lessons are simple. Find a personal approach that’s an aggregation of trial and error. Co-opt the best ideas of others. Apply those ideas where they make sense. Deep-six any process with the scent of gratuitous ceremony. Remain skeptical of shiny new things. Get rid of tools that hinder your progress. Beware of charlatans selling snake oil.

“You never change things by fighting the existing reality. To change something, build a new model that makes the existing model obsolete.”
– R. Buckminster Fuller


I’ve been told in a tweet that this post is a bit cynical. So readers should know that I almost always enjoy the smart people I work with. In fact,

The joy I get from the people I work with invariably outweighs the profound organizational stupidity I encounter.

Bottom-Up Change: The Agile Manifesto at 10

The most enduring and most people-positive change starts at the bottom: Bottom-Up Change. It starts with the few, then spreads to the many.

People-positive change is change that benefits the common good. The principles of the Agile Manifesto have improved my professional life as a software developer.

Individuals and interactions over processes and tools

Agile Manifesto Turns 10

17 software developers convened in Snowbird Utah in 2001 to discuss lightweight development methods. Out of the Snowbird meeting came the Agile Software Manifesto.

The manifesto is a rallying cry: it says what we stand for and also what we are opposed to.
~Martin Fowler

Full Disclosure – Considering the arc of the Agile phenomenon, I am a newbie. The only reason I might have been at Snowbird in February 2001 was to re-live a romantic notion of myself as a ski bum. The truth is, I knew nothing about Agile methods until I joined a David Hussman coached team in 2006.

The advent of the 10th anniversary of the inception of the Agile Manifesto next February has me probing the nature of change and revisiting the stated principles in the manifesto.

The Nature of Change

On change, Nathaniel Branden said

The first step toward change is awareness. The second step is acceptance.

Did Branden miss The Movement? Did he miss some steps before acceptance?

  1. Organization – Convening & engaging like-minds to rally around change;
  2. Inspiration – Inspiring first followers to virally grow change.

The most enduring change germinates at the bottom. The old saw

You can lead a horse to water, but you can’t make it drink

means people, like horses, will do what they have a mind to do. Directives, top-down plans, and top-down change rarely endure.

Shoehorning Agile

Agile doesn’t scale particularly well. People-centric principles in the Agile Manifesto fall by the wayside in the ponderous, profit-take-all organization. Agile principles like customer collaboration or individuals and interactions are summarily ignored in ponderous organizations because there’s ostensibly cheaper developers to be had in remote locations. That your organization dictates the use of cheaper developers, is a smell.

There are exceptions. To be sure the challenge of Scaling Agile has stoked an industry for consultants, coaches, and charlatans. But it’s a fools game.

Shoe-horning Agile into the ponderous, profit-take-all organization often – some would say inevitably – leads to a twisted Agile Lite bastardization where people must make do with sub-optimal conditions and where

process & ceremony trump humanity and practicality

Sub-optimal constraints are today’s reality. But at what point does leaning on people to absorb and adapt to sub-optimal constraints lead to diminished returns?

Dictatorships and oligarchies have been proven untenable time and time again. It seems Agile principles are at odds with current corporate charters.

Thinking Forward

The ponderous organization’s resistance to transformative change and transformative learning appears to be peaking. The antithesis of the ponderous organization, the Lean Startup, is gaining momentum. Lean startup principles are rooted in transformative learning.

Resisting transformative movements is unstable.

It is not necessary to change. Survival is not mandatory.
~W. Edwards Deming

Lasting change and people-positive movements start with passionate people, then infiltrate into the cadres of controllers that infest ponderous organizations. Movement is sparked by passionate people who organize and inspire; not by cadres of controllers.

Agile at 10 years is a double-edged phenomena:  People continuing to do transformative work, and a growing numbers of ponderous organizations paying lip service to change.

Lazy Man’s Agile

Many organizations mistakenly think that capital expenditures on software tracking & planning tools is tantamount to being agile. Plan, spend, and execute. It seems easy.
Tara Whitaker uses the Conscious Competence Ladder in her post Doing Agile is a Sign of Incompetence to expand on the distinctions between doing and being agile.
A common scenario that exemplifies doing agile is to ignore the first value in the Manifesto for Agile Software Development
Individuals and interactions over processes and tools
Capital expenditures on software tracking & planning tools do not guarantee your team will be happier or more productive.
Planning & tracking software CAPEX typically comes from the IT department with no coordination with the “beneficiaries” from the business side.
Short shrift is given to coaching. And there’s no budget left for courses or conferences.
I have dubbed this lazy man’s agile.
Lazy man’s agile is often less productive, and usually no more inspiring, than pile-driven waterfall.

Our lesson is simple.
People are first. All the other trappings are…well…trappings.
Don’t let the easy path of tools and templates drain the humanity from a great idea. People make software. People use software.
Hire coaches. Send your team to conferences. Define it for yourself. Craft a team understanding.
Pragmatic Suggestion
Start with the relatively low-cost, low-expectation of incremental improvement.
This is doing and being at the same time.

Festering Manifestos – What is Software Quality?

Referring to The Manifesto for Software Craftsmanship, product development executive Charl Dreyer asks
Is another manifesto necessary?
The Manifesto for Software Craftsmanship offers up quality addenda to the Manifesto for Agile Software Development. Charl Dreyer wonders if this is necessary (see Dreyer’s Raising The Bar).
Robert Vitello, CIO at New York State Labor Department, says

Although well meant, the Manifesto for Software Craftsmanship seems too unspecific to have real value on the ground. When such pronouncements are too lofty or too general, they are subject to the kind of variable interpretation that cause the authors to rail against the original Manifesto.

I agree with Robert’s critique. There is not much mental traction served up by platitudes like steadily added value or productive partnerships.
Nonetheless I signed The Manifesto for Software Craftsmanship because I support the intent.
If quality is sufficiently defined, who would be anti-quality?
It is perhaps important to remember that

the quality of something does not necessarily determine its value

Something might be good because it is useful, because it is beautiful, or because it exists. I like the aesthetic appeal of sparse but powerful code — one or two lines of code that does a lot – but I can’t assert that it always provides economic value. Sometimes we favor elegance over expedience; not always providing demonstrable economic value. We are employed in the software business to increase economic value.
The craftsmanship addenda to the agile manifesto are born from noble purpose. Open-ended, nearly inscrutable bromides like “well-crafted software” are potentially helpful insomuch as they can promote collective examination and collective improvement. Yes, examination and improvement are good! Lofty, intellectually fuzzy declarations are potentially helpful insomuch as they promote thought about-, and discussion of-, elusive terms like “value” and “quality”.
I like the concept of a team-level “craftsmanship contract” during chartering. I took a swing at this topic a while back in my post Team Manifesto – Craftsmanship, Behavior & Minutiae. Creating a craftsmanship contract starts with the open-ended question
What does software quality mean to you?
The goal is to end up with testable assertions. That is, to end up with prominently displayed bullet points that are meaningful to the team and testable in retrospectives.
What constitutes software quality?
Is software quality a personal matter or is it a collective concern of the team? I would like to hear your thoughts.

Self-Organization: Flocks, Schools & Colonies

One of the Twelve Principles of Agile Software expressed in the Agile Manifesto, calls for self-organizing teams:

The best architectures, requirements, and designs emerge from self-organizing teams.

Self-organization was recognized in 1955 by Farley and Clark as:

a system that changes its basic structure as a function of its experience and environment

Self-organizing systems are widely observed and recognized in physics, chemistry, mathematics, cybernetics, economics, and biology. The prospect of collective intelligence certainly is intriguing.

What are the characteristics of flock of startlings (above right), schools of fish (left) or a colony bees (below right), that might be relevant to how we form, feed and sustain self-organizing teams?

Birds and Fish
Schools of fish move like a single organism. Schooling reduces the risk of being eaten by a predator because the odds of individual detection are less. Fish, unlike migrating geese who form an aerodynamic vee, do not flock in a regular geometric shape.

Flocks of birds group into a geometric shape for the aerodynamic advantage, but otherwise birds group together obeying similar heuristics as fish. Both organisms perform complex tasks with simple individual behavior. Both groups react instantaneously to external events by spawning different invididual tasks to accomodate external stimuli. Further, small differences in individual behavior might influence the collective behavior of community.

Simulations to mimic flocks of birds use three simple rules:

  1. Collision avoidance – don’t crash into a flock-mate;
  2. Velocity matching – move at the same speed as flock-mates;
  3. Centering – strive to stay close to flock-mates.

These simple rules, inate behavior in birds and fish, might spawn a fruitful discussion during your next Retrospective.

Bees, Ants, and Wasps
Colonies of bees and ants perform community tasks by a distributed function that doesn’t seem to require a central organizer. The two observed characteristics of interaction are:

  • Hierarchical – one insect asssumes a dominant role and the other submissive
  • Thropic – a community “decision” is made (e.g., ants produce more foragers when food is scarce)

Agile teams need to make community decisions. To be a good Agile teammate, it is important to develop an instinct for the signals of when to exercise dominance and and when to be submissive. You must be capable of both behaviors as events dictate.

A defining property of living systems is that they self-assemble against nature’s tendency toward disorder, or entropy ~ Erwin Schrödinger

Many organisms have evolved sophisticated community behaviors. It is instructive to examine other self-organizing communities as we form, feed and sustain our Agile teams.

Want to Read More?