Trailblazer Development Techniques

Don’t you find that when you get a small team working on a project, that they end up being far more productive compared to when you load that team up with many developers, designers, testers etc?

Well I have, so much so, that I tried to formalize it at Aegeon.

We called it ‘trailblazing’ development, but I sometimes lovingly called it “Guerrilla Warfare Development” too. Anyone that has ever been to a Code Party or Developer/Startup camp will be familiar with it. Essentially the principles are to address the 20% of functionality that delivers 80% of the value to users. It addresses the most typical use cases and ignores the ‘fringe’ use cases.

The purpose of this is really to answer the question; “I have this idea, and I am pretty sure it would work, but I am not sure – what do you think?”, then you apply the “Nike – Just Do It” attitude. So rather than spend weeks/months on planning, documentation, meetings and discussions, you get the key people in a room to work on the project.

Here are some suggestions on how you too can implement this;

1. Don’t worry about Scope, at first

Don’t get hung up on fixing the scope at first. Just focus on working out what the core of the offering is. In fact, as you will see below, try not to fix the scope at all. Just make a list of the features you want to deliver, and prioritize them. then start from the top of the list and work your way down. But let your team work in flux with this. Because you are wanting to get intense work out of an extremely focused team, you will need them to work on what they want – just give them guidance on what YOU want – and that is the list.

2. Focus

This really should be no# 1 on the list. You need to focus, focus, focus. More so than ever. You need to omit the details, remember that you are working on the most common flow through your app. So for example, if you need people to login to your app, then build that. You are not going to build “forgot password” or “forgot username” they can come later. You can’t “WOW” users with this functionality.

3. 2x Developers, Designer and Product Lead

This was my magic team. Your designer is working on your UI, hopefully you can split your devs to a front end and back end dev, and your product lead is focusing on the functionality and doubles up as a tester. You want this team t be cross-functional as well (so that everyone can do a little bit of the other person’s job). The product lead tests to make sure that the key parts are being delivered. BTW: It is important to raise and prioritize defects. But only address the real critical blockers as part of this process.

4. Don’t ignore solid foundations

Always make sure you are building on a solid foundation. That is, you don’t want this to be a throwaway exercise. Build on tried and tested frameworks, and because in all likelihood, you will be moving what you are building into a production world, you need to make sure you are doing things right, or at least in a fashion where you can refactor them to be right. My platform of choice here is Grails, but RoR, .net, php frameworks and lightweight Java frameworks can be good for this process too.

5. Know your compromises

You will need to make certain compromises when going through this process. Such as;

• Limited testing and test coverage
• Code quality may not be great
• It will be buggy
• it won’t have ‘spit and polish’

These are things that you will need to come back to. BUT (and a big BUT), make sure that you do schedule into the next phase to do so! The purpose of this exercise is to prototype quickly, and then build from the prototype, but you always want to make sure where you are starting from is a good base. Since you are probably halving your dev effort/time, factor in 25% at the start of the next phase to do cleanup.

6. Fix time it – everything else floats

If you want to fix time to a weekend, a week, a month or 3 months, it doesn’t matter. The key here is to fix time, not your deliverable. Remember, you don’t want to fix your scope, you just want to have a task list and attempt to deliver as much as you can in a fixed amount of time. The team needs to know that they have X amount of time to deliver something that works. They will then make the compromises as to how to deliver what they can in the time they have.

7. Co-locate

Co-location always helps with the development effort, as it reduced communication issues. I like putting the 4 people on a single table, that is the most ‘bang for buck’ communication you will ever have. But as long as they are co-located in the same room, you will get the benefits. When your time is limited, the last thing you want to be doing is spending time emailing and having meetings.

8. Motivation

Typically, I have not found this to be an issue. Fixing the time and floating the scope makes this exciting. But try and do some things such as prizes and awards for such things as most features delivered in a week or least amount of bugs etc. This motivates the team to do ‘better’ work. I have found that one of the most powerful things that motivates the team is to empower them. Let them decide what they want to build. Just guide them. And don’t worry, with a mature team, nothing will be forgotten, they will get around to everything, you won’t have anything missed.

9. The aftermath

Finally, we have the aftermath to cleanup. I have already talked about the cleanup you need to do in “Know your Compromises”. But try and schedule a portion of time after the effort ends to do general cleanup. Things such as;

• Remove links to functionality not implemented yet
• Stub any tests that need to be done
• Clean up any UI glitches
• Fail gracefully (maybe through standard error page) on unimplemented functionality

In Conclusion

Give it a shot, I would love to hear experiences from others about how they went, or if they have had similar experiences in setting up such a team. What were the benefits and downsides, what would you do different? I am keen to do more of this type of development, and want to learn from others too.

And on the suggestion of @RobertFischer, you must also subscribe to being a Rockstar Ninja