thekua.com@work

In the morning I attended the Michael Spayd’s “Deep Democracy: A Radical Approach to Hearing from Every Voice” session.

What did I learn?

• Clarity is important in a workshop format – I didn’t come away with a clear understanding about what Deep Democracy was. Perhaps it was my misunderstanding of the workshop however the program talked about the explanation and the demonstration of Deep Democracy. If they were to run it again, I would suggest being clear about what defines Deep Democracy versus not. I would avoid trying to introduce too many concepts such as relationships coaching or systems coaching unless it was relevant. Learning too many things at the same time is just plain hard.
• Energy is important to workshops – The room was really cold and I found my fingers tingling by the end of the session (I ran to grab a cup of tea just to warm my fingers). I think an interactive workshop could have helped here, or more energy in the room. To be fair, the room was excessively large for the number of people.
• A new acronym! ORSC (Organisation and Relationship Systems Coaching) – A certification body that teaches some coaching techniques and styles focusing on a more wholistic point of view. Whilst I’m interested in what knowledge they have to offer, I’m turned off by the certification process.

After that session I ran my session, Climbing the Dreyfus Ladder of Agile Practices.

What did I learn?

• Assistants setting up and cleaning up make a huge difference – Thanks to Andy Palmer, Jen Mozen and Alistair Jones for your help. Having some help helped me to settle my mind both before and after.
• Innovation happens when you state outcome (what) without prescribing method (how) – I handed out some flipchart paper and some headings and what amazed me was three different ways of putting the headings on to the flip chart given only five groups of about 6 to 9 people. What amazed me was how all of them were still very effective (one emulated what I had demonstrated, one turned the flipchart on its side (landscape mode) to fit all the headings, and another came up with a ladder based approach with items floating on either side. Wonderful, wonderful, wonderful work!
• Using the Dreyfus Model to communicate with other coaches – I love using the model for coaching tools, yet it didn’t strike me to use it as a way of agreeing with other agile coaches, some of the behaviours that we would expect of people (although I haven’t really worked in a place where I’ve had more than myself to coach but I will definitely keep this in mind)
• Print more compact headings – The headings I’d printed were a little bit too small to put on a flipchart in portrait mode. I’ll make more compact version so that it’s not too hard to put them as headings
• Have bigger fonts on the slides – I wasn’t counting on being in such a large room and having the tables so far from the screen (not to mention a weird projector that stretched out the slides vertically). As such some of the slides were a little hard to see so I apologise to all the participants for that.

The only afternoon session I attended was a panel featuring my Continuous Integration luminaries, and facilitated by Tom Sulston titled, “How to be really awesome at Continuous Integration“. It was a great discussion about lots of tips for newbies to Continuous Integration and a great opportunity to ask for advice. I didn’t necessarily learn anything new yet it was nice to see some great passionate people discussing their thoughts about CI.

Comments(2)

In the morning I attended Pascal and Portia’s The Bottleneck Game, an engaging and great place to learn about the Theory of Constraints and their use of Real Options.

What did I learn?

• A new presentation style – Using lo-fi sticky notes on paper as slideware. Clear handwriting is a pre requisite so I think I need someone else to draw mine!
• Inviting Observers to act as Consultants – As a way of engaging those that can’t play the game into the session
• Portable microphones can make a huge difference – In the large room, it was sometimes hard to hear the presenters since they both had soft voices.
• I’m not very good at folding paper hats – ^_^
• Go slow when learning something new – The facilitators made sure we stepped through each step before moving on to the next one to ensure that we went through the motions. Too many times, it was too easy to jump over necessary stages. It was definitely helpful to be reminded to go slow when learning.

After the morning tea break, I went to Neal Ford’s presentation, titled Emergent Design & Evolutionary Architecture

What did I learn?

• I like the distinction Neal made about design and architecture. Design is something that you can defer choices on. Architecture is something that you need before starting but can still change. It’s pretty important to make that distinction.
• Neal has a great presentation style, very visual, combined with lots of stories. I can now personally recommend him based on my own experiences (and not just on hearsay!)
• 90 minutes is way too long for a presentation, even if it was engaging as Neal is. I found myself fidgeting just to stretch after about 45 minutes.

Due to some longer commitments at lunch, I missed the talk Michael Feathers and Steve Freeman gave on TDD 10 years later. Fortunately I know a variation is available on InfoQ I can watch later. I had hoped to see them in person. Instead, I arrived just in time for Sharlene McKinnon’s, Iterating a Team in Flux session.

What did I learn?

• Avatars – I really like the pictorial representation that they used for visual management. I’d like to know how they made them since they looked amazingly life-like yet cartoony.
• Visual Management for surfacing of issues – It’s great to see how making information more visual helped them have better conversations and surfaced the problems that were already there.
• Test your slide deck against the projector early – Sharlene had some resolution problems with the projector that could have been sorted out before the session. It was great that she didn’t depend on her slides yet could have been supported much more by the whole slide instead of the partial.

Comments(2)

It’s at the start of the third day to Agile 2009, and I wanted to write up some notes from the conference before I start to fill my head with more ideas from the third day. It’s definitely going to be a slow start to the day, not because the program isn’t interesting, but rather since I’ve had a few hours sleep.

Yesterday was a full day and full in the sense of many wonderful things to think about. Alistair Cockburn kicked off the morning with a keynote titled, “I Come to Bury Agile, Not to Praise It“. Let’s be clear here (Cockburn emphasised this at least three times) as this will no doubt be misinterpreted by people over time: This session was not saying that agile was dead and useless. Rather, that agile has become an everyday part of life, no longer controversial and proven to be good and practical. After all, it’s been around for at least a decade now. Cockburn used the metaphor of an iceberg (agile) melting and forming part of the ocean.

If you get a chance to catch Cockburn speak, I cannot recommend him highly enough. Rather dramatically, he walked on stage following a fellow playing bag pipelines, only to perform a Shakespearen soliloquy completely memorised without notes. Very impressive! I’ll agree with some critics that I don’t think that what Cockburn had to say was controversial, yet that doesn’t automatically make it a bad thing. Cockburn articulates ideas really well, and formed a great story linking what items are essential for software development in the 21st century. On top of this is his great presentation and speaker skills, something very admirable indeed. I also appreciate his humbleness and openness to encouraging others. For example, it’s easy for someone like him to just talk about the work that he does yet he didn’t have any hesitation talking about what interesting work other people were doing, naming them explicitly on stage (something many other people in his position doesn’t do). He really knew the content in the slides, even at the end asking for to jump to content by slide number to bring up diagrams for questions. I also appreciated the fact that he didn’t jump through a generic set of slides, skipping bits that weren’t relevant and spending more time on others. That shows that he at least put thought into how the presentation was going to run for.

After the keynote, another Alistair, this time my great co-presenter, Alistair Jones and I presented our session titled, “Top ten secret weapons for performance testing in an agile environment“. Yes, looking back at it, a bit of a mouthful. We were both really happy with how it went given that the room was almost full and we had lots of questions, both during and after. Admittedly I think 45 minutes was a tight squeeze, however the program’s alternative of 90 minutes would have been far too long to talk for. Thanks to all the people that came along and we’ll be posting the content online somewhere in the near future.

At lunch, I dropped into the Programming with the stars session in the other tower, a fun place to watch different styles of how people approach and present a problem. Well done to all the participants as it takes a lot of courage to step up on stage and put yourself in front of the audience.

Later that day, I went along to the session titled, “What (Else) Can Agile Learn from Complexity?” by Jurgen Appelo that I found pretty interesting only because I’ve been reading more about complexity and chaos and how it applies to everyday life. Pretty heavy technical and term driven presentation yet very helpful for me to see how other people view it applying to software.

This session followed on with the Lean Lego Game by some colleagues, Francisco and Danilo. It’s a great experiential simulation that teaches the concepts of lean that I highly recommend everyone try. In fact, the only pitfall for their session was the fact that too many people turned up, making it difficult for two people to facilitate such a workshop.

Last night (and following through to early this morning) ThoughtWorks hosted an Agile Open Office and helped launch the Agile and PMI initiative to bring those two communities together. If you’re interested working with the PMI, they’re looking for agilistas to meet with a local PMI branch all around the world. I met some really fascinating people and far too many topics to even cover in this time.

Comments(0)

It’s only just past midnight in Chicago however it’s like I’ve had a huge night out in London since it’s the equivalent of half six in the morning. I wanted to jot down some notes around how the first day of Agile 2009 went.

The sessions kicked off from about 11am, allowing people to pick up their registrations pack weighing about of tonne in materials including two full books (one of them admittedly a not-so-pocket sized pocket guide) and some other memorabilia. I attended two sessions throughout the day, one of them titled, Agile Grows Up: The Agile Business Analyst and then Bob Martin’s speech on the main stage about Software Craftsmanship.

Whilst I’m not sure if I came away with anything new, for me it was a nice warm up to the conference with some great discussions and, at least for me, some of the better experiences chatting in the hallways with various people from different areas. The fresher’s fair was a great idea this year. It struck me that most people seemed to identify with only a handful of communities (two to three), whilst I felt very strongly attached to many more (about ten). Perhaps it’s because I strongly believe in developing so many cross discipline skills and a focus on coaching effective teams means connecting many of these disciplines together so often.

It was great to see people that I’d met across many continents and to meet many more new people from all the way. For those that haven’t registered yet, ThoughtWorks are hosting an Agile Open Office tomorrow (pre-registrations required due to building security policies) that I hope to meet many more people tomorrow.

Comments(0)

It looks like I have become a published author along with three other ThoughtWorks‘ colleagues (Adrian Wible, Joe Zenevitch, and Anupam Kundu) in the “97 Things Every Software Project Manager Should Know” book.

I contributed two tips, “Documents as a Means, Not an End” and “You Are Not In Control“.

You can buy it the print or ebook version of the book with a 30% discount via the Orielly.com website, using the code ABF09. Congratulations to all the other contributors to the book, including the author who organised the book, Barbee Davis.

Comments(0)

I’m excited to announce that I will be running my workshop again, Climbing the Dreyfus Ladder of Agile Practices at the Agile 2009 conference in just over a week’s time. This is the same workshop that I hosted at XP2009 in Italy. In addition to this, my great colleague Alistair Jones and I will also be co-presenting an experience report, Top ten secret weapons for performance testing in an agile environment. Hope you can make it to one of these. I’m really excited to be sharing some lessons I’ve learned along the way.

I’m keeping a page from the session here.

Comments(1)

I’m fortunate enough to have recently started back on a project in London* this week. One of the many things that I’ve missed working in London has been access to the variety of communities that you have access to that no other city in the world (even New York City) could ever match. One of the longest running and, and without doubt most influential, on the agile community in the UK is the eXtreme Tuesday Club who celebrated their 10th year of running weekly meet ups in London.

I always find the people there great to talk to and interestingly enough this week there were significantly many more agile coaches than I’ve seen in one place for a while. I hope to be able attend these sorts of gatherings much more frequently now that I’m back in London and would highly recommend this one to any one who happens to be in town on a Tuesday.

Comments(0)

I’ve been working with a large scale legacy system (in the Michael Feathers’ sense). Strangely enough there are a small handful of tests, unfortunately most of them falling by the way side having not been added into an Continuous Integration process. Many of them no longer look relevant, others, unable to run without a specific person’s machine (due to configuration files or special databases). Others look like a mechanism for people to simply diagnose issues with plenty of tracing statements. All of this was an inevitable system without someone running all the tests all the time.

Any serious team serious about continuous integration will think hard about their development testing strategy, considering approaches that allow you to run tests all the time. The strategy needs to consider a good way of preventing side effects from other tests (global state, global configuration, or left over state in external resources) balancing out speed with good quality feedback. Staggering build processes into smaller chunks, such as using build pipelines are a great way of achieving this.

Please don’t let leave your tests to die a sad and lonely death. It will take discipline and effort to keep them running yet the results will often pay back for themselves very quickly on any system with a reasonable lifespan.

Comments(2)