patkua@work

The intersection of technology and leadership

Page 25 of 53

Performance is Emergent Behaviour

Mark’s tweets got me thinking when I tweeted a short number of responses back at him recetly. Unfortunately twitter isn’t a great place to have a long and well thought conversation and figured I would blog about it like Mark did.

The gist of the conversation seem to float around two positions that seem to be in conflict.

One position states: someone’s behaviour is determined by their environment (or system). This is certainly the view that John Seddon writes about a lot in his book, Freedom from Command and Control.

Most people read this position and (incorrectly) deduce, someone’s behaviour is solely determined by their environment (or system) therefore, it is best to focus on one of them.

Mark makes a great observation that people perform “differently” given they have the same environment. In an environment, sometimes those “differences” may be “better”.

To which I responded in the brevity required by 140 characters, “different strengths and interests at play. Emergent behaviour based on individual and environment.”

Emergent behaviour in this case can be seen as much more than just strengths and interests at play. People are complex systems and highly unpredictable. Each individual goes through many different experiences. Just as an example, everyone’s commute around London is different. Train failure? Tube strike? Traffic on the street? Walking to work? Everyone has different social structures – sleep deprivation from young kids, happiness from a child’s graduation, hard night out celebrating a friend’s send off. Even the weather has a huge impact on people (though everyone responds differently).

It’s rare that I think we are all in the “same” environment all the time.

Add in the topics you’re currently interested in, the events unfolding around you and regardless of the system, and the skills, strengths at play and ambitions, I hope you start to understand why everyone behaves differently. Of course some of those elements in the system have minor impact on the end result yet might explain why some perform “better” (i.e. differently) to others.

Thoughts On Øredev

Last week Sweden’s Malmö hosted Øredev for the sixth time. I believe it attracted more than 1400 people, all with varying backgrounds and interests. Unsurprisingly, the majority of attendees turned out to be Swedish and Danish people (with Malmö very well connected to Denmark via their famous Baltic Ocean crossing train).

The Cultural Experiences
Being held in Sweden, the organising committee did well to treat us to some cultural delights including the Swedish sauna-Baltic Ocean run followed up by a delicious traditional fish meal). One of the organising members even welcomed us into their home for drinks before the speakers’ dinner where Glögg continued to keep the cold at bay. The difference of soaking raisins and almonds really surprised me. Malmö’s deputy mayor then welcomed us at their majestic townhall where all the speakers unanimously marvelled at the decadent surroundings. The meal stayed true to the region with first, a regional speciality, black soup (and yes, like black pudding, it has a very special ingredient) before following that up with a hearty roast goose meal and a spiced apple pudding for dessert.

Logistics and Organisation
The organisers impressed me with how smoothly the entire conference ran. Malmö’s Slagthuset (slaughterhouse) hosted the conference for the first time and although not all the spaces turned out ideal (with small walkways between some major rooms), I think it contributed to the friendliness and openness I discovered.

The organisers also did a fabulous job responding to attendee’s needs. For example, on Monday they moved a number of tutorials to warmer rooms after realising the strong draughts let in by workmen who still needed to complete their work. Another example is when they quickly disabled the authentication on the wi-fi when it proved to be another barrier to being connected. Unfortunately the wi-fi turned out to be a little bit flakier throughout the conference.

I also really enjoyed the evening entertainment that flowed into the venue rather than the “move to another location and lose people” approach several other conferences do. This helped to keep the conversation flowing (and we all love our flow!).

