Discloser: I provide the PSD and PSF courses that Scrum.org organizes. We do not certify. We provide assessments that gauge knowledge of the courses, but are quite clear that practice and experience are needed. Scrum and Agile are crazy easy to learn, but crazy hard to master.

Scrum has earned the reputation that Scrum Alliance created. A LOT of us know this and want to fix it. Scrum isn’t the problem and Scrum isn’t the solution.

“It’s not true to the fundamentally critical cycle of experimentation and evaluation that is at the heart of agile.”
This is the heart and soul of Scrum. Beyond that, there are people who create the product (dev team) and a person they can go to for fast, authoritative decisions (PO). Scrum even says the team can fire their Scrum Master. This is, because the role serves the team and PO. Doesn’t get much more simple than that. Daily Scrum = Make a plan for the day. The 3 questions??? See my tweet https://twitter.com/#!/cromwellryan/status/165109125481639936

The abused description of Scrum Master you describe doesn’t come from Scrum itself. We like to say that a Scrum Master is always trying to put themselves out of business by helping the team learn to solve problems. It’s hard to see the many people problems when you’re on the team. SM is meant to be an outside, objective observer who provides space and opportunity for growth. See Coaching Agile Teams… amazing book.

“Well guess what? It’s not agile’s fault. If you just “do” scrum without understanding or appreciating the values behind it, you didn’t “do” agile. You just did a totally empty version of scrum.”
– Bingo. People are always the key. No matter what, the same outcome will surface with the use of any framework while ignoring the foundational elements.

In the end, I really would encourage you to bring your thoughts and ideas to the Scrum community. Suggest a change (http://www.scrum.org/scrum-guide-proposal/) or extend Scrum (http://www.scrum.org/scrum-extensions/). I think you’ll enjoy seeing what comes out of those extensions that are already being proposed. Especially Scrum Basic.

That said, I’m not discounting anyone’s success. I’m not even saying that scrum will cause you to fail. I’m simply saying that the Scrum establishment has screwed up, and it hurts all of us.

http://www.tempobook.com/2012/01/19/steer-ready-fire/#comment-3007

Bootstrapping really does force you to go slower, because the amount you can invest in an opportunity is balanced against the immediate return of your cumulative investments. This clearly limits how much you can do. If you are the founder and the developer, things improve a bit because you can pretty much ignore the cost of your time. For example, my best estimate is that I have invested about $400,000 of my life into TroopTrack at this point, but because I love doing it I don’t have to include that investment when I evaluate its profitability, at least not yet.

For the last year I have been trying to expand my customer base from early adopters to mainstream users. The early adopters helped me figure out what functionality I need, and now I am deep in the throes of trying to figure out how to make that functionality easy to use and appealing to the less tech savvy. It entails a massive redesign of the site that is a huge effort. Would you consider that a pivot, or just a long series of the small changes you mention above?

Also, isn’t the concept of validated learning useful even in a bootstrap?

And, why is lean only applicable to companies that want external investors? Aren’t some of the controls useful to the founder of a bootstrap too? Or does the fact that a bootstrap has an infinitely long runway mean those controls don’t matter as much?

The Lean Startup is built for raw thrust and visibility of certain management elements to investors with certain growth and coarse control expectations. The pivot is an example of the sort of concept that results.

What you describe later (waiting for your opening, small pivots, creating an opening) is not pivoting at all, but something much more subtle and sophisticated: they are cousins of maneuver warfare concepts from Boydian OODA loop models.

When you reduce that to a somewhat simplistic idea of a pivot, as an element of a build-test-fail-pivot-build loop, you lose the sophistication but give the investors crude controls to play with.

The key tradeoff in lean vs. bootstrap is basically higher max thrust vs. better maneuverability. The market dictates which end of the tradeoff is smarter for a given business opportunity. OODA types talk of “inside the tempo” vs. “faster op-tempo.” Bootstrapping is about getting inside the tempo of a market. Lean is about a faster raw op-tempo. Just because you are iterating faster does NOT mean you are generating market intelligence faster. That’s a key fallacy Lean Startup models encourage. Sometimes you have to go slower to generate intelligence faster. “Inside the tempo” is about generating both intelligence and a position to exploit it, faster. After all lions stalk and crouch and wait 10x more than they race, chase and pounce.

This means blending the two is probably a bad idea. You’re more likely to get the worst of both worlds than the best. It shows in your post. You’re trying to express a more sophisticated approach to agility within a less sophisticated model of agility., without gaining raw thrust to justify it.

Bottomline: if you don’t have or want external investors, Lean is probably costing you more than it is delivering.