patkua@work

The intersection of technology and leadership

Page 22 of 53

Linda Rising’s “Who Do You Trust” Talk

June 3, 2011 / / 1 Comment

On the Monday just gone, I attended Linda Rising’s talk held at the very nice Immobilien Scout 24’s office in Berlin. This isn’t the first time Linda has presented this topic, however it’s a powerful message worth spreading further. More than that, it’s just great just listening to how Linda presents and interacts with her audience.

This talk focused on the in-built prejudices we all have. Having most recently been reading about our in built cognitive biases for one of my earlier talks this year, I was very interested in hearing some of the stories Linda had to tell. Her opening slide with the opening doors to the Museum of Tolerance showing the options you have for entering (see the inline photo).

She also used a lot of great stories based on real life research, talking about the way that we naturally fall into groups and the language that we used being one indication of the strength, such as “them” and “us”. She presented about the Robber’s Cave Experiment by Muzafer Sherif. She presented the Solomon Asch experiments that described how we conform to peer pressure although all you need is one opposite vocal opinion to break the effect (this one helped me understand why blind planning poker can be powerfully effective).

Her description about the way that we stereotyping also having further effects, with the example of studies that demonstrate that simply reminding people of their gender at the beginning of a maths test significantly alters the outcome. Fortunately these things can be put to good use, such as the way that Norm Kerth’s Retrospective Prime Directive helps to reframe meetings.

It was a really great session and for those interested, you can watch this (though I recommend seeing her in real life) here.

Testing Pattern: Exploratory API via the Web

May 30, 2011 / / 2 Comments

Last year I was working with Tiest, a former colleague of mine at a bank working on a system with an internal API. It was quite an experience, though I will save that for another (set of?) blog posts for another time. The application was centrally hosted with a client API that allowed people to interact with the server side. The testers needed something to help them do more exploratory testing and my former colleague came up with a great solution to this problem that I thought would be worth recording here for posterity.

Our solution had these characteristics:

  • Provided through a web browser – Installing items onto the testers machines became a bit laborious, namely because they didn’t have rights to install, change or run anything with administrator privileges. It was easier to deploy the tool centrally, and then let the testers prod from afar. This was as simple as writing a page that submitted some code to a web server, that than executed it and returned the results back to the client.
  • Supported dynamic execution – We could have written a web layer on top of the client API but we didn’t really want to add another layer for maintenance. We simply used the javax.script package to turn our standard POJOs into a scriptable/dynamically invokable system.
  • Built in reflection functions – Using the scripting interface meant that the server would not store any state. So the server had a number of built in functions such as a listAll(object) that would show all available property/methods to the user
  • Example queries stored on a wiki – When a tester would ask for something to be checked against the test environment, I would convert it into an appropriate query they could paste into the query browser window. They could then execute it, tweaking parameters, etc and learn to compose things. They didn’t have to really understand how java (as script) worked, just build on what was there.

Although I won’t be reaching into my testing patterns toolkit for this pattern too often, I feel it worked well to enable our non-technical testers to get at something given a number of environmental constraints.

We’re not trying to be rude, honest!

May 29, 2011 / / 4 Comments

I got included in on a twitter conversation by Mark responding to Brian talking about how ThoughtWorks people at a particular conference huddled around together. It’s not the first time people have observed that. A natural reaction by people outside of that circle is to comment on this, such as, “You’re not very inclusive,” or “Crowding around together is so rude.” Having been part of these circles before, and being told this judgement (with accompanying observation), I can tell you where it stems from.

ThoughtWorks is a distributed company
Though I can only observe consultants I interact with from other companies, I feel ours is definitely very global. We encourage people to travel from one country to another, frequently rotating projects and encourage each other to present at conferences. Being located pretty much all around the world, it’s natural you don’t get to meet everyone face to face. Even here in London, I am now used to turning up for a new office event only to meet several new people. We work on different projects, so it’s natural not to meet anyone.

