thekua.com@work

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.

Comments(2)

Last year, I missed the announcement, and therefore the Agile Coaches Gathering UK organised by Rachel Davies (author of Agile Coaching). Fortunately I happened to join twitter late last year and saw the announcement for this year’s gathering shortly after its announcement. I bought a ticket as soon as I could. It’s a good thing too since I think I bought one of the last few tickets for a restricted sixty person gathering.

This year’s gathering, held at historic Bletchley Park spanned a day and a half with Friday evening opening the Open Space format to be used on Saturday. Bletchley Park ended up an awesome venue, and the open space format worked well with a number of spaces located outside. Given the UK actually had a summer this year, it turned out very nicely.

One of my favourite things about this sort of gathering is getting a whole bunch of people working in many different environments, contexts and getting them to share ideas and approaches about what works for them. We had a mixture of experienced coaches and coaches new to the role yet there was something about being there on a Saturday and a passion for it that brought people together. What follows are my notes from each of the sessions.

Experiences from the coaching discipline (not just agile practices)
My first session of the day explored other coach’s experiences working or exploring what coaches from other disciplines do. One person shared their experience working with a swimming coach and how they helped them get better at their practice.

This theme, looking at other coaching disciplines to see what they do, definitely ran throughout the day although I’m cautious of taking the role too literally. We discussed this during this session as most people being coached (life coaching, sports coaching, etc) tend to do so on a voluntary basis. Working as agile coaches for organisations, not everyone is necessarily there on a voluntary basis.

Another aspect that, I think differs, is that most coaches aren’t necessarily experts in the field they’re coaching in. For instance, sports coaches are often not people who’ve been the most successful in the world. In my experiences, agile coaches are really there to act as shepherds to help people get the most out of thinking and working with agile practices. Unlike other coaches, this often requires a level of mastery than what most other coaches have in their field. I’ve seen coaches act dangerously with not enough experience with agile practices.

I still think there is value in looking outside of our discipline for ideas and methods of working, yet conscious of the appropriate context to use them in (and there is always a context).

Presentation is not facilitation
Tobias Mayer is really well known in the Scrum community, and proposed a session to rant about the way that most training is done. I think there are plenty of examples where Death by Powerpoint is interpreted as effective training and whilst I agree with the premise, I’m not sure I agree with the end conclusion. I think presentations have a place, just maybe not in training. I also don’t necessarily think that training is solely about trying to trigger a complete mindshift in people.

When a coach gives up
I met Xavier Quesada Allue at XP2009 and again at Agile2009 so was interested to hear the premise around is it okay for coaches to give up and when to give up. This was one of those sessions located in the sun and some interesting stories about dealing with difficult teams or organisations where it doesn’t make sense to try.

We didn’t attempt to clarify, at the start of this session, what giving up meant to everyone. This probably made it difficult to get an agreement about when or why to give up, although we heard some very interesting stories.

My take on this, is that coaches end up needing to prioritise their work, just like everyone else and thus, not everything is going to get taken care of at the same time. Working with people also means you cannot predict how quickly people will move, or how they will react, therefore there is no way that you can always set completely achievable goals (it relies on others, not just yourself to make them happen). As a result, as a coach, you need to be comfortable with things not always going as planned.

I think that coaches also have the benefit of seeing the system that is driving a lot of the behaviour for the people on teams and unless something is done with that, then they will continue to behave as they always have. Both of these take time.

Game sense approach (what I learned coaching rugby)
Another inter-disciplinary coaching session that I attended briefly although a very loud bus made it difficult to concentrate and I ended up leaving because I had difficulty participating during this session.

Double loop learning + Defensive routines
If you ever get a chance to listen to Benjamin Mitchell in a safe environment, he’s quite the riot. If anything, perhaps it’s his self-deprecating and admitting his own faults and looking back at mistakes amidst his jokes that makes it so warming.

During this session, he talked about a book he’d been reading discussing how people react, and talking about different “models” in which the author classified people and using that to be able to project behaviour in different circumstances.

