As a Certified Scrum Master, I continually re-assess how to best apply Scrum principles to deliver software projects. One of my main criticisms of Scrum is that it is often misunderstood and sold as a panacea for bad software practices. It seems dev managers want to believe that Scrum will allow them to extract stellar results from poor and mediocre performers.

What a real Scrum looks like:

(Photo by flickr user boocal used under a Creative Commons license.)

In my experience, the only common ingredient to all successful projects is: strong software developers. Scrum (or any other software methodology) is no substitute for solid software fundamentals (such as strong object-oriented design skills).

Katie Lucas expresses this more eloquently. Her entire post is worth reading for anyone in the software profession.

Every methodology I’ve come across has, at its kernel, a very small section labelled “do magic here.”

[A software methodology is sometimes] pushed as a way of getting normal people to do something normal people can’t do. Normal people can’t do OO design properly. I don’t mean that derogatively as such. I can’t draw still life, I can’t run 100m races…People have various different talents. One of those talents is doing OO design and some people just can’t do it. No matter how much paperwork you surround it with.

And at the core of [a software methodology] is a small area where you have to use OO design talents…. if you don’t have them, it’s like having a methodology for running the 100m.

“Step 1: write about running really fast. Step 2: Go and draw a plan of the racetrack. Step 3: go and buy really tight lycra shorts. Step 4: run really, really, really fast. Step 5: cross line first”

It’s that step 4 that’s the tough one. But if you put lots of emphasis on 1,2,3 and 5 it’s possible no-one will notice and then you could probably make a lot of money selling the methodology to would-be
athletes who think there’s some “secret” to being a 100m runner over and above being born with the ability to run fast.

Dealing with personal issues tonight, no Kinetic update.

In a historical romance Sun Tzu is represented as saying to Wu Yuan: “As a general rule, those who are waging war should get rid of all domestic troubles before proceeding to attack the external foe.”
–Sun Tzu, The Art of War (“The Art of Maneuvering”), 1933 translation

As a consultant, I charged my clients $60-$100 an hour to build software on their terms. I was a mercenary. I traded my finite time for money. It was deeply unfulfilling. On June 1, 2005, I notified my clients that I would no longer take on new business.

As a software artisan, I can bring my vision to life, in congruence with my values. I can craft software with limitless leverage. The deep joy I experience when I bring beautiful code to life is profound and deeply satisfying.

What’s the spark behind Kinetic? One day last June, while working on an architecture diagram using Microsoft Visio, several of my neurons misfired, and it’s an itch that I’ve been trying to scratch ever since. The idea is simple: How can we use words to describe complex diagrams? For example, is it possible to have a tool that will allow me to update an organizational chart or a network diagram just by changing a few lines of text?

Granted, this isn’t exactly a new idea. Google and you’ll find dozens of programs. But I’ve yet to find one that satisfies my twin requirements of: 1) usability and 2) flexibility.

1. The tool needs to be simple to use. The litmus test is always, “Yeah, but will my grandma be able to use it?” It should be dead simple to update the organization chart.  AT&T Research’s Graphviz rocks, but in my opinion, the syntax might be a bit too arcane for the average user.
2. The tool needs to be flexible. Can the software handle a variety of diagrams? Ideally, I’d like to be able to use the same software to generate both organizational charts as well as network diagrams. Tools such as Diagrammr are limited in the types of diagrams they can generate.

As it turns out, meeting both requirements is a hard problem. It’s a design challenge, a tug-of-war. Make the tool flexible, and usability suffers. And vice versa.

http://www.flickr.com/photos/kitone/2478029256/

I know it’s a challenging problem. The scary thing is–it might not even be solvable using current technologies. And that’s the very reason I’m drawn to it. Paul Graham calls this “running upstairs.”

Use difficulty as a guide not just in selecting the overall aim of your company, but also at decision points along the way. At Viaweb one of our rules of thumb was run upstairs. Suppose you are a little, nimble guy being chased by a big, fat, bully. You open a door and find yourself in a staircase. Do you go up or down? I say up. The bully can probably run downstairs as fast as you can. Going upstairs his bulk will be more of a disadvantage. Running upstairs is hard for you but even harder for him.

What this meant in practice was that we deliberately sought hard problems. If there were two features we could add to our software, both equally valuable in proportion to their difficulty, we’d always take the harder one. Not just because it was more valuable, but because it was harder. We delighted in forcing bigger, slower competitors to follow us over difficult ground. Like guerillas, startups prefer the difficult terrain of the mountains, where the troops of the central government can’t follow. I can remember times when we were just exhausted after wrestling all day with some horrible technical problem. And I’d be delighted, because something that was hard for us would be impossible for our competitors.

Thanks for joining me on this stair-run.

I consider Kinetic “an experiment” because:

One, I have *no clue* whether my half-baked ideas are even feasible (given my grasp of current technologies), and the only way to find out is to actually try them out.

http://www.flickr.com/photos/clivrow/2733115397/

And two: I continually tweak/mash/purge/brainstorm/test new ideas as I clumsily evolve the project towards something potentially useful.

Joel Spolsky calls this “Fire and Motion“:

When I was an Israeli paratrooper a general stopped by to give us a little speech about strategy. In infantry battles, he told us, there is only one strategy: Fire and Motion. You move towards the enemy while firing your weapon…It took me another fifteen years to realize that the principle of Fire and Motion is how you get things done in life. You have to move forward a little bit, every day. It doesn’t matter if your code is lame and buggy and nobody wants it. If you are moving forward, writing code and fixing bugs constantly, time is on your side.

Expect Kinetic to be under constant flux. I have a directory on my MacBook Pro desktop, named “Language syntax ideas.” I’ll try out the promising ideas, and discard those that make the product confusing.

Ready–fire–aim.

Ralph Waldo Emerson quipped: “Who you are speaks so loudly I can’t hear what you’re saying.” Let it marinate for a bit. I think it’s quite profound.

All human creations are unwitting reflections of their creators. And so, like every other project I touch, Kinetic will necessarily reflect my values and ideals.

At first, I considered using today’s post to outline this project’s “core values.” But I then realized it wasn’t necessary: After all, the project’s values will eventually find a way to “speak loudly” on their own.