It is not often that you get the opportunity to get involved with an event on the scale of Global Day of Code Retreat (GDCR). On Saturday (3rd December, 2011) an estimated 2200 software developers gathered in more than 90 cities around the world to solve a relatively simple computing problem. The objective was to implement Conway’s game of Life.

The game has a simple set of rules, and has been implemented countless times since its creation in 1970. You might ask why it takes 2200 developers to solve this problem. There might be a clue in the method used to solve the problem …

The Process

At a code retreat, the participants are divided into pairs, and attempt to implement the game in a 45 minute time slot. The twist is that even the fastest coders will not get to the end of the challenge in that time. Once the allotted 45 minutes expires, the whole process starts again – another 6 times. You might be thinking, why would anybody do this? Why would 2200 developers do this? Starting at 8:45am on a Saturday morning!?

Another clue is that the London event was organised by the London Software Craftsmanship Community (LSCC). The London chapter is part of a global movement of software craftsman who believe that:

“As aspiring Software Craftsmen we are raising the bar of professional software development by practicing it and helping others learn the craft”

[Taken from the Software Craftsmanship Manifesto]

So then, the GDRC is about repeating the same exercise several times in a day and the LSCC believe that helping others improves the craft. Armed with this information it becomes clear that Conway’s game of life is not the aim of the exercise, just a means to an end. Indeed once each session is finished the code is deleted – erased with no trace. It is the journey of developing a piece of code six times in succession that stops the participant from being focused on completing the exercise, and allows the focus to shift to the process of writing the code. To draw parallels with meditation is perhaps a stretch, but it does allow an opportunity to be more reflective about the code being written.

Constraints

Each time the exercise is repeated, different constraints are added to the development process. This forces the pair to consider a different strategy for implementation of the problem.  Amongst the constraints used are: 4-rules-simple-design; object calisthenics and mute. The easiest to explain is mute, which mandates no communication between the pair developing the software, with the exception of the code written. This communication ban forces the developer to produce code where the intention is clear – so called ‘self documenting code’.

Global Community

The Code Retreat day is repeated by isolated groups throughout the year. The idea of the Global Day of Code is to build a bigger community with more participants, have some fun, and to generate some publicity. With the event being run during a weekend, it is a great opportunity to meet a broad spectrum of people outside of your usual work team.

