As explained in my last post, I chose to attend the academic track, with the practitioners track being filmed, to be watched later.

The academic track involved presentations of numerous studies related to the application of Agile methodologies in the work place, generally trying to evaluate whether Agile principles have a quantitative impact on the development process.

Participation Balance in Pair Programming

‘Participation Balance in Pair Programming’, was the first session, presented by Laura Plonka, who I had previously met at last years XP Day 2010, and had joined in a discussion of our pairing practises at Codeweavers.

Pair programming during development tasks typically involves one developer controlling the mouse and keyboard, while the other developer keeps an overall idea of the task at hand, advising on the course of action the pair takes. This pairing is usually equated to  Rally driving, where the person at the keyboard is the driver, concerned primarily with producing valid code, while the ‘Navigator’ keeps the map in mind, and advises the driver of directions for the road ahead.

The big difference is that during pair programming, it is very easy and often useful for the roles to be swapped mid flow, something I’ve never seen in a rally.

This is the premised on which this research was based; that is it preferable for developers to have an equal contribution in a programming session terms of both time driving and verbal contributions throughout the session.

The results quickly indicated that pair programming sessions were very rarely even close to equal, both in terms of time driving and verbal contributions, which I would say is fairly representative of pairing at Codeweavers.

Reasons for uneven contributions

The study then looked at reasons why the pairing contributions  may be uneven, and found several factors such as:

Workstation ownership; A person working at their ‘own’ desk, may have a preference for driving because they are more familiar with the desk, and the machine has been personalised to their preference, including specific software and even development environments in some cases. In our case, we try to keep a standard development environment, so developers have no preference of workstation.

Difference in Skill/Confidence;
Typing speed, confidence and experience may lead to a preference for a particular role, with motivated, experienced developers preferring to drive, while inexperienced developers with low self-confidence may prefer the navigator role as it is stressful to write code with someone watching. Inexperienced developers may also be aware they are slowing the session down, and so prefer to let their experienced partner drive.

Personal Preference and Work Style;
Developers may have different approaches to development which can cause a preference in roles, where one developer may employ trial-and-error, another may perceive this as frustrating, preferring to read through and understand code first. These frustrations increase the likely hood of one developer ‘tuning out’ during the session

Implications?

The next question the study attempted to answer, is what these finding meant, what are the implications of imbalanced pairing?

The researchers also asked the developers on their opinion of how well the session went, and found no correlation between perceived successful sessions and equality of contribution, which is something I would agree with from personal experience.

While I am aware that most sessions are not balanced, some of these uneven sessions have involved driving while an experienced driver watches over, with only occasional contributions, in fact sometimes the lack of interruption from an experienced navigator can be a big confidence boost, while still providing the safety net of experienced eyes covering the code I’ve produced.

Conclusions

So should we strive for equal contributions in pairing?

I think having seen the results of this study, and my own personal experience, I would say that while equality isn’t essential, it is certainly preferable, as the pitfalls of pair programming such as navigators ‘tuning out’ and loosing attention, or drivers following instructions without thinking what they are doing, are both problems addressed by alternating the roles throughout the session, in fact one of the techniques we employ at codeweavers is ‘ping-pong’ pairing, where developer 1 writes a red test, then hands over control to developer 2, who implements code to fix the test, then writes the next red test, and returns control to developer 1.

And when new developers arrive, we employ the ‘inexperienced developer drives’ idea, to engage new developers immediately, and hopefully encourage contributions and social interaction early on, so while I feel equal contribution during a session should be the goal, it isn’t the goal of pairing, so sessions should be judged on the benefits we look for in pairing, i.e. knowledge sharing, increased code quality and better development experience, rather than how even the contributions were.

Next:

Integrating Agile Development and User Experience Design: An Achievement In Practice

Since starting at Codeweavers Ltd last year, I have now attended 3 software development conferences, but my experience has varied significantly:

XPDay 2010 in London was a 2 day conference with an enthusiastic, bordering on religious, zeal for the Agile approach to software development. Despite this, I found it refreshing, motivational and very educating, returning to work with lots of ideas that are still with me now.

The single day Software Craftmanship 2011 at Bletchley park covered more practical software development ideas, however, was not as enjoyable for myself, which I believe is largely because I selected sessions based on what I thought I should attend, even if for the sake of the team, rather than what I wanted to. I’m glad I attended, but I found I learnt a lot less than I had at XP Day (about software development that is, as I did learn a lot about the history of the cracking of the Enigma code) and didn’t gain as much motivation and enthusiasm.