Our electronic-social ties are extremely strong
Internally we have, at least what I like to think of as a very active mailing list. When I post something on there, I generally get some pretty good responses particularly from the largest community of software developers. Over time, you get to know someone’s online persona. You have a picture of them in your head, and start to see the nuances of how they express themselves. Even things like twitter help to do this. It’s not uncommon for me to feel more strongly attached to people actively participating in email conversations than some people in the same office of who I rarely see or talk to.

Conferences are attended by ThoughtWorkers from around the world
As I briefly touched upon before, as a global company we try to encourage people to travel and present at conferences. This naturally leads to opportunities for people to meet in person for the first time. It’s strange meeting people you feel like you’ve known for a long time in person for the first time. I still remember, for example, my first day in the London office where I finally met Liz Keogh and Tim Emiola for the first time after conversing with them electronically for 18 months before hand, and them now inducting me into the whole Britishness of “buying rounds” and the way that it all eventually works out.

People have a need for connectedness and belonging
Having just recently talked about it at the XP2011 conference, I noticed that we weren’t the only people to congregate into small circles. For instance, I remember a whole bunch of people from Brazil hanging around together for almost the entire conference. Likewise for a small group of people who worked for the same company in Sweden. It’s a natural thing, particularly in new environments, for people to stay close to those they already have relationships with.

It’s less about you than you think
It is all of these effects combined that lead to ThoughtWorkers aggregating at events. Perhaps it’s also because we tend to be quite loud/opinionated/noisy that it’s more noticeably. Gravitating towards each other isn’t a conscious act trying to exclude everyone. In fact, I know ThoughtWorkers like hearing other opinions, particularly if they’re even more different and based on strong experiences and though happy to contribute to conversation will be welcomed with open arms.

We can get better at this
I know it can be hard approaching a loud, opinionated group of people. I know we can do it better. Being aware of how we’re sometimes perceived, this is how I go about trying to break the perception:

  • Invite others in – If I know someone standing at the edge of a group, I’ll introduce them and explain my relationship to them to others. It helps break the awkwardness and creates more opportunities for everyone to talk about similar interests.
  • Randomly break away – If groups get too large, or hang around too long, I like to break away and meet some new people. I also try to encourage other people to do the same. It’s not only a good way of getting different perspectives, but helps address some of the above issues.
  • Explain to others the contributing factors and perceived effects – By talking people through the above elements, it helps others understand why perceptions come up the way they do. More importantly it lets them decide how they’d like to deal with it

Whilst I can only speak for myself, I do hope that other people can benefit from this by being more inclusive where possible in these sorts of situations.

Book Review: Quality Software Management: Systems Thinking

May 17, 2011 / / 1 Comment

I’ve been interested in Systems Thinking explicitly for the last two or three years. I haven’t had many good books I could recommend to anyone other than “The Fifth Discipline.” Last year, I inherited a wealth of Jerry Weinberg books from fellow geek, Romilly Cocking and just got around to digesting a very classic book, Quality Software Management: Systems Thinking. Weinberg, whether or not you know it, has had a huge effect on our industry. He has written many books on wide ranging topics, and being a participant/organiser of the Amplify Your Effectiveness (AYE) conference continues to influence many leaders.

Anyway, back to the book.

Hard cover books are always a lot more intimidating than their soft covered brethren. Perhaps it’s the sheer bulky that does it. Fortunately the text is rather large and with only about 280 pages of content, easily consumed on a number of continental flights between the “no-electronic gadgets” zone.

I’ll admit that describing Systems Thinking is hard. Walking through, what Weinberg calls, Diagrams of Effects are intuitive when he explains them step by step, however I find it hard to describe the process and never have been very confident in some of the ones that I have used.

The Mechanics of Systems Thinking Diagrams
One tip that Weinberg talks about is thinking about the things in the boxes as things that you could measure (or you do measure) and their relationship between each other. Giving the item in a circle a name has been a challenge for me, and Weinberg presents a heuristic I feel I can make better use of.

Unlike models I’ve seen from places like Soft Systems Dynamics, Weinberg doesn’t use a plus or a minus, and maybe you’ll find his notations work for you. I can’t say they worked or didn’t exactly work for me. I did appreciate the different take on making the secondary, or implicit loops more explicit by attaching repeating loops to the lines they amplify, rather than to the entity they end up with.

