After attending Agile in the City in Britain’s bustling capital for the first time I’d like to share my experience of the event together with a brief overview of my personal highlights and learnings.

It was an event full to the brim with relevant and varied content - an intense three day conference located in a venue in 15 Hatfields which really had exactly the right size for this event. The conference rooms had good acoustics, a break-out area for quiet energy refilling or a bit of emailing and a coffee-lunch-talking come together main room where also the exhibitors were located. Also the soft side of the event, the catering, the care of speakers and the technical stuff like microphones was handled very well - I hardly noticed any problems anywhere at all.

Although it was a diverse group attending with various roles and levels of experience a large proportion seemed to be rather experienced agilists including Product Owners, Scrum Masters and Agile Coaches. I find it very difficult to estimate the numbers but it should have been between 100 and 150 people. What surprised me was how friendly, open and interested everyone was, no matter how much experience they had. I would recommend the event wholeheartedly to any speaker, experienced and in-experienced alike.

The really amazing thing though were the various sessions - all of them relevant to agile and in each and everyone I attended I learned something new. I will not give a complete summary of each talk but rather want to highlight one key take-away for me personally from each talk.

Descaling Agile, Gojko Adzic

In Gojko’s talk about scaling agile - one of the big themes we saw in multiple talks - he included le Châtelier’s principle on systems in equilibrium:

If a system at equilibrium is subjected to a change, the system will react in a way that minimizes the effect of the change.

Gojko smartly uses this principle to explain that changing systems that are in a stable state are naturally very difficult to change especially if they are large and complex. What I like about the view is that it makes it impersonal: it is not a specific person or role that fights back but actually the system with its proponents itself. This helps us to think rationally about the problem and accept its difficulty as a property of change.

Kaizen to karōshi - burnout in agile teams and what you can do about it, John Clapham

An eye opener in this very intense talk was that burnout usually happens to those engaged and energetic people that enthusiastically push themselves to ever greater achievements. His examples were very drastic but straight from real life. The 12-stage model from Herbert Freudenberger and Gail North for burnout brought the message home especially because the first couple of stages feel familiar to quite a few of us I guess:

1. A compulsion to prove oneself: demonstrating worth obsessively; tends to hit the best employees, those with enthusiasm who accept responsibility readily.
2. Working harder: an inability to switch off.
3. Neglecting needs: erratic sleeping, eating disrupted, lack of social interaction.
4. Displacement of conflicts: problems are dismissed

I also found these factors that affect the likelihood for burnout illustrative:

• Mismatch of person and job role
• Perceived absence of fairness
• Value conflicts between an individual and their working environment

A key take-away for me is to manage our energy instead of time and focus on work that energises us.

Agent of destruction, Caryl Regnault

This was a rather unusual talk about her Product Owner role at Wonga and how it changed when Wonga went into administration. From the stunned looks of co-workers being made redundant on the spot and guilt of the survivors.

It was interesting to hear her evoke the new environment, scaling down rapidly but also becoming much less agile as the administrators were not always supportive. Her role actually transformed from a PO to a jack of all trades like it would usually be in a start-up.

Although I hope I never get into the same situation the new focus and how they approached it was quite interesting as it might be transferred to more usual situations: Investigating all the services they were buying in the light of the new situation. Many were actually not needed anymore. Also interesting, some contracts didn’t have a get out clause, meaning Wonga still has to pay for services they are not using anymore. The exercise of checking all licenses and services paid for is of course well suitable for anyone. Ensuring get-out clauses are in service contracts too.

A strong reduction of offered services focusing only on what is really needed and removing anything unnecessary or only nice to have. If using business value as a driver the same can be done in flourishing businesses.

My main question at the end of the talk was, why would anyone stay in such an environment? The answer was quite simple, the freedom Caryl experienced was key, which reminded me of the burnout talk discussed earlier and how freedom furthers happiness.

One super dog, and her servant leader, Darren Yeates

This was probably the most intense and surprising talk of the day at least for me personally. Darren brought Millie the search dog with him which gave us a chance to see a glimpse of their fantastic relationship.

