patkua@work

The intersection of technology and leadership

Category: Conferences (Page 5 of 7)

XP2010 Review

June 7, 2010 / / 4 Comments

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.

ScottPage

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.

Entertainment

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.

ExtremeMetal

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.

Build the testing pipeline at ACCU 2010

April 14, 2010 / / 0 Comments

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.

Six Years at ThoughtWorks

March 24, 2010 / / 8 Comments

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.

QCon London 2010 Day 3

March 17, 2010 / / 0 Comments

The pace of the conference and the speakers drinks event on Thursday night meant that I missed the first session on the final day. It’s a shame since I think Joe Armstrong would have been good to listen to. I look forward to reading anyone’s report of that session in the blogosphere.

Track: The Concurrency Challenge – Session: Embracing Concurrency at Scale

I really appreciated this speaker for being very pragmatic and conscious about helping people think more explicitly about tradeoffs. He encouraged people to actively think about what solution is most appropriate considering there is always some trade off.

This session resonated another one of those ideas that we use “models” all the time and that models are inherently limited by simplifying things. As the speaker said, “There are many models in science, all of them wrong but some of them useful.” He used time as an example in that there are many ways of looking at it although we have a tendency to want to structure it linearly. “When you admit time is a difficult problem, you will have problems with multiple actors”.

He talked about the ideas that we like convenient mechanisms (such as distributed transactions) because they’re easy to grok and we’re comfortable with those ideas but because they have implicit state, you’re throwing away the value of distributed systems. He went on to talk about how we’re taught about the goodness of ACID properties (particularly around database-centric applications). The alternative he presents is BASE (Basic, Availability, Soft State, Eventual Consistency). There’s apparently a paper on this found here (ACM login required). He referenced Pat Helland’s alternative definition of the acronym, Associative, Commutative, Idempotent and Distributed.

Once again, he emphasises the importance of making the decision on alternatives an explicit one and there is a real tradeoff. This was yet another time someone talked about the CAP theorem that describes three different system properties but you can only guarantee two of them. It’s great as a reminder and highly recommend you read about it as a refresher.

He talks about the world being Eventually Consistent and that “We shouldn’t try to model a world more perfect than it actually is”. He gave a number of examples of using this in practice, and there are ways to make sure that you try to do this. One such example was a Shopping Cart situation where a service should tell the “stock to decrement by 1” instead of “reduce stock from 99 to 98”. I think this is just another example of good OO (tell, don’t ask).

Track: Solution – Session: Scenario Driven Development

Our own Ben Butler Cole ran this session that attracted a huge audience considering it was running in the Solution Track. Ben attempted to help people understand how to use Scenario based testing instead of alternatives such as exhaustive acceptance testing or story based acceptance testing as the regression suite.

I think the audience were largely sceptical but Ben’s views align very similarly to the things I’ve seen on projects, particularly when doing development using stories. One of the misunderstandings about automated testing and stories is that everyone always views stories as additive. For me, you not only have stories that add functionality, you also have stories that change functionality (replace) and stories that also cause functionality to disappear. I tend to think the set of tests also goes hand in hand – if you’re deleting functionality, you should be deleting existing tests as well, or if you’re changing tests, you should be changing existing tests.

I think part of the problem is that stories are kind of fractal in nature and the scenarios that Ben talked about were like at an epic level (maybe even a use case level). What is interesting is how you go about enhancing, maintaining that scenario over time and how the team works around those scenarios – something we unfortunately only got a taster for in the hour.

I heard a lot of people still come away with lots of interesting insights and I would highly recommend everyone go and listen to Ben speak even if it’s just to hear him present. Totally worth it.

Track: The Concurrency Challenge – Session: Modelling Concurrency with Actors in Java – Lessons learned from Erjang

This session was fairly packed out, I guess given the hype of people working with or wanting to work with Erlang. This presenter’s take was interesting because in order to better understand concurrency and Erlang, this guy decided to implement an interpreter on top of the JVM (instead of simply playing around with the language).

