Getting better – in leaps

The first million you ever make is the hardest – or so the saying goes.

This is not only true, but its true at any scale. The first £100 you make, is the hardest. The first £1000 you make is the hardest. The first £10k you make is the hardest.

This is because the hard thing is not generating the money, but learning how to operate at a different order of magnitude. Earning £10k (or £20k or £30k) means getting an employer, turning up for work. Earning £100k means working at a higher level, customer interactions, or management or something. Earning £1m probably means running your own business (or winning the lottery). Each level requires totally different skills to the level below. The hard thing is learning the skills or knowledge necessary to switch levels.

It applies to anything else too. For example sports; competing nationally is a step up from competing locally, just as competing internationally is a step harder that competing nationally. They require different commitment levels, different fitness training regimes, different dietary plans.

What do you do in your life that you could do an order of magnitude better? What do you need to learn, what skills do you need to develop, in order to operate at that level?

By |October 29th, 2009|Improvement|0 Comments

Is Rails Stagnating?

The reason Rails is so amazing is the way it pushed the boundaries, and made everyone accept an order of magnitude improvement.

On a business level, it made it an order of maginitude easier to create a websites. Companies that could not afford websites now can. Small teams that did not have the ability to build great services, now can. Twitter, even though it eventually moved on from Rails, is an example. This pushed the creation of all sorts of cool new services, and ideas.

On a programming level, its embraced the use of meta-programming. Not a new idea, and possible in many languages to some extent. However meta-programming was always considered far too complex to be understood by mere mortals. The word magic was regularly used to describe it. Now teenagers working on small ruby libraries use meta-programming regularly. Its become common place. Ok, so its often used where its not necessary, but its no-longer considered too scary to even go near.

So the question becomes – is Rails still pushing for order of magnitude improvements?

Many web sites are now services more than sites, they want to use things like server push, asynchronous processing, schemaless databases, and probably other things we don’t yet know about. Rails can feel painful, and a colleague of mine even says he finds it too constraining to do these things in.

Rails created a momentum by pushing some developers on by an order of magnitude (and left many more stagnated and left behind). That momentum still exists, is Rails keeping up with it, or holding it back?

Well right now, Rails has stagnated, but this is because its doing a thorough rewrite, making many much needed improvements. As we get closer and closer to Rails 3, I wonder if afterwards, we will see it once again start to push the boundaries, or if we will need to look elsewhere…

Twitter certainly felt they had to look elsewhere.

By |October 27th, 2009|Technical|0 Comments

Crowd behaviour on a London Bus

I just witnessed one of the most interesting events I have ever seen on a London Bus.

This was a ride on a double decker bus on  a Saturday afternoon. On this particular trip there was a crowd of youths on the top deck, making a lot of noise as groups of teenagers typically do. A passenger came downstairs to complain to the driver, who did nothing.

After the bus had travelled a few stops, the noise became much louder, so loud i could hear it over my iPod. The driver was forced into taking action. At the next stop, after allowing passenger to disembark, he placed a radio call, reporting the noisy crowd on the upper deck. He then kept the bus at the stop and did not continue with the journey. One or two passengers from the lower deck (which was about one-third full) spoke to the driver, and understanding that he had called the police decided that everything was OK. They would wait and continue their journey after the police solved the problem.

After the bus was stationary for several minutes, one of the noisy crowd from the upper deck came downstairs to see why we were not going anywhere. He went straight back up stairs and announced:

Hey guys, I think they are waiting for us to get off. I’m serious, when I went down there everyone looked at me – I’m telling you, they want us to get off

Next comes a girl – about 16, with an assertive manner – who walks right up to the diver:

What is the problem – do I have to get off?

She gets no answer at all from the driver, despite trying several times. So she walks back upstairs, and tells the crowd that they have to get off the bus. Down they come, totalling about 30, and get off. The girl then gets back onto the bus, and once more addresses the driver:

Why didn’t you tell us? You could have asked us to be quiet? You could have asked us to get off the bus sooner, and not wasted everyone else’s time?

Again no response from the driver, several others from the group get on and again question the driver. Very politely, clearly annoyed, but mostly curious as to why no-one had said anything to them. They still got no answer and eventually got off the bus. Immediately the driver closed the doors, and drove off.

By |October 24th, 2009|General|0 Comments

Guiding a Self Organising Team into Efficiency

I just came back from ScrumGathering in Munich, and one of the hot topics was teams. How they are structured, and how to make them most efficient.

Scrum states that teams should be self-organised, and this will allow them to form into the most efficient team possible given the set of people in them. But it doesn’t go into any detail on how this works.