In other Systems Thinking Diagrams, people sometimes note a delayed effect, something I was surprised didn’t really turn up in the book to a great deal. I don’t know whether or not this was intentional or not. A new difference I learned though was putting on another notation for diagramming where managerial decision/input affects the Systems Diagram. The way that Weinberg wrote about using this brought a little bit more of a humane aspect to it.

Repeating the role of Mental Models
In the Fifth Discipline, I didn’t really understand the importance of Mental Models related to the point of the Learning Organisation. After chatting to Mark Needham recently on the way that people interpret different things, and seeing how crucial this was to interpreting and drawing Systems Thinking Diagrams in Weinberg’s books, I better understand why these two things cannot be detached. In fact, it was very timely with the question that XP2011 keynote, Esther Derby kept asking, “In what world would this make sense?” to see things from a different Mental Model.

Weinberg tells a really good story about how these Mental Models effect the observation. He recalls a story talking to a manager who’s managed to work out how to distinguish good programmers from the bad ones. The manager starts talking about how he’s noticed how some programmers talk a lot to end users, or to other programmers. A grinning Weinberg, nodding at the manager’s observation slowly stops as he comes to realise how the manager don’t think of these inquisitive, communicative programmer’s as the better ones, unlike what Weinberg (and maybe you and I were thinking). Same observations, different interpretation.

Reconfirmation of in built human biases
We are full of biases that we aren’t even aware of. Many of Weinberg’s anecdotes remind me of some in particular. For example, he talks about how managers running projects that continue to fail, blame it on “bad luck”, or “something out of their control”, whilst taking personal credit for those that do succeed. This is a really good example of the Fundamental Attribution Error.

Things that didn’t work for me
Throughout the book, Weinberg refers to Pattern 1 and Pattern 2 type organisations. Even though he explained them early on in the book, I found it difficult to anchor any real meaning to them by the time I’d finished the book. I would have liked to have seen him give them better names and use them throughout. It’s a minor detail, however I did notice this slowing down my reading.

Summary
I’d recommend this, still highly relevant, book to people involved in IT today. Though it’s published in the early 90s, I’m surprised at how many of the stories are still relevant. It not only explains the basics of thinking with systems using models anyone can relate to. It also explains those systems diagrams that apply to the software problems of today.

Summary of XP2011

May 16, 2011 / / 5 Comments

First full day of XP2011 was a pretty full schedule as I had to prepare for two lightning talks on different subjects. Fortunately both of the topics were very close to my heart, one about learning using the Dreyfus Model (slides) and the other about Systems Thinking (slides). The second day started off with a great breakfast selection at the conference hotel before kicking into the keynote by Esther Derby. Clearly jetlagged, Derby used a set of hand drawn slides to explain her topic, “No Silver Bullets”.

Her presentation style was very conversational and I can’t say that the crowd responded very well to this. Perhaps it was their jetlag as well, or the way the room had been set up. Nevertheless, through many of her stories, I still saw many heads nodding and a really great response on twitter to the things that she was saying.

I’ve followed Derby’s writing for years and could only wish more people would be exposed to them. As a result, I found many of the topics and opinions I found interesting reinforced, such as failing to address the management layer inevitably means agile adoption hits a hard ceiling. Or the oscillating behaviour that results when managers attempt to react to a system with long delays in its feedback cycle. I appreciated the very vivid term, “Bang! Bang!”-management style describing the style of managers who seem to have only two distinct and opposing reactions to a system, unable to moderate their use and wait for systems to find a new equilibrium. If you imagine these two opposing reactions the result of a huge iron lever being flipped, hopefully you can imagine where the noise comes from.

Derby covered lots of different areas, quoting a few people like Donella H Meadows, “The original purpose of hierarchies was to serve the sub systems, not the other way around.” And the work that George Lakoff does with word association with metaphors in our everyday use. Raising self awareness of your own in built biases and metaphors is another key thing she emphasised focusing on the judgements, habits, feelings, thoughts, mental models, beliefs, rules and values we tend to be intrinsically governed by. I particularly liked the phrase she uses to help people uncover their own and others’ mental models, “In what world would this make sense?”