The talk started out very emotionally with a discussion of a failed rescue mission in 1980s in Canada that ended with the missing boy found dead due to the very cold temperatures. Darren explained expertly the circumstances and the reasons for failure and showed us what rescue organisations like Lowland Rescue learned from the failing and how they operate nowadays.

Apart from the impressive organisational sophistication of rescue missions, what struck me most in the second part of his talk was how closely related the topic was to agile. In fairness it was one of the strongest accounts I heard of an agile way of working outside of software production.

Example points were around

• Planning is quick and as detailed as needed to get started.
• Search areas are defined and assigned to teams like Darren and Millie
• Feedback from teams is communicated to everyone whenever updates are available and plans are updated accordingly.
• The right skill set used in the right areas
• Finished teams can check with other teams if they can help

Resilience as a continuous delivery enabler, Steve Smith

This was a very engaging keynote with some interesting takeaways around robustness and resilience in the light of a devOps implementation. Steve spoke about robustness and the drive of many organisations to minimise the amount of problems by increasing robustness. He made a compelling argument as to why this is an overinvestment and pointed at practices meant to enhance robustness that are actually making frequent or continuous delivery impossible:

• End-to-end testing as it has low coverage and high cost
• Change advisory boards as they introduce large delays
• Change freezes or heightened awareness periods which are often occurring around key events like the financial year end

With hindsight it is a straightforward argument: the time it takes to execute practices enhancing robustness is prohibitive for releasing often. Especially his opinion on end-to-end testing gave me a new perspective and triggered further discussions later during the conference.

Instead, Steve recommends to focus on resilience, i.e. the ability to recover from problems, very quickly which of course sits perfectly with the goal to deliver frequently. This includes the ability of services to continue in a reduced state, e.g. in case of a failing search capability to keep a website functional without the search functionality.

Governance so good, people prefer to use it, Cate McLaurin

I am sure many in the audience were drawn by their curiosity to the talk to see if there really is such a thing as ‘Governance so good, people prefer to use it’ - at least these were my own thoughts.

Personally, I have experienced governance mainly as sets of reports which were a chore to produce and of little value when I tried to use reports coming from governance processes. In Cate’s opinion governance is necessary, it provides information needed for decision making upwards in the chain and it provides safety for those using governance to inform. So far it still smelled of old habits and waterfall processes.

Her implementation however, spoke of verbal reporting in regular, short meetings where the whole team reported their past progress and current situation. Teams are allowed to report in any shape and form they see fit, e.g. verbally, using a presentation or a video.

The teams also had to report on the fulfilment of the ‘Local Government Digital Service Standard’ which they started doing in written form without being asked to do so just because they wanted to write it down for themselves too.

It became very clear that for Cate and her peers the information content and the short intervals of receiving it are the main concerns, how it would be reported secondary. They also aimed at a light-weight style so as to not use up precious resources. Together with the empowerment of the teams to report in their own way the smell was gently blown away.

What really inspired me though was the addition of working out loud, publishing decisions and discussions for the public to see. I wish I could see this level of transparency within companies I work with - even if only internally. I guess I’ll try it myself with the next working group I am starting, probably about our internal professional coaching. Let’s see how that goes. Meanwhile you can have a look at HackIT.

Variety: The Spice of Life and Secret to Scale, Cat Swetel

In her funny and witty keynote Cat took us in broad sweep from the new relationships we have with companies, UBER style connection business models to personal experiences when shopping over to Ashby’s Law of Requisite Variety that explains the properties of stable systems.

Her more biological view was powerful in its clarity: Stable systems must be able to balance metabolism and maintenance. If there is a certain amount of energy for the system, e.g. a company that wants to grow, metabolism is what we want to focus on and maintenance should be minimised. Hence her advice that lines of code are a liability and that we should seek simplification e.g. by killing products and services that are not key. Simplicity allows for shrinking the amount of maintenance and allows energy to be spent for the metabolism.

This was a very nice way of explaining the need for simplification in organisations to aid their growth. However, what really got me was the later discussion on variety in terms of people. Cat stated the very simple point that variety of people, from a variety of circumstances allow for a variety of actions. The more different people are involved in finding solutions, the more creative the group can be, the more different opinions, experiences and approaches can drawn from. This also fits well with Conway’s Law:

organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations.

