Skip to content

Registration open for CITCON North America

CITCON North America 2015 will be held in Ann Arbor Michigan on October 2nd & 3rd. Registration opened today with a hard limit of 150 registrations.

Why a limit of 150 registrations? Our original inspiration was Dunbar’s number, and the idea that our prefrontal cortex puts a limit on the number of people we can model at one time. CITCON is a 100% Open Space conference, and the quality of the event comes from the interaction between attendees. I’ve blogged previously that I believe selection bias is a significant factor in making these interactions successful, and I believe the small size helps as well. After the Friday night opening ceremonies, agenda creation, and social hour, you really do know at least a little bit about every attendee. I believe that helps people engage in the conversations on Saturday, and helps ensure we have good outcomes in most sessions.

If you’re not familiar with the Open Space format and aren’t sure it is for you we have several resources that can offer some reassurance. First there’s a neat introductory video that was put together at CITCON Europe 2009 in Paris. Next, for some examples of what the sessions are actually like, you can visit the Skills Matter website, where they have videos of five of the sessions from CITCON Europe 2011. Finally, and what for me would be most reassuring, is the feedback and notes from attendees from the events going back to 2006! Reading through those blog entries is like watching the evolution of industry on fast forward. Hope you can join us and add your entry to our list.

Using the two column case study

On March 25th the London Action Science Meetup held a session on Using the two column case study. In our previous session we introduced some of the fundamental ideas of Action Science, and then closed with an exercise based on the two-column case study. This time we started by creating our two-column cases, used them to identify our Skilled Incompetence, and tried to design more competent options.

Skilled Incompetence was Chris Argyris’s term for the effortless, automatic production of behaviors that led to outcomes other than what the actor desired. In the article of the same name he describes using the two-column case format to make the automatic behavior visible, so it could then be redesigned. Our group attempt was slightly different in that our goals were two fold:  first, we were helping each participant identify what alternatives they might have used, and second, we tried to identify what in those situations might act as a trigger for that automatic behavior. My theory is that identifying these contextual triggers will be helpful for “reprogramming” those automatic responses.

I won’t discuss the cases from our group discussion, but I can share three context that came up as troublesome:  disagreeing with a statement, having an uneasy feeling, and someone else trying to close off debate.

Our first context was a common one, so common that it seems innocuous: disagreement. Person A said X; person B disagrees with X. What could be simpler? The problem is that Person A and Person B might mean entirely different things by X! Consider the statement, “Yes, I’ve tested the changes in the new release.” What is meant by tested? Does that mean writing automated checks or performing manual testing? If automated, does it mean unit testing or acceptance checks or both? If manual testing, does it mean on a locally installed build, in the acceptance testing environment, or post-release in production? Or did this person do all those things and more? We could make assumptions — in fact we will almost certainly make assumptions! — but we can’t know we understand what was meant without asking. And so the first takeaway of the night was that if you disagree with someone you might first check to see if actually understand what they mean. Our re-designed statement: “You just made a statement that I think I disagree with, but I want to check I actually understand you and that we mean the same thing.” This is consistent with the mutual learning model in that we are open to learning that we are wrong and we are transparent in our reasons for asking for clarification.

The second context we discussed from our cases is having an uneasy feeling, but not having a concrete reason to justify your feeling that a proposed course of action is wrong. This can be an uncomfortable situation given that the values of the unilateral control model, our default way of behavior, include “act rationally” and “win, don’t lose”. From this unilateral control mindset sharing a feeling with nothing to back it up is a sign of weakness. But remember that our goal isn’t winning, it is mutual learning! From the mutual learning mindset sharing our feeling is consistent with sharing all relevant information. If nothing else, your conversational partner will learn how you are feeling, and can then make an informed choice how they want to proceed. Do they want to enquire into how you feel? Do they want to share some additional information they have which might reassure you? Do they want to share their own misgivings? As long as you are acting in good faith, not trying to use feelings as an insurmountable objection, we all agreed that sharing these feelings open the door to improved joint design.