She told one great story about the dangers of measurements as targets, using the example of the manager who decided to “Grade developer estimates”. This manager decided to give A’s to those who estimated on time, B’s to those who estimated over time, and C’s to those who estimated under time. Of course, you can imagine what magically happened as people’s grades mysteriously improved.

She also reminded me of the work of Ackoff, who I need to revisit, and the great work that he’s written about Systems Thinking. I have only been able to refer to the Fifth Discipline as a Systems Thinking book, but I really need to read his other ones to see if they would be of use, or are more accessible.

The rest of the day was a bit of a blur. A couple of highlights included seeing Marcus Ahnve take the work Luca Grulla and Brian Blignaut did with TDDing javascript to the next level and doing a demo of BDD.

David J. Anderson also reminded me of the importance to think in terms of the languages executives speak in order to better get our message across. He reminded me of all the great things that Ross Pettit has to say, although I think Anderson’s analysis on accounting for software development costs doesn’t seem to match with some of the data I’ve heard from Pettit.

There was so much more to the conference. Always the way great conversations emerged and the wonderful atmosphere of the hotel adding to the uniqueness to this event.

What’s in your coaching backpack?

May 13, 2011 / / 0 Comments

This morning I facilitated a coaching workshop at XP2011 called, “What’s in your coaching backpack?” It was a four hour workshop, so lots of time to go into detail. I designed this workshop to focus more on depth than breadth for the four hours. After some introductions to the purpose and format of the workshop, I got everyone to move into groups and spend some time introducing themselves to each other. In these groups, we spent some time focusing on brainstorming various coaching tools, models and techniques and we came up with a huge variety. I’ll get around to writing each one of these up (there’s quite a lot of detail) so look out for them in future blog posts. Our coaching backpacks are now much fuller than what they were before.

After a break, we then reconvened and I asked people to focus on some case studies of some coaching situations where, in their groups, using the coaching tools to articulate how they’d approach each situation. There were some really great conversations and discussions, where I hope people got a better feeling trying to see how others might apply different techniques to the situation. Having been grounded in real world experience, people also wanted to know what did happen (even though there aren’t any correct answers to case studies).

I also had a quite mini retrospective, asking the questions, “What you enjoyed about the session?” and “Suggestions for improvement?” I had some great feedback and wanted to put it on line:

  • Like – Practices and real examples, discussion and division to groups, Scrum board or presentation agenda
  • Great format, loved the taskboard, posting on wall “backpacks”, case studies
  • Good group size, great group
  • Really well facilitated
  • Interesting content generated by the open conversations
  • Sitting in the sun was AWESOME!
  • Great opportunity to discuss different approaches to coaching and agile
  • Like the idea of showing progress of the workshop at the scrum board using tasks
  • Case studies/real life examples always interesting
  • Good, clear setup with backlog
  • This was the session I got more out for my work/myself than any other session 🙂
  • The workshop format
  • Working in small teams, all adding different perspectives
  • Sun
  • Nice with practices and your communications
  • Your excellent preparation and light-weight facilitation
  • Small groups
  • Interesting case studies
  • Exchange of ideas
  • Case study
  • Very well organised and structured
  • Good atmosphere, positive energy
  • The case study discussions
  • Living whiteboard agenda
  • Maybe switching up the teams between case studies might reduce effect of powerful personalities
  • Rotate members in tables to get more ideas?
  • Suggest you split groups with the knowledge spread more evenly – you asked experience and could have used that info
  • Same team all he time. Maybe we could have shuffled people in the middle of the session
  • Changing teams after a while (e.g. at lunchtime if in for whole day)
  • I could even have a whole day of doing this without being bored
  • More practises and making the descriptions of “methods” out from this
  • Produce example tool(s)
  • Put all coaches tool/methods together and have a global short discussion
  • Common discussion about the good practices
  • Would have liked to hear/learn more about coaching techniques
  • Would have been nice with an introduction to the methods/worksheet part to get the flowing associations
  • A conclusions panel to write the achieved results

Notes from Michael Feathers’ Brutal Refactoring

May 11, 2011 / / 4 Comments