Once again, Benjamin reminded me of some key points I’ve learned over the years like:

• What you say and what people hear are completely different
• Avoid positional or solutions-based negotiation. Lay your interests on the table and you’ll often end up in a better position.

I’m not really clear about what double loop learning is, so I’m going to have to add that to my to do list as well.

New books

• Training from the back of the room
• The Skilled facilitator
• Situational leader
• Discussing the Undiscussable

Comments(2)

You want to ensure reusing functionality does not have any other side effects in other places that might be using it.

Make the static instance explicit by introduce a static instance encapsulating any static state and delegate items to it. Use the instance.

Imagine you had this sort of code (below) and there’s dozens of use throughout a codebase. Static imports make it easy for people to simply increment a count, but in order to use the Counter, you have no assurance nothing else will try to use it.

public class Counter {
  static int totalCount;

  public static void count() {
    totalCount++;
  }
}

The following transformations will help you keep existing clients happy:

• Introduce new method (instance level)
• Introduce global instance
• Delegate static method to new method (instance level)
• Turn static state into instance state

The final result is below (note that this code is not thread-safe and not designed for concurrent programs, but is there to demonstrate the result of the refactoring steps):

public class Counter {
   private static final Counter INSTANCE = new Counter();

   private int totalCount;

   public static void count() {
     INSTANCE.recordCount();
   }

   public void recordCount() {
     totalCount++;
   }
}

Now we had a bit more of a complex example, but this refactoring helped us move to the right direction of using instances where possible, instead of sharing global state.

Comments(0)

This year’s XP2010 conference was held in the great Northern parts of Norway, up in Trondheim, only about 200km south from my first XP conference (XP2006) I attended several years ago. I always find this series of conferences interesting, partly because there is always the blend between the academic (research papers and experience reports) and the industrial side as well as the infusion of the hosting country’s culture.

This year, the conference saw 425 attendees (50% of them Norwegian) across 8 different tracks and covering four days of a wide variety of conference mixtures including Lightning Talks, Panels, Workshops, Tutorials, and Open Space events.

The first of the two keynotes, run by Scott Page was my favourite – a lecturer and researched on complexity in different environments. He talked about the importance of diversity and its impact on building better solutions as well as a provable formula calculating what the wisdom of the crowds was. Hopefully they’ll be putting up his slides somewhere as a result.

The second of the keynotes, ran by David Anderson did a great job of condensing down a long talk into a thought-provoking discussion on the work that he’s been doing on building a Kanban movement in the places he’s been working as well as a discussion of his recently released book about Kanban. He had some nice visualisations on the slides and even finished slightly earlier with plenty of times for questions.

Overall the conference seemed to have a nice blend of both process and technical topics, although there were a few complaints about specific discussions around “XP” itself although I think plenty of discussions about specific practices quite useful within any agile context.

I ended up much busier than I thought I would be, playing host for two of the session talks, helping out with a Pecha Kucha (more on that later) session and running a workshop on my own.

Venue, organisation and efficiency wise, the organisers need to be congratulated on a job that will be hard to surpass. Everything seemed to run smoothly including an amazing and difficult-to-forget Conference Banquet involving interesting local foods (smoked reindeer heart, moose and local seafood), a pair of comedic jazz academics, Keep of Kalessin playing some Extreme Metal, all inside Trondheim’s amazing Student Society venue.

The strangest part of the conference for me was participating in a “What’s in my agile suitcase?” Pecha Kucha run by Martin Heider and Bernd Schiffer. You can read more about the format here and it was great to be one of the five other prepared Pecha Kucha’s including Rachel Davies, Mary Poppendieck, Joshua Kierevsky and Jeff Patton. I found the diversity of styles and approaches fascinating as well as the specific things that people “packed” in their suitcases. Being the first time format all the speakers found it a fascinating format made thrilling by the short-time and the fact you don’t have control over the timing of the slides. If I were to do this differently, I’d definitely try to focus on a smaller range of topics (or just one).