In practical terms, this meant sharing information with other events using twitter (#gdcr11), and three video conference sessions. It turns out that connecting two remote rooms full of software developers in meaningful exchange has its own challenges, both in terms of technology and raucousness!

For more pictures, visit our Facebook Page: www.facebook.com/ValtechUK

Free to Enter

The code retreat is run by volunteers, and paid for by sponsors. Valtech is proud to have hosted and sponsored the LSCC Code Retreat in our London office because we fundamentally believe in the principles of software craftsmanship. A big thank you is due to Corey Haines, who was one of the originators of the Code Retreat concept and chief organiser of the Global Day of Code Retreat.

Also thanks to Sandro Mancuso and Samir Talwar from the LSCC for facilitating the event. The smooth running of the London event is in no small part due to Valtech’s own Maria Lacher for a marvellous effort co-ordinating the essentials such as food and venue.

 I look forward to Global Day of Code Retreat ’12 – with experience gained from GDCR’11, it  should be the biggest and best yet!

Video

http://www.meetup.com/london-software-craftsmanship/

Samir’s in-depth overview of the event (warning – contains code!):

http://coderetreat.org/profiles/blogs/global-day-of-coderetreat-an-account-from-london

I’m going to be speaking at the eCommerce Expo on the subject of Facebook Commerce on October 11^th at London, Olympia – you lucky people

My subject is “Simplifying Facebook Commerce” and I’ll be building on Valtech’s recent article published in The Guardian newspaper. The emphasis will be on putting the customer at the heart of planning and the tools, techniques and approaches that are necessary to build platforms on a people centric platform such as Facebook.

My presentation will be aimed towards business managers and those responsible for making money from on-line customers.

If you wish to register to attend then click here. If you’re already socially clued up then maybe you’d like to recommend a friend on Facebook would like to attend by clicking here.

Agile methods are of clear benefit while our projects are small enough to be delivered by a single small team responsible for the full life-cycle and incorporating all of the various necessary specialisms. As the project size increases we will eventually reach a state where we face a challenge since the team size becomes increasingly difficult to manage and we seek to provide internal structure through sub-teams. At this point we will typically need to establish the axis along which the team is split.

Option 1: Component orientation
In a large systems it is common to find developers who align themselves to components. This presents a simple option of splitting the team along component lines. By doing this we create a need to split user-centric features into component features and subsequently re-combine and verify the end-to-end behaviour.

In this way we have benefited from natural affinity of developers to components at the cost of lead time. The benefits of this approach will depend on the degree of specialisation and the degree to which specialisation aligns with co-location; this ownership of components by location is common in large systems development organisations. A further drawback, however, is the balance of features to components, it is not uncommon to see feature prioritisation determined by availability of component teams in preference to value, increasing the degree of generalisation increases a teams flexibility to build the next most valuable feature independent of the impacted software component.

Option 2: Discipline
By splitting a team by discipline we risk longer lead times and can easily risk further engraining waterfall like thinking such as stove-piping the organisation with a “throw over the wall” attitude.

However, all is not lost. Kanban systems have been shown to offer a model that recognises the existing flow of work while encouraging innovation to reduce lead time of features. Kanban systems have also been used successfully with teams of up to 50 people, considerably larger than the norm for Scrum or XP teams.

Option 3: Location
Co-location is known to be a strong influencer of team effectiveness. With this in mind it would be naive to ignore location in a discussion of team forming. A co-located team would be expected to out-perform a dispersed team where all other aspects are equal. However, dispersed teams can be used to good effect in order to leverage benefits of feature teams. In this situation we should learn the lessons of those who have successfully built effective dispersed and distributed teams.

Option 4: Feature
The preferred model for team structuring in most Agile methods is to orient teams around delivery of customer valued features. This model encourages increasing levels of generalisation according to the profile of the features being delivered by the team. While integration issues can still arise with feature teams the use of continuous integration will mitigate risks while feature selection can help to limit interaction between teams. Where the project size is very large or the problem domain very complex it is possible to orient feature teams around areas of the problem domain. This is what Craig Larman terms Requirement Areas. By allocating teams to requirement areas we support the team in developing their understanding of the problem space investing in specialisation on that axis in preference to specialising in a discipline or component.

Choosing and Blending
In practice we will typically mix these models in a large multi-location team combining the benefits of co-location, feature orientation and component specialisation while trying to manage the limitations of each. By way of a practical example consider an embedded system distributed across the globe. We may choose to recognise the specialisation of the team that develops the low level board support packages; this team delivers low-level facilities to feature teams. We lean towards feature teams for the majority of user-feature development. However, for high volatility or high risk features we might choose to have co-located feature teams in the vicinity of our key customer groups. This focuses the agility of co-located teams where it adds the most value.

Launching a Facebook Store is simple. As an individual or small business you can build a rudimentary store for free with services like www.facebook.com/payvment.

Larger companies and organisations, however, should consider more powerful implementations, primarily to personalise the customer’s experience and drive sales performance. There is little point in bespoke building Facebook store functionality, particularly when there are excellent applications available which are great value for money and can be configured easily.

Here is Valtech’s vendor checklist to help you evaluate 3rd party products and select the right product to support you in implementing successful F-Commerce initiatives:

• Depth of Commerce Functionality – ability to provide sub-systems for selling online across multiple channels with easy to use tools for the management of catalogues, customers, discounts, orders (including fulfilment and returns) and reporting.

• Editorial Control – ability to give business users the control of the layout of multiple sites/channels. Provide people with the power to change the layout of the commerce and other components and content on the page without needing intervention from software engineers.

• Authorisation – if you plan to sell a wide range of products, or operate multiple brands across dedicated Facebook store fronts, or differ propositions by country, then workflow controls to ensure that content changes are reviewed and authorised by the pertinent people before publishing are important.

• Personalisation – a personalisation engine that enables you to profile persona groups around Facebook criteria like categories and gender and to show personalised content to customer groups is really useful. The ability to utilise Facebook “social graph” unique user profile information and provide a personalised experience for each individual customer is also important.

• Ease Of Use – editors will find it easier and more intuitive if they are able control content, layout and personalisation features of the Facebook application in situ in Facebook.

• Always Social – word of mouth recommendation is key to successful social commerce. Ability to automatically syndicate customer reviews from other web-sites directly onto your Facebook walls will drive the power of social commerce.

• Measurement – inspect and adapt and do more of what works and learn from mistakes. Integrated ability to measure the effectiveness of your F-commerce personalisation strategies, choices and changes is essential.

Above all, however, remember that you do not need to unleash all the features at your fingers tips from day 1. You should be guided by what your customers need and roll out functionality accordingly. Selecting the right 3rd party product up-front will give you the confidence that you will be able to meet emergent need both quickly and well.

Like us on Facebook (www.facebook.com/valtechuk) to get updates, news and best-practices from our experiences implementing our own F-Commerce shop.
by Jonathan Cook, Head of New Media at Valtech UK

A few months ago an article was published in Computer Weekly where corporate IT Lawyer Alistair Maughan, argues the case that Agile will not work in Government projects.  I didn’t see this article when it was first published, but it was brought to my attention when a colleague noticed that one of the comments arguing against the article, referenced a presentation I gave.

Many thanks to Francis Fish for referencing my presentation where I discussed introducing Scrum on a UK government project and used Agile methods to rescue a failing waterfall project, again within a UK government programme of work.  I’m really glad my message got across despite the ropey presentation, although in my defence it was my very first attempt at public speaking.

I’ve been working on UK government projects for over 10 years. During my initial 5 years on government accounts I was part of Valtech teams using RUP and aspects of XP, the later 5 years I was fortunate enough to implement Scrum and Kanban on my projects.  With my Agile UK government experience I feel I am justified in challenging many of the misconceptions mentioned in the article.

Firstly, mismanaged projects will go spectacularly wrong independent of the project management framework.  Projects fail for many reasons including ill-conceived requirements, poorly skilled developers, inept management as well as inappropriate SDLC.

So to address some of the points in this article:

“But Agile simply won’t work in the real world of government ICT.“  This is not true, Valtech have implemented a number of successful projects using an Agile SDLC on different government accounts.  Often Agile methods have been used to “rescue” otherwise failing projects but increasingly the merits of running a project using an Agile approach from the outset have been accepted.

“We need a Richard Dawkins to bust the myth of the Agile gospel.”  We need to bust the myths of Agile, that Alastair has heard and believed.  Agile does all of the same value adding activities found in a waterfall project, just at an appropriate time, for example User Acceptance Testing when the real requirement pops out during development rather than right at the very end.  This approach increases the effectiveness of risk management enabling us to make better choices over the life of the project ensuring on-time delivery if (and only if) this is the most critical measure of success.

“Under Agile projects, you pay a given amount of money for a set amount of effort. But you can’t guarantee a specified outcome for a specific price.” You can guarantee an outcome by controlling the richness of the implementation.  A key differentiator of Agile methods when compared with more traditional approaches is the focus on outcomes in preference to outputs.

“Departmental budgets are managed very tightly” Agile enables much more detailed and accurate planning at the appropriate time, using prioritisation and identification of the richness of the solution that is acceptable to the stakeholders. With the added benefit of being able to more accurately account for the overspend as soon as it happens and justify the reduction in richness when appropriate.

“Agile can’t give you a clear specification of outputs up-front.” Neither can Waterfall, the chances of change is too high while the procurement proceeds, this says more about government procurement than Agile.  A well executed Agile project will provide sufficient specification at the right time to satisfy stakeholders.  It is not an issue of Agile projects rejecting documentation (or specification), rather that, when done well, they defer detailed specification to reduce exposure to late breaking changes or lessons learnt resulting in rework to the specifications.

“As if that isn’t problem enough, Agile offers insufficient means of remedy if things go wrong.” It’s a contractual responsibility not the SDLC to offer remedy.  Further, an Agile project should provide evidence of progress in a far more tangible manner. Valtech (and many others) have been working hard to develop contracts that deliver the flexibility in scope that customers deserve while acknowledging the suppliers responsibility for the management of technical risks and the intrinsic qualities of the product.

“You can have an ICT project with a watertight contract, clear deliverables, openly and legally procured, with a fixed price and appropriate remedies if you don’t get what you want.” Waterfalls might deliver what the customer wanted at the time of specification but rarely what the customer needs; as has been often quoted, 40% of features delivered by waterfall projects are never used   (Gartner). The act of insisting on a full specification of everything to deliver will actually make projects bigger. This is a natural consequence of the penalties traditionally applied when new scope is added late. By contrast an Agile project will be accepting changes in scope while encouraging challenge to “gold plated” solutions preferring “good enough” (but no less!).

Please find links to my presentation slides on implementing Agile on Government projects.

http://www.slideshare.net/valtechuk/agile-adoption-in-a-waterfall-environment

http://www.slideshare.net/valtechuk/agile-project-rescue-in-a-waterfall-environment

Simplifying Facebook Commerce Strategies” by Jonathan Cook

Marketeers have long benefited from harnessing word of mouth recommendation among Facebook’s 700m global users.  The current challenge is to monetise this relationship with people directly.

 

Valtech’s top tips for successful F-Commerce:

For every step you take towards mastery, your destination moves two steps further away. Embrace mastery as a lifelong endeavour. Learn to love the journey.

–George Leonard, Mastery

It is with a mixture of sadness and excitement that I would like to announce that, after over five years, I’m leaving Valtech on the 18th of May. The decision was not an easy one and took me months to figure out what the next step in my long road would be. As I said in a recent interview, I love working for consultancy companies and that’s the main reason I spent over ten years (two-thirds of my career) working as a consultant.  

Working for Valtech

Valtech is a fantastic company to work for and had a huge impact in my personal and professional life. During my time there I had the opportunity to work on a great variety of projects, different companies, different industries and different technologies. Most importantly, I had the opportunity to meet and work with a lot of great people that helped me to become a much better professional.

If there is one thing that I will never complain about Valtech is that I did not have recognition for the work I’ve done. I have started at a Valtech in a relatively junior role, according to Valtech’s grade scheme, and bit by bit, with a lot of support and trust from my colleagues I was given more and more responsibility and gradually climbed my way up to one of the most senior positions.

There is no such a thing as a perfect company but if I had to point out the best thing about Valtech, I would say that, beyond the shadow of a doubt, it is its people. People that I learnt a lot from, that helped me to feel at home in the UK, that helped me with personal issues, people that challenged me, that pushed me to my limits, that gave me constructive criticism, that trusted me and empowered me to do my job, people that helped me to be better.

I may not be in the office or in a client site full time any more but I will always be around. As it happened before (I took a year off to work on a startup idea and came back) I’ll always be around for drinks and events.

Special Thanks

I would like to thank you everyone at Valtech that had to put up with me for all this time. I know I can be a pain in the neck quite often sometimes.

It’s always tricky to mention names since there is always the risk of people left out feeling a bit upset but I feel that I need to thank some people in a more personal level, so apologies for the ones I did not mention. In no particular order: Toby Mckenzie for caring about me and every single consultant during tough times, all his herculean effort to keep every one happy, finding us good projects; David Draper for challenging many of my beliefs and opinions, for the many advices, for supporting my involvement with user groups and events and for the effort in making Valtech a place of excellence; Mashooq Badar for the fantastic time we had together in many projects, for all the things I learnt from him and for making me open my mind about so many things. Ah, and for all the Blazing hot! moments; Phil Hall for the support and keeping the doors open to me and LSCC; Kevin Harkin (I can’t believe he does not use twitter) for the fun we had together, for his friendship, advices, ranting sessions and memorable nights at the pub; Andrew Rendell for his professionalism, trust and for being a great role model for every Valtech consultant; And last but not least, Akbar Zamir, for pushing me and challenging me to be better, for all the advice, trust, knowledge and help, for being a great career manager and most important of all, for being a great friend.

Thanks for the great five years that I spent there. It was an absolute pleasure to work with all of you and be part of this great company.

The Future

It’s not just a question of conquering a summit previously unknown, but of tracing, step by step, a new pathway to it.

–Gustav Mahler, musician and composer

I’m joining UBS as a senior developer at a director level, starting on the 23rd of May. Due to my involvement with the software craftsmanship movement, this came as a surprise to many people, including myself, mainly because investment banks tend to be almost a hostile environment for agile and software craftsmanship initiatives. When I started re-drawing my own map, investment banks were an avenue that I was not considering to explore.

As I said before, choosing my next step was not easy. I had a few things in mind that were non-negotiable: I wanted different challenges, that means, things that I haven’t done before, keep having fun and loving my job, a potential long term commitment where I would have time enough to put into practice many ideas and beliefs and most importantly, have a long term career as a software developer but with a lot of space to keep growing as a professional.

I was fortunate to have had many opportunities during this time but the majority of them could not satisfy all the items above. I was determined to keep doing what I had been doing throughout my entire professional life that is just to work for companies that I really want to work for, I mean, companies that would be able to offer me what I was looking for at that point in time. For me, that’s the best way to keep fuelling the passion that I have for what I do. Joining a company just because of money is and always has been totally out of question.

UBS came along with a very interesting proposition. They want to improve the quality of their software and recognise that agile and software craftsmanship are a great way to get there. They were interested in people with no previous investment bank experience, what is very unusual for an investment bank. They want people that can think different, that are passionate and can help them drive this transformation. I had five interviews and was very pleased to see so many people striving to be and do better.

As far as I understand, my main role will be to work as a hands-on developer, embedded in a team, helping to improve quality, leading by example and mentoring other developers. They also expect me to give internal talks, training, promote events, disseminate passion and promote the craftsmanship values and techniques. In the future I’ll be working with other teams in the UK and in other offices around the world. But make no mistake. I’ll have a hell of interesting and tough challenges ahead of me and I hope to live up to all their expectations.

Besides that, I’ll keep running the London Software Craftsmanship Community (LSCC) alongside my friend David Green and try my best to give something back to the wider and great community of software developers out there that some many times I benefited from.

Thanks everyone for being part of long road journey.

Yesterday I went to my first code retreat, in Winchester UK. In the past I had been sceptical about code retreats since I had doubts if I would really learn something. However, after speaking to a few developers that had been to one before, I was totally convinced that I should give it a go. I thought, even if I don’t learn much, at least I’ll have a whole day of fun writing code, catching up with some friends and meeting other developers. That was more than enough for me to be convinced that it would be a great day.

Summary of the day

There were around 20+ developers. After introductions and explanation of the problem (Conway’s game of life), we started our first session. Throughout the day, we had 6 or 7 sessions. I can’t even remember exactly because it was so enjoyable, intense and fun that even if it had been 20 I wouldn’t have noticed.  I’ve paired with some people that I knew before (although never worked with) and some people that I had just met. After each session, we shared what we have learned, approaches we took, problems we faced, etc. If I recollect well, different languages were used and tried including Java, C#, JavaScript, Ruby, Scala and I think Python as well (I’m sure I’m forgetting something).

The first two sessions we just sat down and tried to solve it, without any constraints, besides TDD, that was mandatory for all sessions. This was good so everyone could get familiar with the problem. From the third session onwards, we were asked to try different approaches, like not using if statements, TDD as if you meant it, OOP to the extreme and the best code we could possibly write. At the end of each session, the code is deleted.

We had a good break for lunch and went to the local pub in the evening.

Things I learned and experienced

• No matter how much you think you know, it is still not much and not enough.
• Pair-programming with other developers exposes you to different ways of thinking and opens your mind for new ideas.
• Seeing and using different languages, makes you see software development with different eyes, giving you a much broader understanding and helps clearing up misconceptions you may have.
• You are not alone. Like yourself, there more talented and passionate developers out there willing to share ideas and learn from each other.
• I definitely learned a lot and feel I got back from there a better developer.
• Besides all the technical learning, it was really great to meet so many talented developers.

Thank you

Firstly I would like to thank Despo and Aimee for organising it and Enrique for running it (and the great chat in the pub). I also would like to thank all the developers that I paired with for helping to make me a better developer. Finally, I would like to thank all the developers that were there for reinforcing my belief that software development is a great profession, full of talented, bright and passionate people and that we can really make a difference in moving our industry forward.

I wish you all have a great long road ahead of you and I’m looking forward to meeting you again any time soon.

Links

• Official site for the Winchester Code Retreat
• London Software Craftsmanship Community – LSCC

I feel enthused to blog about my current project, which is the first project I’ve ran where we have a dedicated UX expert on the team. For those of you who are not aware of the term UX, it stands for User eXperience. The UX expert will work closely with the customer and business analysts, defining user journeys throughout the site/system, producing the wireframes that feed into the designs and ultimately the UI development. Read more on “Managing UX on an Agile project.” »