AWA interviews Antony Marcano for Agile Tour London 2016

The London leg of the Agile Tour will be reaching the capital on the 21st October, featuring a packed line-up of local and international agile experts. As a member of the programme committee, Adventures with Agile are interviewing a selection of speakers at this year’s conference. So, today we’re kicking off our Agile Tour London [ATL] interview series with Agile Coach and ATL keynote speaker Antony Marcano.

1.  Tell us a little bit about your agile journey?

My first professional encounter with ‘Agile’ was before we called it ‘Agile’. I spent the mid-late 1990s working on DSDM projects and then encountered Extreme Programming (XP) for the first time in the year 2000. XP resonated with me immediately and it felt like it had an answer to everything that I felt needed fixing in delivering software products at the time.

I became one of the early adopters in the early 2000s, working exclusively with agile methodologies including XP and Scrum soon after. I began blogging about XP practices, especially TDD and Agile Testing in the early 2000s. Before I knew it I was speaking at conferences, invited to contribute to books (like Agile Coaching, Agile Testing, found myself mentioned in books including Bridging the Communication Gap, Software Craftsmanship Apprenticeship Patterns and more) and was asked to pick up from where Mike Cohn and Brian Marick left off as Technical Editors for Better Software Magazine.

I’m especially inspired by the humility yet incredible competence of people like Kent Beck and Ward Cunningham; the patience and empathic insight of Rachel Davies and the insatiable craving for knowledge of colleague and friend Andy Palmer.

I’ve always prided myself on being practitioner and coach. I’ve spent many of the last few years as a team-member, as well as a transformation coach… I don’t want to be ‘that coach’ telling stories about the challenges and pressures I faced 10 years ago or speaking purely theoretically about a methodology… When on a pure coaching gig, I can usually talk about the challenges and pressures I faced this year when delivering on a real project under real pressure. I like my experience to be fresh and current.

In between all of this, I like to share what I’ve learned when I can via ideas.riverglide.com, at conferences like Agile Tour London and to students, via my regular slots speaking at Oxford University’s postgraduate Agile Methods programme.

2. You’re speaking at Agile Tour London the title of the session is Don’t Put Me In A Box, what are the origins of the talk?

This all came about when I realised that ‘traditional’ job titles define boundaries that constrain the agility and ability of the teams that I worked in. The story begins when I was around 12/13 years old. The talk is my personal journey. I take everyone on that journey so that they can see how I arrived at the conclusion that – the more we put people in traditional boxes of developer, BA, QA etc. the more we hinder the agility of our teams. It’s an honest, sometimes emotional, story – where I’m sharing my personal experiences that lead to me largely rejecting the idea of ‘traditional’ job titles. I hope that the audience will take inspiration from this story to explore how this thinking might benefit their teams and organisations.

3. Our Government clients request that there is a role of ‘Delivery manager’ when using Scrum. Do you have an opinion on this?

Change takes time. Having someone taking care of a ‘delivery manager’ role can be a valuable role on the earlier stages of the journey, providing an additional layer of insulation between the team (supported by, say, a Scrum Master) and other parts of the business still locked into a cost-based-accounting / predictive-planning / waterfall culture.

One thing I learned a long time ago is that transformation starts from where the client is, evolving from there. Some consultancies/coaches sell ‘Agile in a box’ – as if you can buy a flavour of ‘Agile’, install it and it just works. This simply isn’t supported by the facts or realities of evolving the culture, process and skills of the people in an organisation. That’s an attempt to short-circuit the inevitable and natural process of change. I’m often among those called in the aftermath to take a more realistic approach to increased agility. Some purists may believe that a Delivery Manager shouldn’t be needed if you are genuinely ‘Agile’, however, if the role facilitates the journey in a given context, I say embrace it and work with the Delivery Manager to find ways to continuously smooth the path ahead.

4.     Which sessions are you looking forward to seeing while you’re at Agile Tour London?

All of the talks look interesting. I’m especially looking forward to Helen Lisowski’s session “Listen with your eyes – Non-Verbal Communication for Agile Teams”. The message we might think we’re sending is not always the message received and vice versa. I’ve worked with Helen and this will be my first time seeing her speak.

5.     What else is on your radar for this year; any conferences, events, books etc.?

For the last few years I’ve not been able to get out much as a huge amount of my time was consumed helping my son develop his career as a racing driver. I’ve now got a bit more space to do things outside of this so am taking things as they come for now. I’m working on an agile transformation, principally as a player-coach with a large international corporate. I’m really enjoying the diversity of this as I’m not just coaching, I’m slicing user stories, pair-programming and leading by example. I like this because it allows me to demonstrate, in practice, the concepts I write and talk about. I tend to do projects like this for at least 6 months out of every 18 so that my skills and experiences are current and authentic.

Conference wise, I’ll be giving the closing keynote at the British Computer Society’s SIGiST end-of-year conference and trying to catch up on publishing my thoughts from the last couple of years. Right now, I’m passionate about helping people avoid the problems caused by thinking of User Stories as ‘features’. What they called User Stories were really ‘functional requirements’ sliced into feature or action increments. This can lead to difficulties and I’m hearing of many folks rejecting the practice mainly due to common misconceptions about User Stories.