Topics
Øredev offered a huge variety of interesting topics with tracks covering mainstream languages such as Java/.Net, NoSQL, Agile & Lean, Collaboration, Patterns, Smart Phones and Architecture with lots of really interesting topics. I’d keep an eye out for their website and trawl the twitterverse (#oredev) for the interesting discussions.

The keynote presenters also turned out really well.

Dr Jeffrey Norris presented what he thought as agile values leading to mission critical success at NASA (Vision, Risk and Commitment) demonstrating through a “wow” 3D demonstration using the ARToolKit. He used the stories of famous inventors, particularly the rise of Graham Alexander Bell to emphasis these elements very effectively.

I saw John Seddon a few months ago and although I’d heard him present pretty much the same talk, appreciated his message was an important one that more people really needed to hear. I think there is great value in spreading his emphasis on holistic system thinking even further in the work that we do. Entertaining and very British, Seddon completed his keynote without leaning on any slides and to a very positive reaction from the audience.

I missed Henrik Kniberg‘s keynote so can’t really comment.

The final keynote came from Atari Corporation geek legend Nolan Bushnell envisaging what the next key software projects would be in the future. I think everyone enjoyed the talk simply because it was Nolan though I think wasn’t as executed as professionally as it could have been.

People to meet
One of the really great parts of Øredev was all the people around you. As one person put it, you could be talking to a person and then suddenly realise that they created X (where X = language, framework, tool, etc) or someone who wrote a lot of the blog entries that you’ve been reading. I think that the conference does a wonderful job of creating a really relaxed atmosphere for people to converse and the speakers are all really approachable and involved in all of the sessions as well.

I have to admit I also really appreciated the opportunities to connect to a number of fellow ThoughtWorks colleagues (both past and present) who I’d either not got a chance to meet, or hadn’t seen for a very long time. This is one of the consequences of working for a global consultancy – you get to communicate and build relationships for a distance yet rarely get to meet people face to face.

iPad observations
One huge point worth noting was the large role that the iPad played during this developer conference. Obviously, being fairly geeky I hadn’t expected so many of them yet it proved to be one of the best devices for capturing notes & particularly useful for reading and contributing tweets. Laptops lose out on both portability and, on average, a very so-so battery life.

Reading tweets to view session using the native iPad twitter client also worked really well without having to use the keyboard or mouse – this is where gestures and multi touch really shined.

My session
Chris Hedgate, organiser for the track on collaboration invited me to speak. Titled, “Tightening the Feedback Loop“, I spoke about how to give and receive more effective interpersonal feedback. I had some great tweets in response and some great feedback on the presentation (meta!) I’m encouraged that more people will be better equipped in their professional and personal life after attending.

Conclusion
I highly recommend presenting and/or attending Oredev. You’ll meet a whole heap of really interesting people and, no doubt, come away with at least an idea or two.

Upcoming Speaking Engagements

I’ve been terribly busy the last couple of months and it reflects by the lack of any blog posts. So sorry for that. Here’s a short post talking about upcoming speaking engagements.

My first one is for the Collaboration Track at Orevdev in Malmo next week. Titled, “Tightening the Feedback Loop”, I’ll be exploring how interpersonal feedback can be so much more effective. The programme for Oredev looks amazing so I look forward to contributing and participating in the conference.

The second speaking engagement is for the Skills Matter Agile, Lean & Kanban Exchange talking on their “Leadership, Value and Visibility Track”. I’ll be covering, “Making ‘Management’ Work with Agile.

John Seddon Keynote

As part of our closing keynote, English based systems thinker and well known author, John Seddon presented his keynote. Interestingly, like many speakers these days, Seddon presented with zero slides and talked about the application of systems thinking and the work that he did.

Having been a speaker with plenty of experience, he definitely came across with plenty of confidence, timing his witty remarks perfectly. Backing them up with personal stories about their success and simple things that others could relate to, I think he definitely hit the mark as a keynote speaker getting more people to think and applying systems thinking to the work that we do.

For a number of us already interested in this field of study and almost active application, I think we were simply glad to hear about how someone has been so successful in its application. This is particularly important around its pragmatic application.

His talk reinforced the importance of helping people see the system for themselves, rather than trying to fix the problems for them and how that will lead to longer lasting results. His talk also highlighted that the work that we do in an agile world isn’t always the best place to focus our efforts because we don’t really want to be delivering the wrong thing faster. Whilst I think many practitioners realise this in the agile community, those with less experience or those simply looking to make money out of a value set do not – and something more people need to understand as it’s adoption grows larger.

Finally as much of a friendly and well opinionated man as Seddon is, he is clear where he stands with the term lean, frequently used in his vocabulary in a derogatory sense. I found this point particularly interesting because my experience, and the ideas espoused by other lean followers in the software community harks back to the value and mindset of lean, rather than the tool junkies and commercial lean people Seddon seems to associate the term with. For me it was an important reminder to validate other people’s association and anchors with words before moving towards more fruitful conversations.

I’d definitely recommend Seddon as a speaker and at least the book I read, Freedom from Command and Control.

Away Day Weekend

Two weekends ago we had our UK office annual away day. These events let us, as a group, get together and share ideas, reconnect with old faces and establish new ties with new ones. This year, we held our event at Centreparcs Elveden Forest that turned out to be a really nice venue for all of the sessions.

I attended plenty of interesting sessions including Liz Douglass’ session on building Android applications, the new Operating Model of the company presented by Stephen Forshew and a great back to basics but see them fly Refactoring session put on by Pete Gillard Moss.

I also presented alongside my colleagues, Luca and Frankie on the application we built for the iPad competition (something I’ll post about when we get our application live). In the meantime watch this space since we managed to win the competition based on the crucial judgement and critical feedback from our UK based peers.

Like most of these events I came away recharged and drained at the same time.

Freedom from Command and Control

We’re fortunate to be having John Seddon keynote at our internal conference in a few weeks so I wanted to read some of his material in advance. I bought the Freedom From Command and Control book out of interest to see how he applied systems thinking to the service industry.

Depending on what your background reading has been, it may or may not be heavy going. I really appreciated the background I’d done in reading about lean thinking, systems thinking and other respects so I found most of my interest seeing how he viewed the application of these tools, rather than the description of the tools themselves.

Despite some warnings from a number of people, I found the book easy to digest – made all the more entertaining by the repetitive (in a good way) and controversial statements thrown in the book. I figure Seddon wrote them in to intentionally jar your traditional manager into thinking differently.

My biggest takeaways follow:

Stop creating failure demand – Lean thinking looks towards the end-to-end flow of value – starting from customer demand. Seddon articulates on focusing on the idea of shaping the demand and service organisations often get to choose what sort of demand they have (to a degree). More often than not, organisations instead flex their capacity to meet all demand – not really spending the time to think about whether or the demand they have is what they want or not.

For me, this links into another view such that organisations need to address bigger root causes, improving quality and experience for customers to stop generating failure demand. I see these ideas equally apply in a software context – many of the practices we adopt is intended to build quality in from the start so the development effort can be focused on helping the flow of business ideas, rather than spending time on fixing “defects” for customers that should not have reached them in the first place. Similarly, properly addressing user experience early enough will help to prevent failure demand.

Reaffirmation that arbitrary targets are bad – Seddon isn’t fearful to state his view around the idea that setting targets are bad – in that, you get what you measure and the targets are often not really related to the purpose of the system. This seems to sit well with the discoveries of the Beyond Budgeting Movement who’ve realised you cannot use the same instruments for measurement, planning and setting goals (decouple them!)

I found interestingly Seddon still explain to people the importance of measurement, just not arbitrary ones that managemet set and then create systems around.

Using Capability Charts to map demands – Seddon describes the capability chart as a way to visualise the way demand is being generated. Its focus on visualisation is a way of helping people to see natural fluctuations in a system and a way of identified trends not easily seen when boiled down to a matrix of numbers.

Powers of Why

Although I can’t say I’ve been part of many other methodology movements as closely, one of the greatest things I appreciate about the agile community is to explain why things work the way they do.

Back at university, when I remember RUP being taught, none of the books or the leaders of the community explained why they suggested you do things, other than, “This is how you do it.”

I’ll admit that as more and more people call themselves “Agile”, a key characteristic for the community leaders and many of its respected participants is their deep understanding for why we do things. Great examples of this is the community’s willingness to continually question practices adding value and exploring new practices to add more value. Evolutions of TDD to BDD, the introduction of explicit limits for Work in Progress, and levels of automated testing to bring feedback early as possible.

Another great example of this cultural phenomenon is the community’s willingness to explain how situations arise. The most recent example was Rachel Davies explanation of the Gordon Pask award, but stretches as far back as to the origins of the Agile Manifesto written by signatories such as Martin Fowler, Dave Thomas and Uncle Bob Martin.

It’s easy to criticise situations when they don’t work or when you dislike something, yet I think we need to appreciate those willing to not only try new things, but help others understand why they tried those new things. Understanding the intent behind actions lets others attempt new ways of achieving the same goal given the same, or even different circumstances.

Just one more thing

As a developer, there’s a tension between doing things consistently and knowing when to make change. Consistency generally means it’s easier to understand – there’s only one pattern for people to learn and then the next time they see something like it they have a pretty good guess at how it’s going to work.

People also generally learn by copying – and therein lies the problem for inexperienced developers. They look at what’s there, figure it’s better to follow the established pattern and then to add just one more thing. Generally it doesn’t really matter what it is – another branch to a if statement, another parameter to a method, another function to class, or another (ugh!) static call.

Responsible, experienced developers know where the inflection point is – where the right thing to do is to refactor the code, and to avoid adding just one more thing.

« Older posts Newer posts »

© 2024 patkua@work

Theme by Anders NorenUp ↑