In today’s blog post, we break from our usual format to bring you an interview with Paul Ranson of Smash Thinking. I first met Paul at an innovative business conference a few years ago, and I’ve really enjoyed hearing about his innovative approaches to leadership and getting things done.
Paul has been managing development and programming of graphically rich applications (mostly video games) since the 1980’s. He has been the go to resource for blue chip organizations across the planet making innovations for companies as diverse as Nissan, British Aerospace and Tesco. He is a passionate reader of business books and has introduced new techniques such as Agile, Lean development or Visual Communication at the businesses he has worked at.
I recently caught up with Paul for a ‘virtual’ chat, and Paul shared some really interesting insight:
1. So your background was games design and development — that sounds exciting! What challenges did you face, and what techniques did you find to overcome them? Are these challenges specific to the video games industry?
Yes I guess I have one of the best careers ever working in games.
It can be exciting and demanding. It seems that with video games everyone you meet has an opinion.
In games (and frankly everywhere) your customers generally can’t articulate what it is that they want. Henry Ford is quoted that his consumers would have wanted “faster horses” if he’d asked them. With my career I often found myself talking to kids who would describe their next game requirement as merely being a version of what they were currently playing with a slight mod to the story (or with a bigger gun).
To resolve this me and my colleagues would often find ourselves immersed in children’s culture of the time…. As a consequence I know far more about Transformers, Ninja Turtles, Barbie and Dr Who than any adult of 49 should (haha).
Another challenge that I often met in games development is that my developers would often forget that they were not building the product for themselves.
Although this was not always the case… my later products were designed for an audience with much more casual gaming interest than teenage twenty something that was into Call of Duty. This made retention of the really eager coders an issue at times. My recruitment policies mutated so that I would be attractive to developers with a more mature out look or those with family.
I offered work practice with flexible hours and it was an absolute last last last resort if we worked late or weekends. By being family friendly I think we ended up producing family orientated products.
2. So, in a fast moving environment, do you see agile analysis, development, project management and leadership techniques as important?
Yes. Development has never before needed to become disciplined yet light touch. We have New Millennial workers would want to be more empowered and what seems to be an insatiable desire to innovate new stuff.
There has never been a more exciting time to innovate. The effort required to lift your idea into a product has never been easier. Computing Power has never been cheaper. Modern product tech can describe and execute a delivery within weeks. Management therefore has to be just as fast.
Historically (as I touched on above) the innovator kind of worked in a vacuum. Customers don’t know what they don’t know. Agile democratizes the development process by giving the end customer a voice in the development process and furthermore at a point where the development team can do something about it.
I feel that a key plank of Agile is that we bring the development closer to the customers.
As I mention in my book “Agile Fu“: Once Agile is running I love the aspect that developers develop, project sponsors sponsor and managers manage. Done right, a bubble of harmony emerges where everyone contributes value to the solution.
When its working well it genuinely creates an amazing working atmosphere that I love getting up for work for.
3. You’ve written before about “agile leadership”. So often, agile is seen as a buzzword that can be distilled into a number of ‘paint by number’ practices — and this view can cause issues. Yet leadership implies so much more. How important is leadership in these types of situation? How does leadership differ?
Agile is very of the moment, like those bushy beards that the hipsters in London, New York and California. I find that there is a practice observed by some folk to use what I call FRAGILE… this is the phenomena where people talk agile but actually continue to use their existing methodology.
To be truly agile requires some management guts. People by their very nature cherry pick the bits that like and avoid the bits that they don’t like. The devs love to be left to dev, the sponsors like the flexibility and the management like the idea of transparently tracking the workforce. However, each department have areas that they want to avoid… the sponsors don’t like to commit to decisions, devs don’t like to communicate and the management don’t want to communicate when problems arise.
A gutsy manager has to face down all of the objects and up-sell the benefits for the process to work.
4. So — you’re an advocate of agile (clearly!). What one single piece of advice would you give a team or organisation embarking on agile for the first time?
Embrace transparency, but take a deep breath cause it is hard!
There is a cartoon that has done the rounds a while back where a manager stands at the front of a crowd and asks “Who wants change”…. “Everyone” is the response… the next panel has the same manager with the same crowd “Who wants TO change”… “no one” is the response.
Agile produces some tools that allow the team to expose their development on a daily basis… this needs to be shared with EVERYONE.
It also means that the sponsor has to commit to a tranche of work and share these decisions with EVERYONE.
The management also need to be prepared to share the work throughput with EVERYONE.
I think that this is the heart of why agile is so powerful. It becomes very hard for people to hide their skeletons.
By being clear and transparent you *should* engender a sense of comradery between all the members of your innovation team that will pay back in spades.
5. You’ve recently written a book — tell us more about it. How can our readers get hold of it?
I’m so glad you mentioned my little book!
Its designed with the hassled innovator in mind. It can be read in about an hour and I estimate that it could (should) be done on Friday lunch time.
Its written as though you were with me at my local pub and priced as though you had just bought me a pint too.
Click here to find out more about Paul’s book “Agile Fu” on Amazon.co.uk
I intend to make a series of these pub type reads on the subject of management of innovation. This one Agile Fu is about managing the development of an innovative product. My new book (plug alert) will be on the Amazon store on July 27th and is called Innovation Muscle. This gives tips on how to come up with an innovative idea in the first place.
6. How can people stay in touch with you? Do you have a blog.
I’m so glad you mentioned this too.
My blog is at www.smashthinking.com
If you sign up now you get a free gift that is the Agile Checklist. This is a distilled version of my ebook. I write a blog post every week in a similar style to my books.
By signing up now you will get advance notice for a limited offers my books too.
Great, thanks for your time Paul!
A massive thanks to Paul for sparing the time for this interview. If you enjoyed this article, take a look at Paul’s blog by clicking here and don’t forget to check out his recent book.
If you’ve enjoyed this article and would like to read more like it, click here to subscribe.