I’m Mark Dalgarno, co-organiser of the Lean Event and about a dozen other conferences such as UX Scotland, Agile Manchester, UX Cambridge and Agile Cambridge. I also work as an agile coach and have been applying agile methods for many years now.
My colleagues and I are planning to share how we’re organising the Lean Event to give people a better idea of what they can expect from it – and also to show how we’re using lean techniques to develop the event itself.
The Lean Event is about lean, incremental and iterative approaches to products, services and business development. It’s for people who are passionate about using agile, user-centred methods and experimentation to find a fit between products and markets.
I drew this sketch for my colleague Scott back at the start of 2015, when I first started thinking about the Lean Event:
I think this summarises quite nicely the type of people and organisations we think will be a great fit for the Lean Event, although if you’re at the intersection of a couple of those areas you’ll probably learn a lot from the event too.
I’ve been involved in software product development for almost 30 years now, mainly as a developer (and later manager) in start-ups, but also in mid and large-sized enterprises. I’ve taken pride in providing great user experiences since I started my programming career.
I first came across agile methods in 1999, when a consultant at the company I was working with talked to me about them. Later I was introduced to lean startup via Redgate Software’s Neil Davidson, who pointed me at Eric Ries’ Startup Lessons Learned blog. Later, I was fortunate to join Redgate and attend the Business of Software 2010 conference, where I heard Eric speak on the topic. His book was published the following year, and Neil ordered 100 copies for Redgate.
I’d been using agile methods for a few years prior to joining Redgate, but had only worked with old school product management processes. The companies I’d worked with would talk to a few important customers, develop ideas for how we could meet their needs, develop software, then ship it.
But the cycle for releases was frequently one major release a year. We also often injected our own ideas about what the product should do – based not on our ‘user research’ but what we thought people would be interested in (or, more often, what we were interested in). This can work, but often doesn’t. We also didn’t do much to check how users interacted with the products we shipped – aside from looking at the usage of a very few important features.
Agile, user-centred methods were a revelation to me, they offered a low cost, low risk way of finding product-market fit through a continuous cycle of experimentation, learning and adjustment. Not only that, there were real case studies, which meant that the method itself had some validation. I started applying them at Redgate and later in my conference business.
Putting on high-end conferences is a time-consuming and expensive business. Anything that can be done to reduce the risk is good. In my coaching work I will also often introduce these methods as a way for my clients to get feedback on their ideas faster and so reduce risk.
So why the Lean Event? Well, I want to continue to spread the word about these approaches, but they can be hard to apply. I want to learn more, and I think that other people want to learn more too.
So, with the Lean Event, we’re pulling together 16 (or so) of the leading practitioners to share their recent work and thinking with our participants.
I’m hoping that you’ll to come to the event: but more than that, right now I’m hoping that you’ll tell me what would make it so compelling that you couldn’t not come. We’ll do our best to incorporate your feedback into the event.