My week ended (as did the conference) with my final workshop called “Building the Testing Pipeline.” I’d specifically targeted people who’d been working with automated tests for some time and I ended up with a surprisingly full room. I’d run this previously at ACCU with a slightly different audience. We had some great brainstorming sessions (I’ll be putting that up soon) and hopefully more people came away thinking more consciously about the balance of tests they have and whether or not they have the correct balance that maximises their confidence, and minimises their feedback cycle.

I’m also very proud that the experience report that I shepherded won best paper (experience report), and I finally got to meet the author, Jørn Ola Birkeland of Bekk Consulting, in person to congratulate him on the day.

Thanks to all the organisers, participants, and passionate people that made the conference so much fun and success. Wonderful to reconnect with old friends and make many new ones.

Comments(4)

It’s about time I got around to reading the whole Agile Coaching book by Rachel Davies and Liz Sedley. I’ve owned it for at least six months now but has sat with a number of other books that demanded my attention. Fortunately long flights (like back to Australia) give you lots of time to pass with books to read. I’m glad I finally got around to reading it as well. The short version: if you’re interested in what agile coaches do, or if you’re working in an agile team, particularly a leadership role, this book is for you.

When you first open the book, it’s obvious it is a Pragmatic Press book. It jumps straight in with lots of helpful hints for those that want or are currently looking to be an agile coach. It’s broken up into four main areas, with smaller sections revolving around specific agile practices. This also means it’s fairly easy to digest it in smaller pieces (something I probably could have tried) doing the daily commute on the train.

I’ve been fortunate to know Rachel and Liz before and during their book writing. This book really captures the way they work, and great advice in the form of very practical tips for people. I hope that any readers, even without knowing the authors, can tell the wealth of experience both of them bring. I think writing a book on agile coaching is pretty tough. There’s a temptation to focus on the coaching elements alone, or to capture the distilled gotchas around introducing and coaching teams on specific agile practices. This book definitely gets the balance right for those new to coaching agile teams – enough background to the practice with helpful hints (it’s not meant to be a definitive guide on a particular practice) yet framed in a way that would definitely help anyone introducing and encouraging an agile way of working.

There are many other people this book wasn’t written for (more on that later) yet in its form is the best collection of wisdom steeped in experience that I see budding agile coaches benefiting from. I wish I had something like this when I first started out explicitly acting as an agile coach.

Like all the pragmatic books, this one is really easy to read. I think it took me about three hours on the first leg of my flight to finish it. Reading through each of the sections, the authors offer advice and helpful techniques. Many I’ve drawn upon over the years and draw upon often, a few I’ve never used and many that I definitely needed a reminder about using them. In other words, this book contain lots of practical advice that can really work depending on your team and circumstance.

There are many things that I like about this book – including the small personalised stories from both authors, named techniques that will help new coaches remember them better, and a very direct try this and see sort of philosophy that is both pragmatic and living by an agile way of working. I particularly approve of this book being, for the most part, methodology-neutral mentioning a broad spread of practices and principles individual methodologies espouse followed up with many other links to resources, books and references for agile coaches to then follow. I also like the hurdles section (there’s often much more than those listed!) as it hopefully prepares agile coaches for what happens when things don’t go to plan (almost always).

This book definitely fills a need – helping new agile coaches work out where to start with lots of advice that can be applied almost immediately. This book is also a useful reminder of tehcniques and a way of filling in some gaps for agile coaches who might have only experienced some of the agile practices and ways of working.

Like all well focused, practical books, part of what makes it so well focused and good are the areas that it leaves out (something I’m sure will be filled by other books to come). Some of these topics include:

• Setting up an agile coaching gig right (when they perhaps need something broader than agile coaching) – it’s no panacea for all organisational problems and coaching isn’t guaranteed to turn every situation in short timeframes
• Coaching larger teams or large organisations
• Coaching distributed teams
• Helping organisations “go agile”
• Different types of coaching engagements (full time – to part time)
• Working with other agile coaches as a team

