Agile Manchester - Day 1
Agile Manchester 2019

Agile Manchester - Day 1

I'm in Manchester this week for the annual Agile Manchester conference. You can find out more details of it here.

So as appears to be tradition now i'm doing my daily summary of the sessions i've been to throughout the day and any key insights i've taken away. Needless to say Day 1 has not disappointed at what is my first Manchester conference (But certainly won't be the last based on today!)

Keynote - Tendayi Viki - Innovation as a wicked problem

Tendayi gave a great keynote on innovation and the constraints placed on it in a typical organisation. His comparison of innovation as the 'drunk uncle' of organisations i.e. we have to keep an eye on it and make sure it doesn;t do anything too controversial' means we end up forcing innovation into linear processes and decisions.

He gave some great examples of where innovative ideas in organisations are simply pushed back because their business case hasn't ticked a particular box in that organisations business process, or the business case is missing some financial information. The result? Innovation follows the business process, meaning bets on potential game changing ideas are trampled or financials are inflated in order to simply satisfy the demands of the business process.

We end up asking linear questions when it comes to innovation in business, such as 'how much profit can we make from innovation?'

Tendayi's comment that he has never seen a financial projection that has a downward trend (They all end like hickey sticks) got a good laugh from all of us - despite us all knowing how painfully true this is in every org we've ever worked in.

We explored the typical innovation framework which asks us to find the problem solutions fit, before we work on the product market fit and then finally the business model fit. For each of these stages processes need to be followed, certain steps need to be completed (Like jobs to be done, customer value propositions etc. etc.) and then we can finally say we have an idea that is usable.

Unsurprisingly the reality isn't this simple straight line of A-B-C. Its more a huge squiggle of a line that means we may need to do an MVP (i.e. build something) in order to work out if we even have a problem to solve. Yet business forces us to constrain innovation in many cases by not allowing any investment to build things like an MVP until we've proven we have a problem to solve!

We looked at the many many frameworks for innovation, design thinking, Lean UX and Agile. Despite all suggesting they are different (Or in one case can all be linked together into some huge, horrible mass of circles) it transpires they are all the same thing when it comes to innovation.

The keynote was a great start to the week and Tendayi was a great speaker and very funny. A really great way to start this conference

Morning Session - So you can sleep at night... ethics in software development - Jonathan Rothwell

I've attended well over a hundred conference sessions in my career. I've seen great workshops, interesting case studies and taken huge amounts of this knowledge back and applied it to my own job and the work I do with teams. Very rarely however, a session comes along that completely blows you away. Either some new technique that works like a charm every-time you use it. An idea that changes your thinking or a case study that gives you an extra piece of knowledge to use in the future. Very very rarely a session comes along that leaves you pondering it long after the session has finished. This, for me, was one of those.

Jonathan posed the very simple question. Are we ethical in our software engineering?

Now I work for a database development company. We don't build nukes. We aren't building software that gets used in microchips for missiles and we don't have Skynet purring away in the basement of the building. So I like to think the work my teams do isn't remotely unethical.

But, as a craft, as a job and as a business sector it appears we really have a lot to learn about how to build ethical software that considers the people who won't be using it just as much as the people who will.

Jonathan reeled off a huge amount of examples of where software engineering either had no idea what it had unleashed, didn't care or simply blamed it on the 'algorithm' for being at fault.

We went on a whistle stop tour through Medical malpractice (Radiotherapy machines that administered lethal doses of radiation to patients because a previous version had a bug - 6 people died), Breast cancer screening warnings not being issued because the 'algorithm' messed up. Children's toys that record speech having the recordings stored on an unprotected database that was hacked and shared online. Uber's lack of background checks and iffy business practices, Grindr sharing HIV status with contacts and allowing potential contacts to track you, racist soap dispensers, and the dark past of IBM's German subsidiary during the Holocaust.