Here’s my notes from the four hour workshop by Michael Feathers on Brutal Refactoring. I’m trading off timely information for something that probably could be more succinct or polished with a bit more time.

Michael opened with the discussion on what is Clean Code versus Understandable Code, and why each is important. He makes the point, using some good examples from different languages, we can live with understandable code, and there is a cost to having Clean Code, particularly when you have it. He explained it through good relationship with Behavioural Economics, taking about how the incentives for people maybe aren’t quite set up right.

He asked a question, “Is it easier for people to add code to existing place than to create a new method/class/etc? Why?” It’s a good analogy, and something that you even seasoned, diligent programmers often fall foul when working in small increments.

There were some further good discussions about “Understandable” being contextual. Such as, a C++ macro might seem “magic” to non C++ users, but could be quite familiar. This remind me of the learning curve, my former colleague Dan North is going through with Rails at the moment. A nice reflection on some messages I talk about in my “Beginner’s Mind” talk.

Anyway, back to the tutorial. Feathers says, “We should’t be surprised by very large methods. incentives are set up wrongly. Though not sure what we can do about it.” He further acknowledged it wasn’t a “bad coder’s” action, but a systemic effect, “It’s the result of the system between us and the code.” I think this is quite important to note because I think the social system that software development occurs in is important as to what code you get up. For example, when you build teams, having an agreed code standard and consistent technical direction is essential into setting up a different system that incentivises different behaviour. If you know you’ll need to come back to something, and change it, you’ll want to leave it in a good state. If you want the respect of your peers, you’ll want to leave it in a good state.

Feathers then talked about some great visualisations he’s been working on. He’d get on great with many of my colleagues, particularly Erik Dörnenburg who loves to champion this sort of stuff. I agree when Feathers says, “Code has a particular shape,” when you’re looking at a particular system.

Feathers than covered a good deal of stuff as shown in the Mind Map. I have some rough notes.

Feature Clustering

  • Listing out features and looking for commonality. Sometimes you look for common arguments across classes/methods. Sometimes it’s about common data (Data Clumps as Fowler talks about in his book).
  • Look for Locality of information (or encapsulation in OO talk)

