robjam.es

Today is my last day at Optus. I started here just shy of 3 months ago, and decided to leave to start an exciting new role within a small organisation in Freight & Logistics (more to come on that later). It was my latest foray back in a large organisation, and I have to admit, I am pretty sure I prefer working with smaller organisations and startups.

But in general, I must say, I have enjoyed my time here and believe that Optus is probably one of the better large organisations I have been with. But now that I don’t work for the organisation any longer I have some positive and negative things that are worth sharing.

First the positive; Optus’s engagement of their staff is really good. There is lots of activity and lots of (non-business) communication that goes on. Every level is catered for, if you want to do charity work or leadership, or just want to be part of a social group. There is lots of activities in that space. Senior leadership and management is quite visionary and passionate for innovation and challenge the competition. But this is stifled by middle management and heavy processes (see below). Finally, great facilities. Optus have spent a fortune on their campus in Maquarie Park, and its a good one. Lots of outdoor space and sunshine, big open workplans, and lots of cafes, parks, sporting acivities and an on-site gym. But I think the staff don’t exploit this enough. How many times have I been in a stuffy meeting room, wishing we could go outside in the sunshine; we have wireless and lots of tables and chairs. We should be using it.

On to the negatives. One word, ACRONYMS!!! They are absolutely deadly here and have an uncanny ability to slow everything down when you are a new starter. I remember the day that I started here, before I got to work, I was super charged, motivated and ready to take on my role head on. By the time the day was out, I was demoralized, beaten and lost total confidence of being able to take on anything meaningful within a short period of time. For the first month, I felt like I was learning a foreign language. If you can imagine how confident you would be in a country where you didn’t speak the tongue, that’s how I felt.

Optus should be a hotbed of innovation. There are smart people with smart ideas that are being pushed back by middle management with alternate agendas and heavy weight processes that take forever to push any kind of progress through at a rate faster than that of molasses expanding! Every initiative has to have revenue benefits attached (which is understandable), but there should be greater opportunity for R&D projects, and small skunkworks teams to innovate and disrupt the industry. The capability and willingness is there, but the culture pulls this back.

I don’t know if anyone from Optus is going to read this, and although I have focused on the negatives, I still think its a great place to work and there is a real opportunity to escape the black hole that they are going down – turning into the other monolithic Telco that they despise.

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

I recently read a blog posting from Seth Godin, that really hit the spot with me. Selling to business (particularly to small business) can be particularly challenging. Not only will they want exceptional value for their investment and ensure low costs, but they are extremely sceptical.

More so than consumers. This can be particularly daunting as it requires the seller to jump through a number of hoops to make the sale. Seth’s blog hit some quite topical areas about how to plan the strategy around this, and how product marketers and product developers need to work together.

In my experience (particularly in software), this is left too late. Developers come up with a great product, and then marketers are told “productise it!”. Turing a ‘thing’ into a ‘product’ is part of the lifecycle, and as a developer, I know the importance of working with the mrketing guys to understand fundamental aspects such as;

• Who is going to be our market?
• How do we reach out them?
• What is the problem we are solving for them?
• How will we provide the “exceptional value” and “low cost” that they are after?

In a recent project, using a Guerrilla development technique where we put together 2 developers, a designer and a product lead (who doubles as a tester), the product lead was a marketer. Apart from being an strongly opinionated and visionary individual, they provided a new perspective on t he product development that  helped getting it to market sooner.