There was so much in here it was hard to keep up with all of the ethical failures software development has had a part to play in. Jonathan's suggestion that we should all be braver in asking 'Should we really be doing this?' and being the 'shit stirrer' was great advice. We can all do this more. Think what would have happened if someone at Facebook had asked this before they opened up their API to Cambridge Analytica or an engineer had asked whether it was a good idea to copy the programming from the previous version of the Therac-25 radiotherapy machine.

The lasting impression for me was these two pictures. The first, German punch cards used to identify how many Jews were in the national census. The second, a quote from Jacob Bronowski as part of the Ascent of Man series.

No alt text provided for this image
No alt text provided for this image

Utterly compelling session.

Afternoon Session - Mentoring for Success - Kat Turner

The first afternoon session I attended was from Kat Turner doing a tutorial on mentoring. I use mentoring often in my role. Recently I've been preparing to kick off a group mentoring session on public speaking at work so thought this session would be useful to pick up some tips and ideas.

Kat went through the definition of mentoring - an experienced colleague using their knowledge to support the development of a less experienced colleague. No airs, no graces, no sense of seniority involved.

Kat also covered off the two different forms of mentoring - Sponsored (More of an American approach to mentoring) and developmental (More of a European approach to mentoring and the one you are probably familiar with)

As a group we worked as tables to discuss the core competencies of a good mentor. No surprises that being a good listener, clear communicator and building rapport were top of most tables lists!

We then went through the GROW model: -

G - Goal

R - Reality

O - Options

W - Will

Its a model I've used in the past. Although a top tip I picked up from Kat was to be transparent with the mentee about the fact i'm using this model with them (Something I've not done in the past! oops!). We gave the model a bit of a practice in pairs in the room as well, which was useful to dust off some of the less used mentoring style questions I've not used in a while!

In summary, this was a really good session to brush up or brush the dust off mentoring skills and techniques and understand a bit more about the differences between mentoring and coaching.

Late afternoon session - Introducing Agile - Surviving the immune system - Jon Ayre

Jon shared his (frankly huge 20+ year) experience of agile transformations with the room in my final session of Day 1. Jon used the very useful analogy of introducing agile to an organisation being similar to the immune system of the body.

Over generations our immune systems have evolved to deal with all of the dangers around us. From viruses and bugs to the iffy curry you had from your local takeaway. Our body rejects foreign or unknown entries into it. Organisations are the same. New ideas (Foreign objects) or things that are not familiar (Agile?) are rejected because the organisation has survived for years by having this protection mechanism in place.

Its a great analogy and along the way Jon shared the speed of change not having sped up at all (There is no data to back up the statement that change is speeding up when it comes to organisations). Why it took 48 years for us to invent can openers after tinning had been invented to store food, why we shouldn't be asking 'When will they get it?' because they is us.

Getting people to buy into agile is all about making it a shared experience. We appreciate Art through seeing it, Products by touch, but methods? Methods we only get by doing and experiencing it for ourselves.

Jon went through some of the approaches he had used in the past and how we could apply the same thinking in our own experiences. Having survived a couple of agile transformations myself this sort of knowledge would have been invaluable!

I left this talk with quite possibly the most brutally honest analogy I've ever seen. Jon was still using the immune system analogy and discussing us as agile transformers in an org as being like bacteria. Now the body has good bacteria and bad bacteria. You can even buy good bacteria such as Yakult (Those friendly bacteria things you buy in little cups) to aid your bodies immune system. But you also risk bad bacteria entering your system. Now, as Agile practitioners, do we want to be the Yakult, or do we want to be the salmonella?

Brutal yet brilliant!

Summary

So this was day 1 at Agile Manchester. It started strongly, continued that way through the rest of the day and was a great first Manchester conference for me. I've seen lots of new faces and learnt/re-learnt a bunch of useful ideas and techniques. My pick of the day has to be Jonathan's ethics session. This is something that'll stick with me well beyond this week and i'll endeavor to be the 'shit stirrer' asking the difficult questions when I get back to the office.

Look out for my summary of Day 2 tomorrow (Which should be shorter as i'm also doing my case study here on the Worst Team in the World)

To view or add a comment, sign in

Insights from the community

Others also viewed

Explore topics