Managing Technology Means Being Wrong a lot

This reminded me so much of a friend of mine who is big into Scrum (He sits on the Scrum Alliance Board). To him, every problem is solved by some combination of Scrum. If you're running 20 teams on a program, you need a scrum of scrum. If your division has 120 teams you need a scrum of scrum of scrum. Got 500 teams in your huge enterprise? Well you need so many scrum-of-scrums that I lost count.

As technologists we are always looking for simple metaphors to handle complex systems. Simplicity is good -- we should always strive for it. The goal in creating a large system, whether a computer system or a system for managing programming, is to make it as brutally simple as possible, and not a bit more.

Of course, the very next question should be, how do I know when I've gone too far either making things too complex or too simple?

The answer to this is 1) small steps, 2) err on the side of simplicity, and 3) have a very responsive system that measures feedback and changes course

When I look at the ClimateGate emails, what strikes me the most is people actively trying to prevent the error-correction system -- open data and methods, honest peer review, critique -- from happening. This sets off big alarm bells. I got the same feeling from my Scrummy friend: whenever something didn't work using Scrum, his answer was always "well it wasn't being done right", not "we need to challenge our beliefs here"

Scrum just doesn't work that well at the program level. I'm not saying it can't work well at all, but I'm saying that you don't just take the way things happen on a co-located team of 5 and somehow "expand it" or blow it up like a big balloon and end up with something that can effectively track and manage 20 projects. It'd be nice if it worked like that, but it doesn't. (And don't take my word for it. Feel free to try it and find out for yourself. After all, the point of this article is that you have to take small steps and adapt, not that others can do your thinking for you)

The same goes for Kanban.

At Agile 2009 I went to a session on making better Story/Kanban boards. The guy started out with a simple board with a couple of columns. At the end of the 2-hour session, each of our teams had created this color-coded, post-it-tagged system from hell. It looked like something a serial killer would have created in the back room of his dank apartment -- if a serial killer wanted to build a new e-commerce application.

How did it get like this? Everybody worked in a vacuum and we all used intuition as to what might work or not. And intuition will commonly fail you when working with technology.

I'm going to repeat this in case you missed it: Intuition will commonly fail you when dealing with technology.That's why good technologists are also good scientists: looking for patterns, forming hypotheses, and coming up with reproducible tests.

That ResizeableArray that worked so well dealing with 400 people at your school is not going to scale to 400K people. The functional programming style used by you and three other guys probably won't scale to 50 off-site developers with varying degrees of competence. The offshore system that worked wonderfully well on your last project isn't going to work at all on this one -- even though it's basically the same type of project. The state management system you used when running on one box is going to flake out on you when you've got 100 boxes. I could go on. And on.

So we take little steps, we measure, and we adapt quickly. Whatever we do, from creating little pieces of functionality to creating Kanban and story boards to creating bug-tracking sytems, we take little steps, measure, and adapt quickly. Every team, every industry, every company is different, and unless we get good at those basic skills, we're just working from book knowledge and seat-of-our-pants thinking. Architecture Astronauts are not just architects. We have a little one inside of each of us.

Once you've lost your ability to be wrong, it's time to leave the game.