The premise behind his talk was that Object Orientation as a paradigm brought with it plenty of productivity and that Actor-based modelling was going to be the thing to give us the next boost. Whilst I admire his premise, I don’t necessarily agree. I don’t think we’re all that good (as an industry) as implementing Object Orientation. I do think things like the JVM have helped raise the abstraction level so that we don’t need to think as much about the lower level memory management (although you have a memory leak in these languages if you’re not careful).

He spent a long time fascinating all the language geeks with his ability to run a simply Erlang program on top of his project, Erjang (Erlang on the JVM) but I really wanted to hear about the lessons learned from programming instead of the technical details of writing an interpreter on the JVM, something he spent a majority of the time on. I don’t think there were very many interesting bits other than designing parts of a system with different ideas. As he said, “Imagine treating parts of system as different actors with different responsibilities?” to which I was thinking, “That’s what good Object Orientation is about. Treating objects playing different roles with the right set of (small) responsibilities”. Nothing new unfortunately.

Track: How do you want to test that? – Session: Performance Testing at the Edge
This session brought a lot of mixed reactions. I agree that the start of it seemed a little bit commercial, talking about their product and the complexities of performance testing. I like discussing the importance of performance testing for applications because it’s one of those things that are often neglected and really not treated very well. This presenter eventually got around to talking about some of these aspects, but like many of the talks still ended up being fairly late in the talk.

I think that this speaker had a lot of great things to say and although much of it was very common sense, didn’t give people an impression about how they could go about doing it well. They had some interesting approaches to monitoring performance such as running it on the same set of dedicated hardware (that wasn’t even a replica of production). This has a trade off of being able to compare results over time which they had some interesting graphs, although it is at a cost of being a proper representative sample of what the software might actually run on.

I found that some of the good things he talked about were similar to the talk that Alistair and I had, although it still sounded like the performance testing team was a predominantly split responsibility that worked orthogonally to the actual development team. It also sounds like there was a big cultural barrier that they have been trying to break down by getting developers to write performance tests and have some more ownership.

The crowd also had a lot of scepticism about convincing a business to invest in the automation of performance testing.

QCon London 2010 Day 1

March 14, 2010 / / 2 Comments

I’ve never been to a QCon before and being run by the same organisers of JAOO and the folks behind the ever popular InfoQ, I was looking forward to being both an attendant and presenter. Lasting three conference days and two tutorial days, this conference focuses mainly on being talked at – quite a different experience to the Agile 20xx and the XP 20xx conferences I normally run workshops/talks at. Being focused on the cutting edge and practical technologies side, I can really understand this because it’s hard to target people with the right level of experience.

Talking to most of the attendees, it also attracts a noticeably different side with the majority of people already in architect or senior developer roles with a relatively smaller proportion of people in other ancillary roles such as PMs, testers or BAs.

Feedback that works
I like the feedback note for the conference, asking people tweet, email or talk to people at the conference. I think some of the feedback mechanisms even worked as we saw a lack of caffeine/water during the breaks on the first day change for the other remaining days.

The Keynote
The first day’s keynote started with the evangelical Uncle Bob Martin. He’s a great speaker and channels a lot of opinion towards the crowd wandering back and forth on stage. I saw a version of this at the Agile 2009 conference. I’m glad he adjusted it somewhat more appropriately for this conference. He talked about some good principles that should be followed after a few bumpy technical glitches. He is all about the drama (which I guess is part and parcel of a keynote) such as showing us a video that scrolled through a single java class for something like two to three minutes backed up by a song from the movie from 2001 (thanks Ola!) that almost sounded like the flight of the bumblebee. The point of this showmanship was to demonstrate how we can sense bad code visually without even looking at the specifics. He went through a number of his mantras such as “The Boy Scout” rule, leaving things better than how you found them, or that functions should be no more than four or five lines long.

Whilst I don’t think I learned anything new, Uncle Bob Martin was entertaining and had good things to say, despite how preacher-like he comes across.

Track: Architecture’s You’ve Always Wondered About – Session: BWin – P5 a future proof poker platform
The rest of the day was split into six different tracks. I went to the first of these and was truly disappointed. The two presenters came from BWin, apparently one of the largest poker and gaming sites in Europe. They spent half an hour talking about their problems of performance (many of the -iliites) and where the history of their application came from. They even had to include a three minute video from their marketing folks. They finally flashed up a screenshot of their architecture diagram which I think everyone had come to hear about it. Unfortunately they moved onto the next screen very quickly and said that they couldn’t actually talk about their architecture. How disappointing! Indeed this might have been an “Architecture You’ve Always Wondered About”, and after this session was one to still, indeed, wonder about it.

