Content landmarks.

Think of a relatively small city, with a few noticeable landmarks such as a church, a castle, etc.
And now think of an urban expansion like the one of Los Angeles with, in all directions, low buildings as far as the eye can see.

This is pretty much what happened to content and content editors, during the last twelve years.

BBC, CNN, and a handful of content giants established in the twentieth century, are like the landmarks of an old city growing at an unbelievable rate.
The low buildings are the millions of web sites available on the internet today, each of them concurring to the amazing growth of the “content suburbia”.

Content suburbia.

Getting information “straight from the source” is getting incredibly time-consuming. Not only we are flooded with sources, but we need to decide which ones can be considered reliable, and why.
Which site will we visit? Which opinion will we trust?

Curation is King.

To try and make sense of the huge amount of information currently available, we rely more and more on social media. In other words, with count on friends and opinion leaders to distil a sound out of the noise surrounding us. They are the modern-day version of the old “Reader’s digest” (that shows my age, I know…); but friends and opinion leaders face exactly the same problem we do. Simply, there is too much stuff, out there.

The solution?

For many, it is about getting back to the old, familiar content landmarks they have been knowing for years.

In a World Wide Web made of billions of pages, visibility is everything. And they are making sure of remaining visible.
The BBC, for instance, is undertaking a huge effort to brand consistently all the websites and apps of its constellation, and even the iPlayer will soon change its design to abide to stricter consistency criteria.

In this way, they make sure that the “castle” keeps remaining visible from afar, no matter how much the city grows.

Valtech was invited to the BBC Online Industry on the 4th of May 2012 as a preferred supplier.

For pictures of this event please refer to our Facebook page.

Agility is the ability to do what you need at the right time and to the right level of detail, to be able to analyse enough now to enable you to build something that works, which can be implemented preferably into production in order to gain the benefit you planned.   

But how about concerns that are cross cutting that impact many areas and would have a big impact if they were to change, same rules apply? You wouldn’t dream of not thinking about the software architecture of a solution and just building something, that’s a trick used by the RAD/agile cowboys.  Rather you would create a backlog, review that backlog looking for stories that are architecturally more risky that others and reduce risk by considering a spike, whether that is within an early iteration or part of an activity that is an appropriately sized at the start of a project (see Valtech’s Inception offering). 

User experience seems to fit in the same problem space.  There are some considerations that you don’t want to let evolve over time you want a coherent approach that will form a decent foundation, be flexible enough to accommodate change, we all know that there will be change, but will not evolve into a tangled mess as features are developed.  A solution I’ve used is to consider these types of stories as spikes and priorities them sufficiently high.  

We’ve been able to manage these types of architectural considerations in Agile for a while

• As a Finance Director I would like the system to scale sufficiently to support my business plan so that I can generate sufficient revenue to meet board expectations.
• As the Operations Director I would like a structures logging paradigm so that I can operate the system and analyse issues efficiently.

… may realise as spikes, so what’s the Quantum leap to expecting

• As a user of the site I would like a consistent approach to search so that I find content easily.
• As the marketing director I would like my users to a simple to understand navigation paradigm so that they use my site and return to my site.
• As the sales director I would like to implement some access and entitlement so that I can charge users for my premium content
• As a user of the system I would like feedback to be provided in a clear and constant manner so that I can use the system easily and I know what to expect. 

… to realise in the same way.

It seems that Agile has grown up. That was certainly the message I received when I attended the Valtech Agile Edge event recently. The people attending were primarily from large enterprises and the public sector.  The type of attendee was not a surprise, given that target audience for the Agile Edge event is programme managers, CTOs, etc. The attendees seemed genuinely excited about the application of Agile within their organisation. It was there that it dawned on me just how far industry adoption of Agile has come in the last few years.

A Trip down memory lane

But where did Agile start? Nostalgia led me to recall my own introduction to the Agile movement back in its halcyon days. Many years ago I worked on a team that successfully adopted the eXtreme Programming (XP) methodology. It seemed a breakthrough that XP had addressed the delivery cycle (requirements, prioritisation, etc) AND improvements in development practise (Unit tests, Pair programming, refactoring, etc) with one fell swoop.  In many companies, the adoption of XP was driven by developers trying to deal with delivering quality software with right features, on time. Often this grass-roots movement was successful and early adopting organisations saw the benefit of Agile methodologies. News of successes made it to senior management, and finally Agile had broad acceptance as an effective way to deliver software.

Top-down Agile

Times have changed. Nowadays, often it is top-level management driving Agile adoption.  Success in promoting Agile as a process for managing projects, programmes and product portfolios is great news! However, it is my belief that we must be careful to remember that the successes of many grass-roots agile projects are not solely related to the Agile delivery cycle. My own productive experiences with XP were as much to do with new software development practises, as changes to the delivery cycle.

Back to the roots

In a quest to determine whether the founders of the Agile software movement had considered software-specific practises part of Agile, I referred back to the Agile Manifesto website. The 12 principles accompanying the agile manifesto were illuminating. One particular principle caught my eye:

“Continuous attention to technical excellence and good design enhances agility”

Technical excellence is not a direct product of SCRUM, Kanban or other delivery cycle management methodologies. When companies adopt Agile from the top-down, they must nurture a culture of technical excellence to complement its delivery cycle management. XP had this built in, but for those methodologies that do not, inspiration must be sought from elsewhere if we are to stay true to the Agile movement.

The Agile Hangover?

Some companies have discovered that Agile is not a magic bullet and projects can still deliver bad software. I have even heard that we are now suffering an Agile hangover (but we did party hard, right?). I believe that many of these failures are due to a lack of focus on technical excellence. I am sure that there are many who agree with this. Indeed members of the Software Craftsmanship movement propose their manifesto is the solution to an Agile hangover, even the natural successor. This theme of replacement was elaborated during a talk by Sandro Mancuso and Mashooq Badar on Software Craftsmanship at Agile Edge (thanks guys for a great talk!). I however, do not view Software Craftsmanship as a successor – I believe it is actually reinvigorating some of the founding principles of the Agile manifesto. Software Craftsmanship focuses on delivering technical excellence and better design, and bundles it under a coherent and sound-bite friendly name. Viewing the two as complimentary can deliver a powerful set of tools in the challenges of delivering software. Hopefully the top-down implementors of Agile will hear of the successes of Software Craftsmanship and actively champion this in the future as a complimentary tool to already accepted Agile methodologies.

External Links

Principles behind the Agile Manifesto:

http://agilemanifesto.org/principles.html

eXtreme Programming

http://www.extremeprogramming.org/

Software Craftsmanship

http://manifesto.softwarecraftsmanship.org/

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: