A LeanPub book for Scrum Masters?

I've had a side-project that started because I've been working with dual-role (and one triple-role) Scrum Masters lately.

I appreciate how hard it is for them to be good at several things simultaneously.

Once I started collecting techniques for them, I figured I should publish it somehow.

I was thinking of a blog, but Joshua Kerievsky (our leader at IndustrialLogic) had mentioned possibly using something like LeanPub.

I really need to learn to release a product early and use feedback to guide it to be something that really addresses a market need.

I've invested some odd hours here and there on this, and have gotten some friends to look it over. Sadly, most of them who are dual-role SMs haven't had time.

Still, here is a chance for me to learn in a lean startup kind of way, releasing early and often, and let the market help me develop the product further.

I'm interested in hearing what you think of the cover, and the idea in general.

I've not settled on price or even included inside illustrations yet. If you want to pop over to the public page at leanpub, you can suggest a price.  I might make an early release without illustrations if enough people think that's a good idea.

Of course, I would release it at a lower price initially since it's not all there, or at least give coupons for people who want to be a part of this process.

There is no good way to eat soup with a knife.

Wherever I go, I find people who want to "implement agile" but they want to start with processes and tools. They could develop techniques first, but they want to begin with working at a very large scale and comparing capabilities across teams and maintaining individual accountability and individual review. They want a big program they can plug into their existing system.

A lot of organizations want to "go agile" starting with long-range planning, so that they can control the direction and results of the agile teams and track their progress toward n-year goals. They want an agile way to drive their teams in a straight line.

Some corporations have layers of hierarchy devoted to contacting customers, usually in the interest of controlling perceptions and getting marketing intelligence. They wouldn't let developers within a mile of anyone who actually uses the software, for fear that they would let the internal culture and personality of the company leak out. Or worse, they might verbally discount the difficulty and cost of making a change to the product.

In many places, they want to "go agile" but without changing the software. They want to add stuff on, but no testing or refactoring because the code is hard to work with, comes from a contractor, is old. They want the benefits of high quality and fluent development, but without requiring a change to the way code is written or tested.

We've tried it. It sucks.

In light of the agile manifesto, those questions all sound like "what is the best way to eat soup with a knife?"

There is no good way to eat soup with a knife.

You can eat soup with a knife, but it will be messy and slow and inefficient. You might come up with some really creative ways to eat soup with a knife, and build up a lot of process and mechanism so that you don't make too much of a mess.

It will (at best) be the least awful way to eat soup with a knife.

You will feel somewhat disadvantaged and unhappy with your whole knife-soup experience. You'll see other people enjoying their soup in cleaner clothes and you will feel a little unhappy. That is the experience you should expect.

Mind you, eating soup with a knife is better than starving to death. Maybe a crippled form of agile is a good first step on your way to a more satisfying experience. It's a fine place to start, but expect to have some disappointment and expect to have more fundamental changes take place later on.

I will happily help you start from where you are, and I am not going to make you feel bad about it.  But at some time we may have a friendly conversation about soup utensils.

Do me a favor, watch me. You may need to talk to me about soup.