This is where the talks at Scrum Gathering picked up. It was immediately apparent that there was not much agreement in what is meant by a self-organising team. Several talks defined this, and one focused on providing a specific and general definition.

Summarising what the general ideas seems to be, I get the following:

  • The team should be given goals, and scope of work to be done. This cannot be self organised and is outside the scope of the team.
  • When a team self organises, roles, behaviours and processes emerge naturally. These identities (to give them their generic name) are not possible to predict, and may or may not be efficient. Therefor this will not always be a good thing.
  • Self organisation takes up energy – unless you apply more energy to the team, the self organisation will stop. It may not stop in a useful or efficient state.
  • Changing external factors (timelines, scope, physical environment etc) or internal factors (team make up, rules and so on) will cause a change. This could be good or bad.

Several talks focused on how you can influence the emergent behaviours, roles processes, in order to make the team more efficient. I guess this means able to produce large amounts of well written code while still being happy at work.

One very abstract mode, ABIDE, was presented, as well as two more practical models, “Anderson’s Seven Levers” and “The Contains Differences and Exchanges Model” (both in Mike Cohen’s presentation). To my mind, both of these are implementations of ABIDE. They provide ways in which you can modify the inputs to a team, to generate new emergent behaviours, and the idea that you have to move very slowly. You can’t know what new behaviours will emerge as a result of your changes, so you have to constantly stop and observe if what your doing is creating good or bad effects.

There were also a couple of ideas how teams change and evolve over time. You should cook a team, but not burn them, as well as the classic,  Storming Forming Norming and Performing

Personally I find this all very interesting, and there is no doubt that having been introduced to these models helps understand how your team dynamics are working (or not). But its not clear if that makes it any easier to create a team that works well. It seems to me quite surprising that we ever brought into the idea that leaving a team alone and not interfering will create an efficient team. At the very least it requires an outside, objective observations, which feed into the team, as well as active facilitation (intervention)

By |October 23rd, 2009|Entrepreneurial|2 Comments

Talking at Scrum Gathering

Gwyn and I presented our Bamboo Toolbox at the Munich Scrum Gathering on Tuesday.

The gathering was my first Scrum Gathering, and was one of the most enjoyable, friendly, and all round rewarding events I have been to.

We had the presentation slot just after lunch on the second (of three) days, and just before the board panel, which I expected many people to skip, and use as a chance to see Munich. In short, possibly the hardest slot of the conference to attract an audience to! great!

So I was flattered and surprised when the room started to fill up 15 minutes before the talk, and by the time we started, all the seats were taken, and people were having to start sitting on the floor.

Our presentation was intentionally pushing the boundaries. Gwyn and I both decided early on that we wanted to create a presentation that people would either love, or hate. We went for a high energy style, with acting, fights, and an argument or two. We also wanted to some some audience interaction, but scaled that back a bit, partly because we were not sure how well it would play, but also because the room was a bit too packed to make it practical. In retrospect we could have pushed things even further. Expect bigger things from the next talk.

The content of our talk was more practical than most of the other sessions, and this seemed to go down well. We presented a number of new scrum practices we have invented (as well as a few we didn’t invent, but have adopted). Broadly these split into the categories of Sword Fighting, Stakeholder Management, Poker, Meetings, and Misc.

Each practice was developed to solve a particular problem that we have found, and we tried to cover the problem, the solution, and our practical experience of using the new practice.

Finally, we had everyone in the audience write down one item from our talk that they were going to commit to taking back and trying. When people read them out what interested me was that the most popular ones, like “Odd Times”, were not the ones I would have guessed. It seems that small practices that can fix small but specific problems are more popular, as are ideas that a bit odd, but not too extreme. No-one committed to going back to their office and replicating our practicing of building paper swords :-)

The talk went down very well, and we got a lot of good feedback, which will be taken into account to improve the talk next time we give it. The same idea has been accepted for London’s XP day, but the time slot is shorter so we will need to restructure the talk somewhat to make it valuable for the people who will see it there.

The slides will not be available online – as they are totally useless without seeing the whole presentation, but over the next few weeks we will be rolling out a series of blog posts explaining our new practices.

By |October 23rd, 2009|Entrepreneurial|0 Comments

What is big software anyway?

This recent post by Ola argues that if you plan to write big software, you have already lost. He is talking about why we should not write projects with many many lines of code. To me, this is a bit of a truism. Is it not always the case that doing the same thing is less lines of code is better?

Well, as long as your not talking about deliberately minimizing and obscuring your code I think it is.