The last context that came up from our cases was in some ways the most challenging:  how to respond when someone says “this is not open for discussion”? Once again we came back to the key distinction between Model I and Model II, which is the goal of controlling the outcome vs. the goal of learning. If I believe the decision that isn’t open for discussion is wrong, then from a Model I perspective I need to find a way to re-open the discussion, to have the decision reversed. But from a Model II perspective, I have the option to be curious, to seek to understand the decision rather than reopen the discussion. Going back to the Eight Behaviors I have the option of responding with something like, “I can accept that the decision is made, but I’d like to understand the reasoning. Can you share your reasoning and intent in making this decision?” With this strategy we can learn more about the interests of the person making the decision. Even better, if we are genuine in our curiosity, we just might learn something that would change our opinion!

Asking at the end of the meetup the group agreed this was a productive exercise. The two column case study format allowed us to identify areas where our communication wasn’t generating the outcomes we like. By discussing these situations with the group we were able to both come up with alternative behaviors and also to recognized the context that resulted in our original ineffective behavior. Our hope is that by continuing to practice in this way we will come to be more aware of our options and less skillfully incompetent.

To help with this process in our next meetup we will be introducing a new tool, The Ladder of Inference.

Why I Write

I’m on Day #2 of the 10 Days to a Better Blog online workshop and the assignment for today  is to meditate and write down the answer to your “why” in terms of your writing, and they even provided a nice template for the content that I’m happy to adopt as my own.

I’m beginning to define and explore the difficult question of why I write and why I want to become a better writer. Here are some of my initial and incomplete thoughts:

  • I aim to reduce suffering in the world of software development through improved practices and improved communication. I believe that the practices and mindsets that make a difference can be taught, and I believe that through writing down what I’ve learned I can reach a wider audience than I do through my working and speaking and meetup activities.

I feel that’s fairly complete. I’ve given a lot of thought over the years to my purpose, my mission, my Why. And thus in the Why | How | What scheme described by Simon Sinek, writing is a How, not a Why.

How to get better at writing? That’s something I’m still working on…

Excited about CITCON Europe 2015

I’m super excited about the upcoming CITCON Europe! As an organizer I’m thrilled with the strong response to the event. It is scheduled in Helsinki for September 11th and 12th and we already have 40 people registered, more than 25% of capacity in just a couple of weeks since we opened registration.

But as an attendee what I’m really excited about right now is who is registered.  When I look at that list of names I picture a lot of familiar faces, and I start to imagine a lot of conversations I’m looking forward to.

Ten years ago PJ sold me on the idea of holding an open space event by comparing it to standard conferences: “You know how the best conversations are the ones that happen in the hallways between sessions? With open space all the sessions are like hallway conversations.” Sounded good to me! And it has been in good in practice now for 25 separate events, on four separate continents. I think we have a case that there’s more than luck involved…

I think an important part of our success has been the selection bias. CITCON is held on a Friday night and Saturday. This makes a big difference in who turns up. This is an event populated by people who have given up personal time to be there. They must have enough interest, enough passion, to make the trek and to put in the time. Details in background — developers, testers, sysadmins, managers, coaches, consultants — matter less than being the kind of person who will make that personal commitment to improvement. And if you’re a person like that, being in room full of others who feel the same way is hugely energizing. I think that’s why these interesting, accomplished people come back again and again, to be part of those conversations.

Now maybe you don’t recognize those names, but you want to be part of that kind of community, what to do then? Easy, join us in Helsinki!

Starting with the Mutual Learning Model

On February 25th we held the first meeting of the London Action Science MeetupStarting with the Mutual Learning Model. My goal for this session was to describe Action Science as a discipline, introduce key concepts, and illustrate some of those concepts through a hands-on exercise. I’m going to cover the same ground in this blog post including the exercise. I’d love to get your feedback in the comments, especially your experiences with the exercise.

