How to start a startup without hiring developers first.

First hire your product team. You're looking for the following skills, ideally in the order below. How many actual individuals is up to you and your budget, but avoid conflicts of interest, especially between product management and marketing, graphics and user experience.

1. Product manager
2. Product marketing
3. User experience designer
4. User interaction designer
5. Graphics designer
6. Prototype builder
7. Business intelligence specialist

Then set them on their voyage product discovery. Let them explore for awhile. Build paper prototypes. Fail. Build design prototypes. Fail. Build an alpha tester base. Then you can start hiring your first Scrum team of 5-9 individuals, and this could be months after you've got your product team. This team should contain the following skills, again ideally in the following order.

1. Scrum master
2. Developer in test
3. Data analytics engineer
4. QA engineer
5. Developer
6. Release engineer

Your scrum master gets to work with the product manager on the backlog, and helps hiring the rest of the team. The developer in test starts setting up automated testing frameworks so that the developers have it there day one. This is also true of data analytics, who should be ready to provide an easy framework for the devs that supports multi-variant testing and the BI specialist is happy with. Get your manual tester in early, and you want them to have plenty of experience with spotting edge cases and confident enough to challenge the product team on their decisions before the developers have worked on story. Then, and only then should your developers start on product stories, so it's only at this point you need straight up developers. While the release engineer skill set technically comes after this, you'll need it at the end of your first sprint.

Don't have probation periods, because you're good enough at hiring to not screw up so badly that a week's notice is more important than showing new starters you value them day one. Give everyone laptops so that they can pair work, be that designing or programming. Set aside focus periods [No meeting Friday / no comms between 1pm-4pm ]. Make meeting agendas mandatory, and default them to 30 mins, not 1 hour. Teach everyone, including HR & admin Agile, Scrum and Lean. Don't skimp on fruit, water, tea & coffee. Start with test driven development as the very first lines of code your team writes. Do informal code reviews. Have information radiators, that actually work, sprinkled about. Make business and performance stats available to everyone, easily.

Then sit back and watch luck be a huge, but ever so slightly smaller, part of your success.

Death to the P1!

I often hear developers and product owners talk about all the P1 issues on the storyboard or in the backlog. They need to stop it. It is only the order of the backlog that matters. Having stories that appear to equal importance confuses the developers and encourages management to think teams can work on many parallel work streams. Worse, cynical programmers will laughingly say ‘everything is a P1, except for the other stuff which we’ll never do anyway’ and they are often right. If work isn’t worth doing soon, it shouldn’t be at eye level for the teams, so calling a bunch of stories low priority will sound their death knell.

Product owners can steer themselves, and stakeholders towards lean and agile productivity by avoiding talking about buckets of priorities. It’s hard of course, especially with product work that spans multiple teams, instead talk about how stories, features or epics relate to each other. ‘Is getting the biplane flying more or less important right now than the catch the pigeon feature?’

Probation periods or punishment periods?

Having changed jobs I'm currently in a probation period. I have, for a time, lost many of the advantages of full time employment I previously had, and it feels like a punishment for exiting my last employment. Recent family events have made me think quite hard about things like fitness, healthcare and pensions, none of which I'm entitled to during my 6 month probationary period.

I can, grudgingly, understand that the notice period is short during this period but withholding employee benefits feels like mixture of punishment and old fashioned 'you should be grateful for a job' thinking. When you're trying to hire clever, in-demand individuals who want to work in autonomous teams where their contribution and commitment is valued, you need to reflect those qualities in how the company treats its those new employees day one.

And as my friend Ian Cackett pointed out, it actually shows you're not confident enough in your hiring procedure to trust that you've made a good hiring decision. That makes me nervous about the company. Have you hired badly in the past and don't think you've fixed that yet? So actually, who should be sitting on the naughty step? 

Agile : ideal or ideology?

The word ideology has a string of negative connotations. It’s used to describe nightmare government regimes, disastrous processes and blind loyalty. When I first thought about writing this article I wanted to describe Agile as an ideology, but swiftly realised that would worked against what I was trying to communicate. So, I’m turning to the word ‘ideal’. The Oxford English dictionary defines it thus,

adjective

• satisfying one’s conception of what is perfect; most suitable:the swimming pool is ideal for a quick dip, this is an ideal opportunity to save money
• [attributive] existing only in the imagination; desirable or perfect but not likely to become a reality:in an ideal world, we might have made a different decision
• representing an abstract or hypothetical optimum:mathematical modelling can determine theoretically ideal conditions

noun

• a person or thing regarded as perfect:you’re my ideal of how a man should be
• a standard or principle to be aimed at:tolerance and freedom, the liberal ideals

Which sounds like a good thing. Agile is an ideal. It is not a process, and just following Agile methodologies will not be satisfactory to those that think of Agile as an ideal. Many of the Agile ceremonies are easy. It’s easy to run 15 minute daily stand-ups and it’s easy to have a retrospective every two weeks and pick apart the low level details of the completed sprint, but neither of those things are going to make a team Agile. The tragic beauty of Agile is that even doing just those things will improve most software teams performance, and will convince managers and other stakeholders that they are a successful Agile organisation. They probably aren’t but they have benefited from it already. The issue is that the steps they have to make to become Agile are hidden to them, they don’t know they haven’t reached it. It's fearful for them too, as it relinquishes micro-management for unproven quality gains. The problem comes when the Scrum team starts ‘grokking’ Agile, while their managers see it at best as another process and at worst just another fad. It’s understandably tough for management who are above the day to day to understand that Agile is an ideal, as they aren’t seeing it every day, and I suspect Agile courses rarely effectively teach that side of it. However once the box is opened for developers they'll want in, they want to embrace Agile and they’ll move further away from the managements worldview, causing friction and probably leading to dissatisfaction.

It means those dev managers who see Agile as an ideal have to go to their CEO and say ‘this is what we are striving for, you’re going to need to understand it and embrace it, but I think you're going to love the results.’ That takes bravery.

‘Agile’ Bob Hartman, who trained me and my original teams in Agile effectively said ‘the harder the project, the more you must strive to be Agile in it’s execution’ and it was great advice. My advice is, if you are thinking of moving to Agile, and you’re a small or mid-sized company, you’ll need to train everyone who sits in the tree above the developers too, or expect the developers to seek greener pastures where Agile is seen as an ideal and not just a word. When I interview developers, and increasingly QA they often ask, how Agile are you? And sometimes they tell me they want to leave their existing organisation to go somewhere 'more Agile'.