And so, when @CodeweaversLtd allowed me to attend Agile North 2011 in support of my brave colleagues, presenting an update to their successful ‘Chaos to Kanban’ session last year, I was somewhat cautious, but the fond memories of XP Day were enough for me to give this a chance. My grandmother was saved from yet another short notice ‘Family emergency’ inducing funeral that would prevent my attendance.

So, after a swift trip up the M6, expertly piloted by @BlueReZZ, and after a complete lap of the site to find the car park entrance, we arrived at UCLAN‘s Foster Building.

UCLAN’s Foster building was a good choice as a venue for a conference, with several conference rooms and a large canteen (primarily for patrons of the attached leisure facilities I believe). The conference rooms were roomy, with suitable shading for the many projected powerpoint style presentations, and the bacon buttys were very welcome.

The attendance was better than suggested by the small and partly empty car park we observed on arrival, with most sessions being well attended without being overcrowded. The first test of this being the Practitioner Karaoke, where the speakers from the practitioners’ track (and only the practitioners’ track for some reason) could give a brief sales pitch for their session.

Agile North featured the ‘track’ system, common to my previous conference experiences and probably most others, where the event were split between 2 tracks (Practitioner and Academic) in different locations, running in parallel timeslots throughout the day with larger introduction/closing sessions running uncontested (much like Sepp Blatter). Unfortunately this means having to miss around 50% of the sessions, but in this case Codeweavers media wing, Big Table, were in attendance to record the practitioner track, leaving me free to attend the academic track without regret.

But before splitting into the separate tracks, we first had the keynote address from Dot Tudor:

Agile Transformers by Dot Tudor

In this session, Dot Tudor of TCC and the sponsoring DSDM Consortium used Optimus Prime and Megatron, leaders of the Autobots and Decepticons respectively, as examples of different leadership styles, introducing the AllSpark, which gives the bearer incredible power to use at will, as an analogy for self-organising,  laissez-faire team management. This was very interesting, and I think most people would be able to spot elements of 2 or all 3 of the styles in leaders they have worked under. The talk then moved on to how to spot good/bad leaders, and introduced Agile/DSDM qualifications as a ‘weapon’ for revealing unwanted Decepticon style leaders. This did lead to some discussion of what having a qualification actually means; does having an ‘Agile Project Management’ qualification mean that a person is automatically a good Agile Project Manager?

This discussion actually linked quite well with the last session at Software Craftmanship on Personal Codes of Conduct, which lead into a heated discussion on whether qualifications should/could be required to call someone a Programmer. Personally I remain undecided, qualifications only tell you that someone can pass a specific exam/course, and provide no guarantee of competence, however, courses I have been on have been very beneficial, and I believe have improved my skills in a professional capacity, and I would still lend weight to the opinion of some possessing a credible qualification in a subject area, rather than whoever speaks loudest. I also would rather be treated by someone medically qualified than someone who just says they are doing what is best (I’m looking at you, homoeopathy).

My overall feeling of the session, other than a desire to watch Transformers 2, was that while it did raise some interesting questions, and make some good observations, it did feel a little like a sales pitch for DSDM qualifications, probably not surprising with TCC/DSDM consortium being a sponsor, for which they do deserve some credit.

At this point, I chose to take the Academic track for the next session, on which I ended up staying for the whole day…

TBC…

Codeweavers @ Agile North 2011

Following our successful talk at last year’s event we were invited back to Agile North 2011 to present a second instalment in the Codeweavers Agile journey. We’ve taken the key changes from a paper we’re writing and organised them in a 40 minute presentation for the practitioner stream at the conference. Information about our previous paper and presentation can be found elsewhere on our blog.

The Paper

Four of our current team, and one ex-team member are finalising a chapter for an edited book titled: Agile and Lean Service-Oriented Development: Foundations, Theory and Practice. This will be published by Lero, the Irish Software Engineering Research Centre later this year. We’ll publish our chapter on our blog so check back later in the year and keep an eye on our twitter stream for announcements.

The Slides

I’ve made the slides available via Google Docs https://docs.google.com/present/view?id=dg7kxgdk_161cbm8mrfq.

If you want to see the speaker notes too or can’t get Google Docs working then you could also try SlideShare: http://www.slideshare.net/paulshannon/from-chaos-to-kanban-episode-ii

The Video