First, what is Action Science anyway? According to the book (see Preface) it is “a science that can generate knowledge that is useful, valid, descriptive of the world, and informative of how we might change it.” More simply, it is the science of effective action in organizations. But this is no ivory tower science, remote and theoretical. Chris Argyris as scientist was also an interventionist. To practice action science is to learn how to be more effective, to help others to be more effective, and to increase the opportunities for organizational learning.

For my introduction to Action Science we began with the Mutual Learning Model as described in Eight Behaviors for Smarter Teams. This white paper from Roger Schwartz has been my go-to introduction for people interested in improving the relationships in their teams. Formerly called Ground Rules for Effective Teams, it provides a Shu-level set of behaviors that you can use to have better, more productive conversations. It also provides the motivating mindset that must be present, the mutual learning mindset, and the core values that go with it:

  • Transparency
  • Curiosity
  • Informed Choice
  • Accountability
  • Compassion

The mutual learning mindset and the accompanying values are easy to espouse. Who doesn’t want to learn? But one of the key areas of exploration in Action Science is the gap between what people claim to value — Espoused Theory — and the values that can be inferred from their actual behavior — Theory in Use.

While effective behavior starts with the theory-in-use of the mutual learning mindset (what Argyris called Model II), there’s a common default action strategy that is used instead, the Unilateral Control Model (what Argyris termed Model I). In contrast to the mutual learning model, the governing values of the unilateral control model are:

  • Achieve the purpose as I define it
  • Win, don’t lose
  • Suppress negative feelings
  • Emphasize rationality

Read these lists again, and test these values against your own experience, reflect on your own behavior… Heading into a meeting where you think there’s an important decision to be made, where there’s something of significance on the line, how do you behave? If you are like me — and according to Argyris if you are like virtually everyone — you will act consistent with the unilateral control model. You will believe your understanding of the situation is correct, you will believe the inferences you make are reality, and you will act so that “the right thing” gets done.

“Well… maybe. But so what?”, I hear you ask. The implication of the unilateral control model is limited learning; I am listening only to formulate my response, only speaking to persuade. It is defensive relationships; you know that I’m acting to get my way. It is reduced opportunity for double-loop learning; we are unlikely to question our norms, goals and values when we are struggling over whose strategy to use. Now perhaps in your context these implications don’t matter. But in teams that want to excel, companies that want to innovate, organizations looking to evolve, we can’t afford to lose learning opportunities. And on a more personal level the defensiveness engendered by the unilateral control model is ultimately unpleasant to live with.

“Okay, I’m convinced! Are we done?” Actually, now we are ready to try that hands-on exercise I mentioned at the start. It is a variation of the two-column case study, tool for exploring and understanding our behavior in stressful conversations, the kinds where it is difficult to produce mutual learning behavior. To perform the exercise you’ll need three items: a full page of lined paper (A4 / 8.5 x 11), and two pens, preferably blue and red. You’ll also need 15-20 minutes and a desire to learn more about yourself. Do you have everything you need to begin?

Prepare by folding the paper in half vertically so that you’ve got two lined columns on either half of the paper. Now think of a difficult conversation you’ve recently had, or are expecting, or a have been putting off. At the top of the page on the left hand of the fold write (blue pen) a sentence describing what you would desire out of that conversation and on the right what actually happened or what you fear would happen. Then in the right hand column write out the dialog as you remember or imagine it. (If this was an actual conversation don’t worry about remembering exact wording; for this exercise the sentiment as you remember it is more valuable.) There isn’t much room on the half-page so this process should only take 5-10 minutes and capture the essence of the exchange. Take the time to write out the dialog now, on the right hand side, before proceeding.

Once you’ve captured the key dialog on the right hand of the paper turn your attention to the left hand column. In this column write down what you expect you’d be thinking and feeling during the conversation. This could be what you are thinking as you formulate your words, this could be your feelings in reaction to theirs. This will likely take less time than the right hand column, only 3-5 minutes. Take the time to fill in the left hand column with your thoughts and feelings before proceeding.

