Some thoughts in no particular order after 3 years at a start-up
Have a plan – sounds obvious but a weakness of agile is that it can give rise to the illusion that there’s a plan. However, in reality planning is emergent as the iterations and stories float by. Emergent planning means that the team can drift or can become distracted, or it’s hard to turn down non-core projects because you can’t point to a strategy or project delivery. Plans can be flexible and tested in the MVP style, and changed when they are proved not to be working – but there’s no excuse not to have one.
Then ensure everyone is signed up to the plan. Even in a small team it’s easy for factions and agendas to emerge. Getting everyone pulling in the same direction is non-trivial
Sales and marketing are waaay more important than devs admit/realise
– Make time to support sales and marketing efforts. Devs love to scoff at sales people with their suits, lines in BS and vague promises. But the hard fact is there are very few successful products that have gained market share on technical superiority alone, and the chances are your team is not producing one of them. You need to think long and hard about your sales and marketing approach.
Only today did I read in the Sunday Times that the publishers of Grand Theft Auto hired Max Clifford to create a media shit-storm regarding the moral failings of the game. Resulting, of course, in millions of additional sales.
Avoid non-core projects at all costs – Pressure for sales may mean you’re tempted to take on side projects, or do free work in exchange for some kind of marketing exposure. DON’T!! DON’T EVEN THINK ABOUT IT!!
My experience was that this was a huge distraction and money-pit and time waster and just a generally bad idea that should be pushed back against at all costs. If you’re tempted and think you can manage it – trust me it will still be a distraction. If you’re still tempted time-box the work hard and ensure all stakeholders understand that there’s a maximum amount of time you can afford.
Don’t white-label and abstract features until at least 2 customers ask for them – This is basically a rewording of YAGNI – it’s tempting to assume all customers will want feature X or Y. However, until you have hard evidence that multiple customers want the same feature, try to avoid wasting time abstracting them. This sounds simple but is very difficult to police and make hard/fast decisions about without getting devs backs up – kanban boards etc can help here to demonstrate to the team how these tasks can add time and cost to the project.
Invest in your team – This doesn’t just mean salaries, this mean listening to your employees. If you notice the team doing a lot of overtime, do something about it. Encourage R&D, make sure they have some “slack” time, pay for them to attend conferences, encourage them to blog, take them out for dinner. Encourage experimentation with new technologies. Let them do flexi-time, homeworking.
Things like this make a job enjoyable, and mean your team aren’t scouring the job ads.
So in conclusion, as usual, we can say the golden rule is that there are no golden rules, no doubt success can be achieved by ignoring all of the above, but these stuck out to me over the last few years.
See also:
Convivial Coding 