> Your user stories should not be interdependent. As you describe above, you feel as if you would have to move all stories to in progress, if you started any specific one. This indicates that you have epics or stories that are not vertical slices of business value. I'd recommend looking at what you have and trying to re-write it in such a fashion that each story is independent, relatively small, and delivers a piece of value to your customers when completed.

I'm not sure how to go about doing this in my case. In many examples I see of Kanban in practice, it's showing some project where the "core" work has already been done and they can afford to add small user stories that would involve introducing small extra pieces of functionality that could be implemented independently of one another - you just break off a feature branch for each one, create the feature and merge back into master/develop.

In my case though, my user stories are all 'MUST' requirements and will both determine and be fulfilled by the core body of work. There will be a lot of code in common, for example, that will be used to satisfy the user stories "As a [test sequence] developer, I want to be able to create a test procedure that can monitor the oil pressures." and "As a [test sequence] developer, I want to be able to create a test procedure that can monitor the temperature of the oil."

What you said about "vertical slices of business value" gave me a great launching point for doing some research, though. On this page (http://www.deltamatrix.com/horizontal-and-vertical-user-stories-slicing-the-cake) under "Why transitioning to the vertical user stories is difficult" it mentions something called the Iceberg Phenomenon which seems to describe my situation pretty well - the user story about being able to measure oil pressures will alone involve doing 95% of the work, and it'll take maybe just 5% of the work to then later add functionality for measuring oil temperatures as well (to cover the other user story).

I just don't see a good way to decompose user stories (things that will actually add customer value) into small pieces here - all I can see are ways to create implementation-oriented tasks (e.g. "Create a class to handle this functionality") that might be small and easy to work with.

> Kanban is a lot harder to follow than Scrum. Consider why you have chosen Kanban. Many teams use Kanban when they are unable to get a full iterations worth of backlogs defined because requirements change so rapidly.

Really? According to one of Atlassian's Agile guides (http://blog.valiantys.com/en/jira-en/jira-agile-scrum-kanban), Kanban is the simpler option to get started with:
"If you are looking to start working on a board quickly and with minimal configurations, then Kanban is the way forward. Other than creating new columns and mapping your statues, Kanban requires very little configuration and enables users to get started pretty much instantly.
[...]
If you are working on a smaller scale project with only a limited number of issues, then Kanban is undoubtedly the simpler option."

> I also wanted to add some thoughts on the actual Kanban board. A key concept of Kanban is visualizing your workflow. Your current board looks out of the box. Many Kanban teams will customize their Kanban flow to be more granular.

Yeah, you're completely right. This board was about 30 minutes old when I posted my question. The other 50% of our company's software R&D department is pretty inexperienced with software development in general and so one addition I could make to the board is a "Code Review" column. That way, I can assign work to my colleague and when he believes it's done, he can move it to the "Code Review" column. When I have time I can then pull items off that column, check he's done a good job, make modifications if necessary and then move it either back to "In development" or to "Done".