They proceeded to pick a single example about two processes that concurrently wrote and read from the same database table and their architectural change simply transitioning it to a disk persistent queue and the reporting service reading from that queue and writing to its own database. Neither very profound, or a very interesting tidbit that failed to give the audience any more insight into any interesting part of how they architected their system.

I found it interesting they spent a long time (something like 250 man years) rewriting this version of their architecture so I asked the question about how they went about moving from their old to their new platform at which they pretty much described a big bang approach – neither iterative or incremental. Pretty disappointing.

My lesson learned from this: Regardless of how pretty your slides are, make sure your abstract matches what you’re going to actually talk about.

Track: Dev and Ops: A Single Team – Session: Devs and Ops Cooperation when the Worst Happens
My next session was much more fulfilling with Michale Nygard (author of Release It) describing some of the stories that were the basis for the book but wouldn’t have been publishable. Michael is really down to earth and happy to chat about many of the details behind the book. It’s really obvious that he is also a very pragmatic person, understanding that models are just that and recommending people look into the details because there is often something much more complex underneath.

Many of the things that Michael talked about also resonated very strongly with ideas that I’ve seen on applications. Many of them included focusing on ensuring documentation artefacts should be tested by those who will consume them. As he put it, “UML is virtually useless to the deployment and operations team”. Other gems included, “From a high enough view, everything starts to look the same”

His stories also reinforced the importance of having a ubiquitous language will all members of the company in the shared domain. One of his most successful rescue missions dealing with a production problem only worked because the architect (on the dev side) and Michael (on the ops side) understood enough to really communicate the real problems. Michael also kept (understandably) hammering home the point of lack of information on both sides really hurts the problem solving process.

A lot of Michael’s stories also described their successes working around the existing (organisational) systems in order to deal with the problems at hand. To me, this was just another great example of organisations that structure themselves for efficiency over effectiveness.

I like the way that Michael finished off his talk as well, focusing on the fact that you’re not just trying to build software, that you need to care about the organisation (and I would also argue, the systems and procedures in that organisation) that support the software. Design them for effectiveness, not efficiency.

Architectures you’ve always wondered about: Facebook
The next session I attended was by Aditya Agarwal (one of the engineering directors of Facebook). He shared some great insights and lessons learned into what things Facebook did that got them to where they were. Admittedly they had some strange choices like writing something that converted PHP into compiled C++ and using MySQL is a very “reliable bitstore”.

They have a lot of great things to say, like being very proud of the low number of engineers ratio to actual users. Like Alistair, I’m puzzled why they’re secretive of the exact number of their employees.

Aditya has some good things to say and although he means well, I don’t support everything that he says. it’s obvious a lot of what he says is based on a start up culture. Things like, “don’t worry about it until it becomes a problem” encourages the recklessness we see in many software companies. Same thing about the choice of programming language such as “every programming language will have problems at our scale”.

On the plus side, I was pleased to hear them encouraging the innovative engineering culture that I don’t see in many organisations.

Track: Non relational DBs and Web Oriented Data – Session: Social networks and the richness of data: getting it done with
After going through my notes the most interesting tidbit was about using a partitioning mechanism to deal with data updates based on the number of connections. There was plenty of buzzwords (both internal and external) that I think I had a hard time fitting it all together. Some things I’m going to look at include:

  • Bit versus bloom filters – Not familiar with this term or how to use it.
  • Tools – RESTeasy (I now see it’s a JBoss project). Redis and Voldemort – something they used heavily all over the place.

That’s about all I got out of this session though I’m not sure if it was about the lack of familiarity with the tools, or the excessive use of acronyms and unfamiliar terms or just plain tiredness.

Track: Functional Programming – Session: Demystifying Monads
Josh Graham did a great job stepping into fill in for his ill wife talking through some of the different ideas behind monads. I haven’t done functional programming since university and I’ll be the first to admit Monad’s are still a mystery to me but I came away with some key learnings.

