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.

Z80 8 bit Microprocessor and Arduino Mega

My first computer was a ZX81, and as child I always wanted to make my own computer. However I always found writing software easier, and moved away from electronics to software. The Arduino rekindled some of that delight in physically making things,
so I started to wonder if an Arduino could help me understand how old 8-bit processors work, and kickstart the process of building one.

I bought two Z80s from RS Components, and after realising I was going to need a lot more digital pins than the Uno provides, an Arduino Mega. The video below shows my set-up running in test mode, which I reset at the beginning. The LEDs in the bottom right are power (green), clock (yellow) and reset (red). The reset blinks 3 times, to clear the Z80 program counter and probably it's registers. I read somewhere that 3 times was better than just once, but I'll play around with that to see if it's true.
The strip of LEDs at the top left are the low bytes of the address bus. The yellow is the 1's and the red the 128. Oddly once I hit 128 in the PC unexpected things start to happen. The LEDs at the top right are memory request (blue), read data (red) and write data (yellow).

When the processor is reset, it's also fed 0's on all of its data lines. This means that when the program counter requests each instruction, it gets a NOP  (no operation). This causes the program counter to increase by one, hence the address bus counts up in binary. Right now all the Arduino Mega is doing is monitoring the address lines and outputting the result to the serial monitor. This works, and proves at least that the Arduino is capable of limited support of the Z80, as well as making me more happy that I probably should be. One thing to love about the Z80 is that the clock signal can be manual, you can literally step through the instruction processing.

I've uploaded the very basic code to GitHub here.

The next step is to make the software recognise the memory request & read data signals to provide instructions, effectively working as a ROM. The after support RAM and IO. I plan to use a small Arduino controlled OLED display to act as an output for now. No idea about input though!

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'. 

Pair programming, code reviews and checking in cheatsheet, part one.

My software development cheatsheet, part 1

Pair Programming
Pair programming is a technique that hopes to achieve three main things. Those being: better architectural design, shared knowledge and code quality. Pair programming often reduces waste during code reviews as core concepts are already decided, leading to fewer rewrites.  When done well it helps to build trust and understanding between developers. The following steps are all equally important and can be considered a cheat sheet.

• Define the task, with small goals in mind. You’ll then be able to move in the same direction quickly.
• Agree on the solution. It’s worth spending a little time before coding to fix in your minds how your solution will work.
• Talk constantly about what you are both doing. 
• The developer with the keyboard writes, while the other one directs. An analogy is that of driver and a navigator. The driver at the keyboard makes the tactical decisions while the navigator keeps them on course and suggests short cuts. 
• Switch roles at least every two hours and maybe even every 45 minutes.
• Consider checking into a temporary pair-programming local branch in git at each swap point. This shouldn’t be master.

Code Reviews
Code reviews are there to catch mistakes, keep the code base balanced and gain the insight of another pair of eyes before you submit your work to the wider business. It’s there to help and protect you, not to criticise you or force you to change complete direction. When you are reviewing others code, you should be wary of asking for changes to make the code look like you had written it. The following points should be considered during code review.

• Select a reviewer as close to the code as possible. Therefore if you are pair programming or working with someone on a user story, they should be the reviewer. You must stick with this reviewer for re-reviews.
• If at all possible, do code review together at a desk before it is even pushed to Git. Even better correct problems there and then. This makes it more immediate, less confrontational, more productive and a better experience all round.
• Review the code, not the coder. Refer to the code, not the coder.  Don’t say ‘your code here tests the wrong object’ but ‘this code tests wrongObject, not rightObject’
• The reviewer should assume that things have been done by the reviewee for good reason. The developer has likely given it more thought than the reviewer, so challenges to how something has been done should be diplomatic and open. Equally, the developer may not have thought of everything and may not have thought of the best solution. When such things are raised in review, they should be discussed and either corrected or clarified (e.g. better code structure or comments may resolve the issue).
• The developer should not take feedback as personal criticism. They should view them as honest questions/feedback aimed at ensuring that the delivered code is of an acceptable quality (fulfils the requirement, complies with best practice in terms of architecture, design and code etc.). Any feedback should be considered openly and as an opportunity for improvement, learning and to deliver a better end product.
• Be clear in identifying the issue and suggest obvious fixes. ‘This doesn’t work’ is worse than useless. 
• Programming style should be challenged not demanded. Rather than saying ‘This code style is not following the command pattern’ say ‘Consider the use of the command pattern?’ This however is not an excuse to ignore best practice or consistency issues with the code by the developer.
• When you review code you become part of that story. If a reviewer just rubber stamp the review, they’re directly responsible for failure. If they sit on a review, or re-review you are responsible for it being held up. Check you requested reviews often.
• Always respond to every code review comment. Either with “Done” or with a suitable response. This aids re-review.
• Point out the good. When reviewing code you may learn things yourself or spot elegant solutions. When that happens, say so, the coder may be unsure that it was elegant and it positively reinforces the good stuff.