Red pen time. Take a read through your dialog and circle in red every question you asked, every occurrence of the question mark. Write this on the top of the page on the right hand side as the denominator of a fraction. Next, review all those circled questions and count all the genuine questions, every question asked with a real interest in learning something from the answer. A genuine question is not a statement in disguise: “If the team feel they need the time isn’t that good enough?” When you’ve counted the genuine questions write that on the top of the page as the numerator of your fraction.

Red pen time, part two. Look through the left hand column and circle every thought or feeling that did not appear in the right hand column, that is the thoughts and feelings that you did not express. Write a fraction at the top of the page which is the number of unexpressed thoughts/feelings over the total number.

How did you do? In our meetup session the total number of questions was low (0-2) and the number of genuine questions even lower (0-1); very little red ink on the right hand column. The left hand column, by contrast, looked like it was bled upon. Most of the thoughts and feelings were not expressed. Now consider those lists of values again and compare it to your marks in red. If we espouse curiosity, why do we ask so few genuine questions? If we espouse transparency, why aren’t we sharing our thoughts and feelings? This gap between our espoused theory and our theory in use was clearly exhibited by the exercise in the meetup. Being aware of that gap is required to start with the mutual learning model.

What’s next? Experience and reflection has shown me that while I believe the mutual learning mindset is better, it takes effort, real mindful willful effort for me to produce it. But unilateral control behavior? I can produce that effortlessly! I know how to persuade, how to influence, how to build consensus. I know when to press my point and when to back off to avoid conflict. That sounds good, but if our intent is to learn this instinct leads me in the wrong direction. It is a symptom of what Argyis terms Skilled Incompetence. The good news is we can unlearn our incompetence and learn redesign our conversation. Starting down that road is the where we will head in the next Action Science meetup, March 25th. Hope to see you there!

Summary of five years

“What have you been doing these last few years?” was the question Péter Halácsy asked me during my visit to Prezi. I was there for the CTO equivalent of a developer exchange: learning how things were done at Prezi, sharing my observations, and then speaking at the Budapest Jenkins meetup. Prior to my visit Péter had come to this blog to learn more about me, only to learn that I’d not been blogging. I’m resolved to get back into the blogging habit this year and I decided I’d take the time to fill in the gap for any future Péters. In part this will recapitulate my LinkedIn profile but also describe some of what I felt was most significant.

The primary reason I only posted a single post after 2009 was that I joined Urbancode in a marketing/evangelism role and I posted almost everything I had to say under their masthead. In my two and half years there I had a great time spreading the word about build automation, continuous delivery and Devops. I was able to visit a wide range of companies, learn first hand about the challenges of enterprise organization, and then turn this information into new content. At Urbancode we developed a very good flow of information and almost every month we had a new webinar, a newsletter, and maybe a white paper. My primary content collaborator was Eric Minick and he has kept up those evangelizing ways at IBM following their acquisition of Urbancode.

After I left Urbancode we made a family decision to try living in London for a few years. I reached out to Douglas Squirrel and he brought me into TIM Group to do continuous delivery, infrastructure and operations. In my time there I’ve become CTO and Head of Product and I’ve really enjoyed the opportunity to apply what I know, both about product development and about organizational change. I’ve been almost equally as absent from the TIM Group development blog, but I have managed to share some of our experiences and learning at a few conferences including GOTO Conference 2012 (talk description & slides: A Leap from Agile to DevOps), London Devops Days 2013 (video of talk: Crossing the Uncanny Valley of Culture through Mutual Learning),  and XPDay London 2014.

During my time in London Benjamin Mitchell has been one of the biggest influences on my thinking and approach to organizational change. Benjamin has been a guide to the work of Chris Argyris and Action Science. It has been what I’ve learned from and with Benjamin that has inspired me to start the London Action Science Meetup.