Rapid Scratch Refactoring

  • A bit of regret not focusing more of it in his book.
  • You learn a lot my attempting stuff out and then seeing, “What could be?”
  • Some discussions on the danger of making these too much of a big leap and never reaching for it. (Just another reinforcement about clear vision and essential leadership to keep people heading in the right direction”
  • I found it interesting he liked to do it in a plain text editor instead of an IDE. Feathers talked about the distractions of syntax highlighting. I find that I learn a lot more information (and can try things out faster with an IDE like IntelliJ or Resharper)

Twisting Classes

  • Breaking down a class based on use rather than adding more
  • Step by step process of creating a new role (via interface or superclass and using that in a consumer rather than the original)
  • Feathers recommends a very riguourous command query separation

There’s lots of other small gems included. Some notable tweets worth saving:

  • “Branches often biggest impediment to refactoring in large orgs.”
  • “Narrowing scopes: often we gain leverage by moving temporary variables coser to their points of first use”

Learning a new language

April 29, 2011 / / 2 Comments

I took a week off my current project to take part in intensive German lessons. I figured having some full time theory would help round out what I’ve learned from audio guides since working in Berlin, and it’s a good opportunity to do it whilst still in Germany. In talking about “The Beginner’s Mind“, I thought I’d share how I’ve been applying these to what I’ve been doing.

Recognising I’m still a Novice
In his book, Outliers, Malcolm Gladwell talks about experts requiring this magic “10,000” hour number. I’m well far from that. Models that describe how we learn, such as the Dreyfus Model of Skills Acquisition, point out different levels requiring a different environment to further your skills.

For example, if I could speak German fluently, I would want to further hone my skills my taking part in public speaking classes such as Toastmasters or reading a book on philosophy, in German. I’m well far from that.

As a novice, I need to build a base vocabulary. I need strict rules on how sentences are (generally) formed and lots and lots of practice.

Drinking from a firehose, one mouthful at a time
When you know you don’t know everything, it’s tempting to want to take in everything. I see someone in my class writing down everything, asking about complex sentences and all the variant manners of how to say something (German is full of these!) For me, I recognise it’s just too much at a time. Learning occurs through repetition, growing a wide base, and at the same time, building on top of what you already know.

Knowing when to say enough is enough is the key to not simply being overwhelmed.

Building stronger knowledge networks
The prerequisite for building knowledge is first having a wide enough vocabulary set. This means simply getting more words and experience under your belt. As I’m growing this set, I’m searching for links between words, trying to find patterns or relationships between words. I think it’s working out relatively well with the limited set that I have, though I know that if I can find ways to remember these, it’ll be easier to remember them later.

Long Feedback Loops

April 29, 2011 / / 0 Comments

Almost five and a half years ago, one my first project in the UK, I built a constrained email tempting engine to be used by marketing folk with a small team of three other developers. I think we worked for about six to eight weeks to develop the entire application, including retrofitting its integrate its output with another system.

A year or two ago, we had some consultants return to the client who talked to one of the original developers who still worked for the same client. They spoke fondly of the good times he had on our team, and spoke proudly about the application we wrote. In the four years or so of constant use (they would revisit their emails at least once a month), the users apparently only ever reported one bug. He mentioned that bug (a special character in the email subject line) was also deprioritised from the original work we did. It was an enough fix and with test around it, was not a problem updating the system.

I certainly appreciated the feedback, particularly since you don’t always get to return to see the long term results of the work you do as a consultant, or even just as a developer.

Some of the great things I learned from that project.

Acceptance Test Driven Development is entirely possible
We worked hard to test drive this Swing based application from the start. It really changed the way that we designed the application and all of us learned a whole heap about understanding testable presentation patterns. It formed the basis of several talks and the knowledge, particularly the separation of concerns is entirely applicable to all sorts of other tools and interfaces such as javascript, or command line interfaces.

On a different note, coverage combining end to end acceptance test and unit tests meant we had 100% code coverage. It was never the goal, but interesting to see on this application it was entirely possible.

Never discourage people from trying new things
The organisation was rife with contractors. Not all of them entirely passionate. I love building great teams and the fact that everyone was learning, and saw things being delivered reignited people’s passions to do various things. I distinctly remember two events made possible by encouraging people to explore their passions and strengths.

One of the developers, interested in the User Experience side asked if he could do some user testing with the application. I can’t remember exactly what I said, but certainly encouraged him to do that. He did, what some people call Guerilla Usability Testing – grabbing someone who didn’t know anything about our application, and giving them a task list to complete as he watched them over the shoulder. Based on this study, we found out, to no surprise, the way we laid out the application didn’t make some of the tasks as easy as they could have been. We channeled this feedback into our interface and helped make life easier for its users.

The other event, a contractor, seemed to find his passion for developing usable software reignited. Everyone will know that swing applications aren’t the nicest things to look at. I remember coming in one morning to find that whole interface reskinned and redeveloped. It looked a whole load better than what you’d get with swing out of the box.

I found out much later that he had, by his own volition, worked a couple of extra hours one night because he wanted to add that extra polish and make the interface attractive to users. Awesome stuff that would never have happened without encouragement to do “the right thing”.

Involving real users
As a systems thinker, I know that the purpose of the project should have been an intermediate step. The real problem the organisation was a missing feedback loop from IT back into marketing. I knew that then, and I know that know, however being pragmatic and realistic, you can only do good things within your own sphere of influence. Trying to change how the entire marketing and IT department silos worked (or failed to work together) would take much more than the two or three months I was going to be there.

Fortunately, we had one person on our project who had worked for their company for a while and had a couple of good contacts in marketing. Whilst we couldn’t change the way projects spun up, we managed to get someone who was going to use our software down, early, and show them what we were building for them. More than that, they asked for somethings (that we could almost immediately turn around for them) and they were blown away that their feedback actually mattered and made a difference.

Conclusion
I appreciate good projects, and where possible, create those environments for others to thrive in. There are many good things to carry forward in these things and can only hope others benefit from it as well.

« Older posts Newer posts »

© 2024 patkua@work

Theme by Anders Noren — Up ↑