I’m glad someone got around to putting this book together – and I’m happier knowing that it’s also written by practitioners grounded in plenty of real world experience and a variety of different contexts. To new coaches, many of these apporaches may seem optimisitc or impossible but I know that they’re all tested and can work in the right circumstances. Read this book as a way of starting off and refining your own agile coaching style – don’t view this as a definititve book to agile coaching, and as the authors put it so well at the end of the book – develop yourself continually.

Comments(2)

Just a short note that I’ll be running a workshop for attendees of ACCU2010 this Saturday on understanding how to get the balance right for the testing aspect to build pipelines. We’ll explore the tradeoffs and conscious decisions we should be aware of when putting these into our feedback loops.

Slide deck to come, though it’s a classic me-style, participatory workshop (you learn more by doing!) so slides won’t necessarily make a whole lot of sense by themselves.

Comments(0)

How many times have you heard, “We’re not allowed to do that because we need to follow the process”? I had a great example this morning when catching the train out of Kings Cross, dropping into the Carluccio’s chain to pick up the Italian breakfast of a coffee and pastry. Carluccio’s, hidden on the top floor of the St Pancras building, meant I went out of my way to try something different.

The entire shop was quiet, though the main door was open so I walked in. As I entered, the waitress, obviously setting up for the day by putting pastries on the shelf turned to me and said, “We don’t open until 8″. I walked out, empty handed and Carluccio’s lost another customer for the day.

This, by itself, wasn’t so much of a problem, if it wasn’t so rampant all over the world. Just another example of using the “process” to justify not being to able to give the customer what they wanted. This would never have happened with my normal coffee shop, the Farm Collective.

Imagine if, this waitress, explaining how they don’t normally open until 8, but would go out of their way to give me a coffee or, at the least, sell me a pastry for breakfast. Imagine the story I’d be telling now.

How often do you see this in the organisations you work with?

Comments(5)

For the first several years at ThoughtWorks I ran an annual personal retrospective looking back at the year gone by. I value celebrating success, making time to reflect and finding ways of continually improving. I ran them for the first few years before collapsing them back into each New Year’s review.

So what has happened six years on?

When I look at first starting at ThoughtWorks, I was just another developer, almost considered a graduate, because I’d only a small amount of real world experience. I worked for ThoughtWorks in Brisbane when we had an office presence, staying there until itchy feet drove me overseas. I could have moved to another Australian capital city, but London ended up much more of a drawcard with so many more opportunities and access to more interesting aspects to life harder to reach in Australia, such as exposure to so many different cultures (music, food, entertainment), personal travel opportunities and the presence of many professional communities.

To this day, I still can’t fathom working with the same company for six years. When I left university, I assumed two years would be the most I would work for in any company. Being lost in one of Oracle’s massive divisions only served to reinforce this view. So what’s changed? Working for a consulting company brings a variety similar to working for many different companies, yet without being tied to any particular one. Each project brings with it plenty of learning opportunities to uncover new contexts, problems and solutions.

Since being based in London, I’ve worked on at least nine projects of great length (a handful of much smaller ones as well). Unlike many of my colleagues, I’ve worked on many projects beyond web technologies (although I’m sure they’re just as fun). Some of these applications integrated with lots of hardware (think RFID readers, barcode printers, scientific equipment), server side REST applications with extremely high performance requirements, lead several development teams, taught fellow colleagues through our lateral training induction programme in India, and coached some very large organisations on appropriately using and understanding agile methods.

In this time, I’ve been fortunate to work with plenty of bright people, both within our own company and at our client, and grown great personal satisfaction by helping others find a passion for learning and taking pride in what they do.

Seeing a variety of situations and working with lots of different people in lots of different roles has lead to significant growth as well. One of the aspects I appreciate the most about ThoughtWorks is the ability to move between roles and develop skills in different areas. Although we’re trying to put a little bit more structure in place, it’s not a place that thinks you have to grow up or get out like many other consultancies.

So the upsides:

Consulting – You develop many experiences and see many environments, giving you better insights into how people behave and how to overcome undesirable behaviour. This first hand experience is invaluable as you apply it to new environments and new clients. Not being independent means I don’t always get choice of what I work on, but I have to be thankful for some of the opportunities over the last six years (partly of what I’ve made it as well).