Finally, I couldn’t recap the last few years without also mentioning Paul Julius and CITCON. Since I last mentioned CITCON North America in Minneapolis on this blog in 2009 we’ve gone on to organize 16 additional CITCON events worldwide, most recently in Auckland (CITCON ANZ), Zagreb (CITCON Europe), Austin (CITCON North America), and Hong Kong (CITCON Asia). For PJ and I this is our 10th year of CITCON (and OIF, the Open Information Foundation) and it has been fantastic to continue to meet people throughout the world who care about improving the way we do software development.

Speaking at ESDC

The first week of March will be a mix of old and new for me. I’ll be speaking at a new conference, ESDC, the Enterprise Software Development Conference. This conference isn’t just new for me, it is new period, taking over the traditional calendar-slot of the defunct SD West. If you’re interested in attending you can use my last name as a discount code when you register to get $100 of the full conference pass. You can also register to attend the expo for free as long as you register by February 28th.

I’ll be giving two talks at ESDC, both on Wednesday March 3rd. I start the day bright and early with #605 Going Lean: Slash Waste with Build & Deployment Automation at 8:15 am, and finish the day at 4 pm with #906 Creating Habitable Code: Lessons in Longevity from CruiseControl. Lean software development has been a hot topic for me lately, as members of BayXP and the Silicon Valley Agile Meetup should know, while practices for creating long-term sustainable code has been a long term sustained interest. I’ve delivered the Habitable Code talk before but this’ll be the first time doing it solo, without Paul Julius by my side.

Build Engineer Bootcamp and CITCON Minneapolis

Paul Julius and I have put together a training class for neglected population:  build engineers. We don’t mean release management people exactly, though sometimes they have the build engineer job. No, we mean those people who are told “go write the build script”.

Historically the build, like an installer, is a very low status job. So historically it goes to low status people, like the most junior developer on the team, or perhaps even a QA person. The result is that many build scripts, like many installers, more or less suck. I think this is more a reflection on the low status of the task than the skills of the person; there is just very little incentive for fixing a bad build. But that’s mostly because so few people have worked in environment with an excellent build they don’t know how much their missing.

We think that in the move to agile development your build can be a major blocker, or and that there are major productivity gains at stake, so it makes sense to approach your build engineering efforts as a serious task. We think this is a big enough problem with a big enough potential gain that we’ve organized a public Build Engineer Bootcamp for April 22nd-23rd in Minneapolis. Come and learn how to get your build system on a solid footing and then stay for CITCON (free, but separate registration) and learn about how to take your continuous integration and testing efforts to the limit.

Hope to see you there!

OSTATLI: Safari & Firefox with Watir

I went to Elisabeth‘s Open Source Testing Automation Tools Love In with a very clear mission: “Get SafariWatir testing my local WordPress instance the right way“, where the right way meant using a single script that would also run against IE and Firefox without modifications. I’m not sure I was a good OSTATLI participant because I spent most of my time in the corner trying to get my goal met while other people were talking about cool stuff (which is why Watir/FireWatir/SafariWatir didn’t make the list of tools; I didn’t know we were making a list). But I had a blast anyway and was able to meet my modest goal.

My starting point wasn’t quite ground zero but it was close. I used Ruby on a project for a couple of months a couple of years ago but I haven’t used it since. And I’ve never used Watir. The last time I wrote tests to drive a browser it was 2002 and I was using WinRunner.

My motivation for this project came as a side-effect of my recent change from full-time to consulting/contract work. I’ve been working out of NextSpace, a coworking operation in Santa Cruz, and that has given me a different set of colleagues than I’ve had in the past. I’m now daily rubbing shoulders with a range of interesting people, but a bunch of them churn out websites for a range of clients. The technologies vary — WordPress, Drupal, Flash, Ruby/Rails, etc — but one common factor is there seems to little in the way of automated testing, even for sites that involve a lot of custom coding. I’ve wanted to know if some of the tools from enterprise IT and product development could be applied in their context.