Checking in
Git is complex and powerful, and there is a lot to say on it, however these general check-in points are important.

• The code you write is valuable and needs to be backed up as much as possible so that there is no danger of losing it.
• Check the code in at end of the day, as a minimum. Otherwise you are preventing others from picking up the work to get it finished. We can’t ever predict what will happen from one day to the next in terms of illness or transport problems.
• More frequent commits mean more flexibility in code reviews. This leads to faster turnaround and less context switching.  Small commits are easier to understand, easier to review, and can be merged to master much sooner. This means that your code gets picked up by others sooner, reducing the complexity of conflict resolution, and ensuring that your code is in use sooner which gives you a higher degree of confidence that there are no corner cases that you missed in your unit testing.

Everything I know about agile software development I learnt from playing Dungeons & Dragons

Wikipedia src : Sargoth

Roleplaying games, the kind you play using odd shaped dice sat around a table with friends, are about three things. You play a role, usually a dramatic heroine or hero, you are part of a story and you overcome challenges together achieve some goal. Software development is also best done sat in groups, with people you like. It’s also about overcoming challenges to achieve a group goal, and often each person in the team has a particular role to play.

Diversity
The most famous RPG is Dungeons and Dragon, in which a party of adventurers explore Tolkienesque worlds fighting foes and finding treasure. The secret to a successful adventuring party is diversity and the same is true for development teams. If everyone in your team has the same background, the same experiences and outlook they’ll tend to solve problems in singular way and make software for people like themselves. An adventuring party made of just dwarven warriors might find it easy to fight their way through hordes of orcs, but without a cunning thief who will pick the lock to the impenetrable doors that guard the dragon’s treasure? Better to have a diverse team and end up with software that has been thought through by people of different backgrounds, genders and cultures, teams who won’t get snagged by issues that come from a single perspective.

Leading
Roleplaying games require a Game Master, sometimes called a Dungeon Master. This is the person who has the story their head, who frames the challenges and who plays the parts of the other characters in the story. It’s like a Scrum Master and Product Owner in one. The worst kind of Dungeon Master is one who ‘railroads’ the players. Rather than encouraging the players to figure out how to proceed, they tell the players what to do and railroad them into a particular course of action. This isn’t much fun for the players and rarely goes to plan as the Dungeon Master can’t think of every turn beforehand. It’s not playing to the strength of the game. The same is true for software development. When you’ve hired a talented group of developers, testers, product owners and sys ops don’t tell them as a manager what to do. Tell them what is required, and let them get there themselves. If they wander off from the user story, guide them back to it by reminding them of the features needed.

Resource planning
A big part of roleplaying is essentially resource management. Players worry about how many spells they can cast, how many gold coins it costs to buy that magic axe or how many sips they have left in their potion of healing. Eventually it becomes risk management. Trolls have hidden enough gold to buy the magic axe and a bunch of healing potions, but the fight might be so tough that characters could be defeated. Perhaps it’s better to face the orcs first and use the little treasure they have to buy a single healing potion so that they have a better chance of defeating the trolls. Or maybe they should try and sneak in and steal the treasure instead.

Software team’s dilemma is how to divide the work up between them. It’s rare that there are enough programmers, let alone QA to work on all the ideas the company has at once. It helps to think of resource planning in terms of risk management. Is it possible to take a small step that brings in some value rather than rushing into a big long project without knowing it’ll be successful? This of course is a fundamental principle in Agile software development, but incremental gains work just as well in D&D as it does in product development. When you don’t have quite enough QA engineers to give you complete coverage, do you risk reducing coverage or match the pace of development with that of testing? It depends on how valuable and risky the project is. Orcs or Trolls? Silver pieces or gold?

Experience
As characters gain in experience in roleplaying games they also gain in power, and more interestingly options. A freshly made wizard can recite a single and low powered spell once per day but as they gain in experience, and go up in levels their titles and options change. An experienced Enchanter can change shape, go invisible, befriend monsters, throw fireballs. They can also build magical towers that aid their spells and train apprentices to do their lesser magic.

The same is true in a way of developers, both in terms of technical and product experience. When they start out they are often given very specific jobs to do that aren’t very complex. As time goes on they learn more about best practice and the way their software is used. The variety of problems they can solve increases, but additionally and vitally the creativity they can bring to bear on product development also improves. Senior team members should be building wizard’s towers and training apprentices.   

No More Heroes
There is one area where software development shouldn’t be like RPGs. In Dungeons and Dragons the heros and heroines grow in power and become superheroes, saviours, invincible and invaluable.

When you have heroes in a software development team it can cause all manner of problems. These are the people who stay late, who can seemingly solve any problem, who will avoid all the process and management layers to get things done. The trouble is they never look back, they rarely leave behind code that others can work with in their quest to get things done and disrupt the workflow of others because of their sudden needs for unplanned QA or releases. The set expectations that others can’t meet, hoard knowledge and avoid helping others. While the hero mentality is noble, and not to be squandered, it is better to show them why teamwork is finally more productive and desirable that wearing spandex and a mask.