Growth – Not everyone takes the time to explicitly focus on learning from people around them. This is one of my core principles. Being surrounded by people who think and have great conversations helps me grow. Being put into new situations, slightly beyond my comfort zone increases my confidence and skill set as does dealing with difficult client situations. I can’t thank of many other organisations where I could develop facilitation and coaching skills whilst moving back and forth between hands-on technical work.

Opportunities – I’ve been fortunate to present at a number of conferences over the years. This isn’t an easy path and isn’t one that happens overnight. I’ll be the first to admit, fantastic story telling at the level of Dan North isn’t one of my strong points, but I like to think many people enjoy the experiential workshops I put together. Opportunities are about making the most of what you find yourself in, such as finding yourself, unwillingly, to work in Copenhagen over the summer lead me to finding that lone free booking at Noma, the world’s third best restaurant in the world and enjoying one of the best meals I’ve eaten in my life.

People – ThoughtWorks prides itself about hiring great people. That’s not to say that we always hire perfectly. However I’m glad to be surrounded by other people who take pride in their work, care about learning and passionately applying themselves in whatever they like. I’ve lost count over the years for the number of work colleagues who’ve inspired me to get better at things that I do, and challenged me to better understand the work that I do. I continue to meet more people like this everyday, and am thankful for that dimension.

And the downsides:

Support – Part of not having clearly well defined structures for people as they “advance” make it harder to plan for the right level of support and to time it correctly. I know of some people who moved on by not getting the right support at the right time, and those who failed to get the right sort of support. This isn’t to say that there is no support but it’s a bit random at times. I know that I was particularly let down during my last year although I recognise I have higher tolerances than most.

Travel – I primarily moved across to the UK because of the strong correlation between project work and the office. This has definitely changed over the years. Travel is a necessary part of consulting, yet made harder when traveling greater distances and amplified by the lack of support.

Consulting for clients is different from working in the office – This is definitely one frustrating elements for working for any consulting firm, and I don’t think that ThoughtWorks is any different here, with a different cultural divide between those working in the field and those working in the office. It’s taken me years to see some of the systemic effects, although I’m sure it will be much more before there is something significant I can do about it. Ask me about in person and I’d be happy to run through my current theory.

The key to retrospecting is about learning, so here’s some of the lessons I’ve learned:

Leadership is not about titles – People I talk to see leadership as a role you are explicitly given. I disagree. Leadership implies taking ownership of responsibility and this is true whether or not you are given it or not. It’s not about a role, or a title. It’s about the way you act and the things you say. The leaders I’ve most respected were those that owned the rewards and pitfalls of responsibilities, regardless of it not being an explicit part of their role. The best teams I’ve worked on ensure all responsibilities are taken care of despite the varying titles amongst the people on it.

Everyone is responsible for passing the experiences on – Working for six years for any consultancy is rare, and part of that comes with a certain responsibility of passing on the right culture, and creating the same opportunities for others new to the organisation. Every individual in an organisation should feel the burden of this responsibility. I’m grateful for feedback from co-workers the difference that I make to them everyday. It’s amazingly gratifying to know that I made a positive contribution to people’s growth, even more so when I already hold each one of them in high regard. It’s so gratifying to receive that random text or email from previous co-workers telling me how they’re still doing, or doing things differently as a result of the small investment I made with them.

People move on – People leave companies. That’s a fact of life. The way I look at it, an individual’s needs and wants change more quickly than what an organisation can adopt. I think it’s the organisation’s responsibility to ensure that it does as much as it can to keep people. I think an organisation’s failure is to not to do what it *could* have done to keep them there. This sometimes happens and it’s frustrating. I think we can also get better at keeping in touch with alumni because we definitely aren’t very good with that.

Consulting is a sharp, double edged sword – The change that brings about new experiences and opportunities also often requires travelling or something not quite matching up. Some people in our organisation believe growth will solve these problems, something I also disagree with. I think growth will simply make it much more complex to solve. Having more people on hand simply makes it harder to get the right people to the right place at the right time.