I was interested in using Watir for a few different reasons. One seeming motivation is that I’ve done some consulting for WatirCraft, but that’s getting things out of order: I was interested in what they’re doing before I started working with them. What really attracts me to Watir is the philosophy that they want to take maximum advantage of Ruby as a language, as opposed to having a language neutral API like Selenium. I enjoyed Ruby when I worked with it and I’d like to do more of it. I also really like the idea of Ruby as a language for testers. Testers have long done more coding than they get credit for; switching that coding to Ruby should offer more opportunities for collaboration with developers and more credit and status from the coding they were doing already.

I was also interested in doing this experiment with Ruby because Bret/WatirCraft have been working on a new WatirCraft framework, with the source available in GitHub, and one of the enabling changes in Watir was to allow browser independent scripts by using Watir::Browser.new. All the references I’ve seen to this reference IE and Firefox, but since I’m on OS X (and because I’m a bit of an Mac fanboi) anything that doesn’t work with Safari is a non-starter. I went so far as to ask for Safari support on the WatirCraft UserVoice page only to be told it was already there. Oh. Okay then…

So here’s what I actually did. I installed the very awesome MAMP, an all-in-one installer for Macs to run an Apache, MySQL and PHP stack. Next was WordPress 2.7. Ruby 1.8.7 came via the also awesome MacPorts. Then began the fun that started “sudo gem install …”:

  • safariwatir
  • firewatir
  • rspec
  • cucumber

I didn’t actually use Cucumber, but there was talk of it in the air and the examples look interesting so I gave into the peer pressure. (Maybe in a future OSTATLI…)

Honestly I struggled a bit getting started from that point, trying to run the Watir tests against SafariWatir… or even the SafariWatir tests on itself! But here the power of Twitter came in handy, with Dave Hoover stepping up from behind the SafariWatir twitter account and updating the directions for running the Watir tests in GitHub in real time. Dave likewise saved me from the rathole of the old SafariWatir tests. In the midst of my struggles I did come to appreciate GitHub. It was trivially easy for me to fork SafariWatir and send a couple of minor tweaks back to Dave. After years of taking submission to CruiseControl via patch files and working with CVS and SVN, I’m jealous!

Eventually I was able to sort our some basic RSpec syntax and some basic Watir syntax and put together this script which met my goal. If you have the default WordPress 2.7 site running on port 8080 (and you have the same admin password that I left hardcoded in the script) then this script will open Safari, log into WordPress, post a message and logout. Change Watir::Browser.default = ‘safari’ to Watir::Browser.default = ‘firefox’ (and install JSSH) and the script will run against Firefox instead. This setting is in script for connivence; if I were testing in anger I would be setting it with an environment variable from Rake as I ran the tests.

My plan for the future it to take this a step farther and try running the same tests from Celerity. My vision is a system where we run tests in Celerity for fast feedback and then run across browsers to surface compatibility issues.

I would love to do more work doing cross-browser testing with Watir (and fix some of the incompatibilities in the process). If you know of anyone with a contract for that kind of work they can contact me via The CI Guys website.

StrengthsFinder Report Circa 2005

Back in 2005 I read Now, Discover Your Strengths and took the original StrengthsFinder test. My top 5 strengths were:

Strategic: People strong in the Strategic theme create alternative ways to proceed.  Faced with any given scenario, they can quickly spot the relevant patterns and issues.

Input: People strong in the Input theme have a craving to know more. Often they like to collect and archive all kinds of information. 

Learner: People strong in the Learner theme have a great desire to learn and want to continuously improve.  In particular, the process of learning, rather than the outcome, excites them.

Individualization: People strong in the Individualization theme are intrigued with the unique qualities of each person.  They have a gift for figuring out how people who are different can work together productively.

Intellection: People strong in the Intellection theme are characterized by their intellectual activity.  They are introspective and appreciate intellectual discussions. 

My original fear was that the StrengthsFinder results would be like reading your horoscope: no matter what came back you’d find a way to make it fit. But at the same time I took the test so did two others in the management. It turned out we all shared 3 of these traits but the differences really did seem to fit the people. And looking back I do think it has been these traits have have shaped my career and my passion for what I do now.