Firstly, to understand monads properly, you really just have to see several examples in action. There’s a high barrier to entry because it means:

  1. Learning a new language
  2. Learning a new development environment
  3. Playing with plenty of examples

When I find some time, I’ll do those. In the meantime, I understand a bit more about the properties of a monad, and that they can be a powerful abstraction for functional languages.

Final keynote – Dan Ingalls: Forty Years of Fun with Computers
For being so late in the day, this was a very entertaining keynote. Just like any modern day small talk person, this entire demonstration took place in the Squeak development environment. Dan demonstrated some interesting and interactive elements.

I had a few key takeaways including:

  • We’re really bad at learning the lessons from the past. Partially because we don’t have enough storytellers and that our generation doesn’t listen very well.
  • I’m going to read this article at some point.

Limitations of the Dreyfus Model

February 2, 2010 / / 4 Comments

Last year, I ran a workshop at XP2009 and Agile 2009, helping people map behaviours to the different levels in the Dreyfus Model. Being a workshop for only 90 minutes, we only had time to introduce the model, generate a set of behaviours mapping them to each level in the model and only a small fraction of time thinking about where this might be useful in a coach’s toolbox.

I tend to use it as a way of encouraging people to self-assess their own behaviours, and as a way of seeing concrete, specific sets of behaviours that people in more advanced stages might find themselves.

We didn’t really get an opportunity to discuss the limitations of using the model in this way (remembering that all models are inherently limited in some manner).

Most useful for Novices
Ironically enough, this set of behaviours mapped in this way is only most useful to those who still remain Novices and less so, the Advanced Beginner. Novices need concrete rules, and directions. Advanced Beginners start to see context, yet it’s often helpful being specific about what sets of behaviours you might see at different stages.

Ironically, as you progress, using the Dreyfus Model in this way becomes less useful as you progress. I like to introduce this set of behaviours after people have had some experience with a certain practice. It helps people answer the question, “What does good look like?”

It’s not an exhaustive list
When I’ve run these workshops with other coaches, I find it interesting to see how they notice different sets of behaviours from what I would observe. Even when looking at a single practice, you have a multitude of behaviours at lots of different levels. It’s preciseness at describing specific sets of behaviour also has the risk of people only focusing on the prescribed behaviours instead of thinking about the sorts of behaviour that sits at this level.

I can’t imagine trying to list every single set of behaviour. As interesting as that might be, I think it would be impossible to capture, and difficult to communicate succinctly.

Best for personal development, not as performance evaluation criteria
It’s easy for managers to see a list of different levels, and then attempt of fit people into a box for performance evaluation. As much as their intention might be good good (professional growth) I think it’s easy to game.

I like to emphasise that this model is best used as a way for coach’s to help people self-assess, and for people to set their own goals about where they want to be.

Not the only tool to use
I like using this tool as a transitional tool, helping people jump the gap from Novice to Advanced Beginner and from Advanced Beginner to Competent. Beyond that, I would use less of this tool and look at other tools that help people self discover their information.

Agile 2009 Session Results Posted

September 16, 2009 / / 1 Comment

It’s been a few weeks and I’ve finally had a chance to go through all the photos and sticky notes from the “Climbing the Dreyfus Ladder of Agile Practices” workshop I ran at Agile 2009, as promised.

For those that didn’t get to attend, I asked five groups to pick one agile practice out of 12 choices and brainstorm specific behaviours they had observed people participate in. Based on their brainstorming, I then asked everyone to categorise them according to what different level in the Dreyfus Model of Skills Acquisition.

I found it fascinating to see firstly, what behaviours people witnessed, and even more fascinated by the way that groups then tried to classify them. Follow the link above to look at the results.

Agile 2009 Day 3

August 28, 2009 / / 2 Comments

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.

Agile 2009 Day 2

August 26, 2009 / / 0 Comments

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.

Agile 2009 Day 1

August 25, 2009 / / 0 Comments

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.

« Older posts Newer posts »

© 2024 patkua@work

Theme by Anders Noren — Up ↑