So far I have seen diversity mainly related to acting in a fair, ethical and non-discriminatory way. For the first time now have I seen an explanation of a benefit in what can be achieved with greater variety of people - which should not be construed as viewing the aspects of fairness and ethical dealing as unimportant.

Establishing business agility at the bank, Julian Holmes

Agile transformation in a large organisation is challenging due to the size and complexity of the business - that much is clear to anyone who witnessed such a transformation initiative. Julian and his colleagues used a typical and effective structure:

They started with a 6 week discovery to understand the environment, especially how technology and business interact. The aim was not only understanding but also trying to effect some amount of change already in this initial period and of course to gain trust so further change would be easier.

Some of the interesting key points were (1) to talk about agile with the business addressing their hopes and fears, (2) to pick one team and their connections within the organisation to start with and (3) to work with leaders in business and technology to facilitate their own agile journey with training, facilitation of agile events, visual planning and transparent working.

There was much said that I could refer to here, e.g. about the simplification of the banks target operating model, the highly visual way in which Julian and his team worked with the bank, creating a hub of information radiators, communities that were created, e.g. coach and retrospective communities, lean coffees etc.

My two main takeaways however, were the numbers (1 year duration, 300 people in the departments they worked with, 2 system integrators and 14 consultants in rotation with no more than 6 at a time) and the goal of the consultants to enable the bank to continue the journey of transformation without them after the initiative finished.

Empowering people is impossible: the neuroscience of intrinsic motivation, Jenni Jepsen

At the end of an intriguing time at Agile in the CIty: London Jenni gave us a super-energetic endnote to think on well after the event itself finished.

At the core of her empowerment argument was the point that empowerment and motivation are intrinsic aspects of people and cannot be created directly from leaders or managers. Instead people need space and receive control to become empowered.

Neurologically there is again the discussion of the two competing systems in our brain, the limbic system for basic control (fight or flight) and the hypothalamus for creativity. If we want to be at our best we need space and psychological safety to calm the limbic system and activate the more creative parts of our brain for optimal solution finding creativity.

She presented us with a graph depicting ‘give control’ vs. ‘competency & clarity’ (technology competency and organisational clarity) in which chaos reigns in the upper left (lots of control but not much competency & clarity), frustration in the lower right (not much control but lots of competency & clarity) and the optimum is around the 45º line from the centre of the graph. The conundrum is how to reach the line, do we first teach or first give control? If we try to first teach to achieve competency & clarity, when do we have taught enough to allow for more control - and how much control? The simple takeaway is that we first give a bit of control in a leap of faith and see how much additional competency is needed for that stage. Then we give more control and so forth.

That last nice little take away was about how to change our perspective on and our reaction to the world. We can start thinking about reframing a bad situation by finding something good in it. For example when you lost some money on the street, instead of being angry and annoyed about the loss try to see that someone will find the money and imagine how that person will feel like (it probably made their day).

When trying to influence someone in the negative mode (aah, I left 50 bucks with the change in the shop), start where they are (that really sucks) and then see if you can frame it positively with a new perspective.

So What?

This little question popped up in quite a few talks and discussions and rightly so I think - because in the end what do I do with what I learned? The talks were inspiring, fun and thought-provoking, discussions with people in breaks and in the evenings engaging and surely networks were extended.

But other than having a good time and meeting great people, what’s the impact if I am not going to use it? So, let me try and think up a sentence for each talk I presented here that I vow to use going forward.

• I’ll use Le Châtelier’s principle next time I speak with teams and leaders about organisational impediments.
• Talk about the 12 stages of burnout in one of our internal talks to raise awareness.
• Use Darren’s search dog case as an example for agile in non-software environments.
• Discuss robustness vs. resilience with teams that want to use devOps in my work as an agile coach but also in larger transformations.
• I will try the working out loud from HackIT in my next internal initiative to test it.
• Diversity has been important to me, but now my conversations will certainly move from being purely about fairness to include the improved problem solving capacity.
• I will try to use a success bell like Julian used in his information radiators.
• Control vs. competency will certainly be used in my next agile coaching session with a specific organisation I am working with currently.

That’s quite a lot - let’s see if I can do it. In any case, I am looking forward to the next Agile in the City, continue my journey for understanding and hope to meet more great people.