“Big projects” get a lot of flack from the development community, but I don’t know – what is a big project? Is it:

  1. A system that has many lines of code?
  2. A system that has many developers working on it?
  3. A system that has many features?
  4. A system that has many users?

I don’t think anyone would agree that choosing 1) as your goal is a good thing.

There are obvious reasons why 3) and 4) are desirable goals (even though you may, rightly, question those reasons).

2) Is interesting. Its often arrived at for historical reasons, such as “we brought a company, so got all their developers”, productivity reasons; “100 programmers have to be able to add more features than 2, right?”, or even publicity reasons; “We have the biggest best team working on this”.

Each type of bigness has its own problems. Which big are you complaining about? What is the best way to fix those specific problems?

By |October 15th, 2009|Technical|0 Comments

Google Wave – First Impressions

I’ve been REALLY looking forward to Google wave, and got my account last night. So far I have only had a few minutes to play, but enough to form an initial impression.

It has a huge amount of potential, but there are one hell of a lot of rough edges to polish up first. I want to be able to move about comments made by other people as I restructure a wave document to add sections for ideas in replies . I can’t do that, i want to, but I can see why its a bad thing too. That’s going to be a tough one for google to solve.

There doesn’t seem to be any clear way to flatten a wave in order to convert it into a document that can go in a file archive. In the long run it may become an old fashioned idea, but for now, its pretty much going to be my main use case (collaborate on an idea, extract is as a blog post).

Undo – where is it?

Overall though – i like it! :)

By |October 12th, 2009|Entrepreneurial|1 Comment

Finally – Sequence Diagrams without the pain

I love UML sequence diagrams! It’s a beautiful visual way of understanding how a series of method invocations work, what the interactions between them are, and generally a kick-ass tool for good understanding of whats going on.

I have sequence diagrams! They are slow to draw, difficult to modify, and a big drag on a project that has to maintain an up to date set of them.

Introducing WebSequenceDiagrams.com. These guys have come up with a really cool way of turning almost natural english like:

TwitClient -> Twitter: Post status "Testing cool tool"
Twitter --> TwitClient: Success
Twitter -> Notification: New Tweet

into diagrams like:

TwitClient -> Twitter: Post status "Testing cool tool"
Twitter --> TwitClient: Success
Twitter -> Notification: New Tweet


Now I once again love sequence diagrams.

By |October 8th, 2009|Technical|2 Comments

Agile projects don’t *, They get smaller.

Agile projects don’t run late
Agile projects don’t run over budget
Agile projects don’t have bugs
Agile projects don’t deliver the wrong thing
Agile projects don’t end up just not working
Agile projects do get smaller.

In most software projects there are many things can go wrong. Development taking too long, bugs, features that don’t quite fit the legal requirements. The list is surprisingly long and often feels endless. There are just so many risks to balance, and trade off with each other. It is no wonder that very few projects have a clear handle on their risks, and possible mitigation. This is a root cause of failure for many projects.

When working with agile, there are fixed dates for the end of each iteration, and often a fixed number of iterations. If a project is running behind, less has been done by that date. The timeline normally equates to budget, so the same argument holds. A similar argument applies to bugs. They require time spent fixing them, which is time not spend adding all the features planned for a given iteration. In fact there is a similar argument for anything that can go wrong. Building the wrong things results in time being spent to change it – meaning less is done by the end of iteration.

In an agile project any number of risks get transformed into exactly one risk. That the scope decreases. This is much easier to manage as it leads to a simple binary question.

Has the scope decreased to the point where there is no longer any value in continuing?

Let me be very clear here. I’m not saying that agile reduces the risks in a project. What it does is change them into something that is easier to understand. This makes it easy to communicate. This will make it much easier to have the difficult conversations.

By |October 7th, 2009|Entrepreneurial|0 Comments

Bamboo Toolbox

Gwyn and I are going to be presenting at the upcoming Scrum Gathering presentation in Munich.

We are presenting a tour de force of all the practical techniques we have developed over the last 18 months or so, while New Bamboo has been aggressively moving into a fully agile model. Lots of traditional scrum (and general agile) practices have been tried, some of which were ok, some of which were exceptionally useful.

In our 90 minutes we will cover all the biggest wins we found, regardless of if they are well known or totally new. For each topic we explain exacly how it benefited us, and what problems we encountered with it.

Gwyn especially deserves a lot of credit for this presentation. I have been flat out on a big project, and Gwyn has been driving me to find time to talk to him and share my ideas, and has put in most of the effort on preparing the slides, and the cool extras, for the actual presentation.

By |October 6th, 2009|Technical|0 Comments