Thanks to our partners at Big Table we now have a full HD, professionally shot video of the talk. There are also other videos from the conference on AgileNorth’s YouTube page but for us, I’ve embedded them for you here:

Feedback

We’re really grateful the for positive feedback that we received, as it spurs us on to continue improving our practices and also producing new presentations and papers for the community. Thanks to the organisers of Agile North and the other sponsors too for providing such a great platform for our contributions – we’re all looking forward to next year already.

Our very own Ronnie Lawson has started a “saga” of blog posts on his experience at Agile North, which has an interesting take on the event, and my driving ability.

I’ve seen some feedback on twitter recently too but would invite any comments, good or bad, on this post.

It was the Agile Cambridge conference last week and unfortunately we weren’t able to send anyone to attend, so instead I’ve been following it on Twitter (#agilecam). The reactions came first, via tweets from people in the sessions, then the slides, and now we’re getting photos from workshops and videos from presentations.

Creating Agile Workspaces

Most of the sessions were of some interest to us here at Codeweavers Ltd but one in particular stood out because of our impending move to our new HQ in a converted barn. The session was conducted by Rachel Davies and John McFadyen who asked the attendees to share their experiences with working in Agile Workspaces.

Heaven and Hell at Codeweavers

After reading the slides and looking at the snapshots of the flip charts from the session I thought it would be good to take 10 minutes on Monday afternoon to present them to the team here, and ask them to consider their own points about working environments. I mainly concentrated on coming up with ideas for “Heavenly” and “Hellish” workspaces and asked the team to come up with a few points each so that we could reconvene next week to discuss things we definitely wanted at our new offices, and things we definitely wanted to avoid.

We briefly discussed the points that had been recorded in the workshop and found some parallels with our own opinions and with things we’d changed over the last couple of years. The first item on the “Hellish” list was separation which is a concern for us at the moment and one of the main reasons we’re moving. The current office has two large rooms; a development room and a room for everyone else. In the new, open-plan, barn conversion we’ll all be together with plenty of space to meet and mix. Temperature too is also being addressed by our new air conditioned offices and a new addition of a chill-out room will certainly benefit current employees whilst also helping to attract potential new team members. It was great to see that our concerns were quite common in the Agile community which gave us good reason to come up with new ideas.

Next Steps

One of the resources mentioned in the presentation slides was a blog article about a similar “refactoring” of an Agile space at Digg. The key point I took away from this is that things that work in theory, and for other teams, might not necessarily work for our team. At Digg they thought the concept of quiet areas, or caves, would be popular for developer pairs who needed some isolation but found that the devs preferred sofas in the communal area. They invested in nice desks with 30 inch screens too, but the majority of development time was spent on a laptop, on a sofa.

All this leads me to think that we just need to keep an open mind, try things out, and not be scared of changing anything. We need to ensure that anything we do isn’t irreversible or adaptable so that we can keep moving forward to get the best environment we can. We are quite good at adapting our processes and Kanban boards so I’m sure our workspace can follow suit now that we have more flexibility.

I’ll post again with the results of our own workshop next week and then with anything poignant when we actually move.

At this month’s XP Manchester meeting I was asked to lead a discussion on Code Smells. As we’re constantly trying to improve our code through refactoring code smells, this turned out to be something I knew all about.

Download the Slides

Firstly, the slides I used, including code screenshots used in my explanations, are in my shared Google presentation.

Books

The books I had with me were:

• Clean Code – Robert C. Martin
• Refactoring Workbook – William Wake
• Refactoring – Martin Fowler

We also have a recommended reading list that contains some great resources that I didn’t have the strength to carry with me to MadLab last night.

Resources

Smells, refactoring etc – google and the wikipedia article are also pretty useful:

• http://c2.com/cgi/wiki?CodeSmell – Well known Agile/XP wiki with information and discussion
• http://sourcemaking.com/refactoring - A well designed and very usable site with good content
• http://www.codinghorror.com/blog/2006/05/code-smells.html - My quick reference, go-to list of smells
• http://www.industriallogic.com/papers/smellstorefactorings.pdf - Suggested to me by a colleague, this is a printable version of common smells

Other Topics

I also mentioned a couple of related topics that were of interest to us at the moment, but would also suit some further reading for people looking at improving their code quality.

• J.B. Rainsberger’s Mars Lander post about Integration Tests being a scam – a great, feet first, introduction to collaboration testing using mocks and verification
• Josh Kerievsky on The Limited Red Society and his company Industrial Logic that use a clever tool that charts when you are red, “pink” and green during TDD