Learning is a lifetime endeavour – I continue to argue how our education systems force us to stop thinking and learning. We focus on teaching (push) over learning (pull) and worse, we focus on absorbing facts instead of thinking. Our environments offer learning opportunities all the time, yet we’re trained to turn a blind eye to them, or to fail to respond to them. Living and breathing agile methods has taught me to learn first, and judge later.

Comments(6)

When you introduce agile methods to very traditional organisations there’s a side effect most people underestimate. This is, I believe, where the first line in the manifesto is most appropriate:

Individuals and interactions over processes and tools

Traditional organisations are geared for efficiency – keeping individuals busy to the point where you lose overall effectiveness if you ever need to synchronise between parts (which you inevitably do for software these days). Calling a meeting is frowned upon as it takes up lots of time, so out of necessity, most communication occurs over email or IM. As Alistair Cockburn pointed out a long time ago, these are pretty ineffective channels of communication. Relying solely on these types of channels only turns to a build up of frustration as issues go unheard by the right set of ears. In traditional environments, these often turn into build ups set to explode at the most random of moments.

Image from Nic Jacka’s flickr stream under the Creative Commons licence

Perhaps you’ve seen it? Think about when one person hijacks a meeting to highlight an issue (typically important one) not being addressed, or when someone spontaneously shouts at someone for no apparent reason. It might even be as bad as someone having a temper tantrum, literally throwing things across the room. Traditional environments often do not provide mechanisms as outlets for this.

Therefore, when introducing practices such as daily stand ups, planning meetings and retrospectives, the first few times you run them, expect an avalanche of unresolved issues and emotions to ensue. This is fine. Expect this from some of the quieter members as you give them explicit permission to talk about important things that need resolution where traditional structures have not given them that permission to talk about them.

Treat it as you would the opening of a previously shaken soft drink bottle for the first time. You’ll have to be ready to clean up some of the spilt liquid, but you don’t have to worry about picking up broken glass. Now that the bottle’s open, you can work to address the real issue at hand.

Comments(2)

I first read “A Community of Thinkers” that Liz, Jean and Eric published late last year. I remember thinking that I felt strongly aligned to it, yet slightly uncomfortable with the exact wording. I toyed around with some words and now, a couple of months later, I am much more comfortable with a slightly abridged version.

It isn’t enough to be a member of a community of thinkers. We can philosophise and think ourselves to death. The world continues to operate in complex ways (yes, as in this, and this sort of complexity). It is not enough to sit back and only think. We need to experiment. We need to apply. We need to practise, then reflect and feed those learnings back into our thinking. This is the essence I respect the most about certain people in the agile community. This is what I want to keep alive. Remind yourself the Do is an important part of PDCA just as much as Check (Reflect) is.

For me, I am not just a member of a community of thinkers. I am a member of a community of thinking practitioners. If you’re not practicing and actively thinking, you’re not part of my community.

A Community of Thinking Practitioners
I am a member of a community of thinking practitioners.

I believe that communities exist as homes for professionals to learn, teach, and reflect on their work.

I challenge each community in the software industry to:

• reflect and honor respect the practitioners who make its existence possible;
• provide an excellent experience for its members;
• support the excellent experience its members provide for their clients and colleagues in all aspects of their professional interactions;
• exemplify, as a body, the professional and humane behavior of its members;
• engage and collaborate within and across communities through respectful exploration of diverse and divergent insights;
• embrace newcomers to the community openly and to celebrate ongoing journeys; and
• thrive on the sustained health of the community and its members through continual practice, reflection and improvement.

I believe that leaders in each community have a responsibility to exhibit these behaviors, and that people who exhibit these behaviors will become leaders.

I am a member of a community of thinking practitioners. If I should happen to be a catalyst more than others, I consider that a tribute to those who have inspired me.

This one is based upon the original posted on Liz Keogh’s blog here. This licensed under the Share Alike Creative Commons License. All modifications/addendums I made are emphasised in italics.

Comments(3)