Our economy is based on The Wealth of Nations, and it’s out of date…

This is a post I’ve been meaning to write for some time, and have never got around to as it’s just too big a thing to get straight in my head. I’m writing something now (and it’s little more than the title) just because I think I should lay down a marker. Apologies in advance to anyone who was looking for something more insightful.

The summary is this: The Wealth of Nations by Adam Smith is the de facto bible of western economics, and its core tenet is the Division of Labour, which he studied through the prism of industrialisation and specifically the manufacture of pins.

Problem is, we’re moving beyond a classic industrial society – possibly to something identified as the Information Age. And in this age, classical economics no longer apply. This is most clearly seen in my own industry – software development, which works in precisely the opposite fashion: productivity increases as work is consolidated into a smaller group of more talented (and expensive) developers. The Division of Labour is not only unproductive, but positively destructive, as anyone who has scrambled through an offshore project can attest.

This paradox undermines many well-meaning corporate initiatives, and until we have a clear, and open, debate on this we are, frankly, a bit f*ked.

More to follow.

^[1] Notwithstanding the “Invisible Hand”, which is the other core message.

Yes, Facebook has lots of users. So what?

Another day, another article about Facebook's global takeover. Yes, I know that FB now has 750m members, which is clearly a lot of people. However, the obsession with registered users feels very like the rush for pixels in the digital camera business a few back, or the stampede for ever larger app stores amongst the mobile vendors.

I don't care if FB has 1bn members (anecdotal evidence suggests that registrations peaks at apprx. 50% internet users within a country), a camera has 50m pixels or my mobile app store has 1m applications - if they're not my friends, my favourite apps, or the pictures still come out blurry it's a problem.

Google+ is the victim in the latest article - with the Facebook-Skype deal apparently sounding the death-knell for the new Hangouts video-chat service. I don't think it will kill it, and what is more, I think the niche audience that G+ is rapidly acquiring (albeit fanned by the limited access to invites) is more valuable than the mass of humanity represented by FB*.

In a similar vein, if I was a camera vendor I would pay a lot more to advertise on Flickr than Facebook (yes, I know Flickr doesn't have ads, it's a theoretical point), because people on Flickr care about photos, and people on Facebook don't. (I'm also sure there are hundreds of amateur photo groups on Facebook - but if they really cared they'd be on Flickr, as it's a destination defined by the quality of images available.)

I am sure that it makes sense for all commercial entities to have a presence on Facebook, and to invest in a "social media strategy", but they are supporting acts; the web is the superset of all properties, and will outlive Facebook.

* NB This obviously doesn't apply to the drinks brand WKD - whose natural habitat is clearly Facebook on a Friday night.

What agile means to me

[Update: in response to some of the comments here and on HN, I thought it might be worth updating with a note on my personal experience with Agile, which appears at the bottom of the post.]

Agile (with a big 'A') has become so mainstream now that it has started to become the problem. An alarming number of people who espouse the virtues of Agile, and who quote the Agile Manifesto believe that Agile is a project management methodology, and that Agile really means SCRUM, XP, Kanban, and that it is embodied in the daily stand-up, whiteboards or writing requirements on post-it notes. I was once told by an Agile Trainer (LOL) that the correct way to phrase the requirement "we need advertising placeholders on the site, and some way to manage which ads appear where" was "As a User, I wish to be marketed to." Needless to say his company lost a $m project on the back of such BS.

As a result of all this, Agile (big 'A' again) has become a bit of an albatross - it doesn't really work, it doesn't deliver the benefits it promised, and it inevitably involves a lot of arguing amongst the team about who should be doing what, and when.

All of which distracts from the fact that agility (small 'a' this time) is a wonderful thing, that can be achieved, that does provide enormous benefits, and that should be encouraged in everything we (as an industry) do. Agile (small 'a') refers to team dynamics, delivery processes, the software itself (how easy is it to change), and operations. Everyone should aim to be agile.

So, a few lessons I've learned along the (hard) way:

• The best way to achieve your goal is to start with the right people
• If you've found the right people, let them get on with the job you're paying them for
• The people with the best ability to plan the delivery are the people doing the work
• A small team with a manageable backlog needs very little Project Management
• Everyone on the team “needs to know”.

A few things that help this happen on a practical level:

• Try and avoid building towards a pre-determined marketing / launch date
• If you do have a fixed time, then scope is variable
• Never try messing around with team sizes to massage delivery
• Automate everything in sight - builds, deployments, testing, progress reporting, tea-making
• Measure as much as you can - no feedback == no direction

And finally some other things that will prevent you from getting there:

• If you have to have everything on your requirements list, you can't be agile
• If you need to plan beyond the next sprint with any degree of accuracy, you're not agile
• If you think you can "fix" an iteration by adding more people, you're not agile
• If you are prepared to change the end date of an iteration to "fit something in", you're not agile
• If you have to give a fixed date for delivery - it's very, very difficult to be agile.
  

Postscript: my personal experience with Agile.

I worked for several years at a company that was at the forefront of the Agile movement in the UK, and I believe that at one point they had more registered SCRUM Master practitioners than anyone else in the country. (I think Sensai Schwaber visited in person at one point, although I’d left by then.) They were generally acknowledged to be the leaders in the field.

The incident in the post occurred when I returned to the company as a client, parachuted into a large project that they were running with the full SCRUM toolkit (“Agile Coach” included), that was running into trouble, principally the fact that it was not agile. The project was rescued by hiring a team of people with the right combination of aptitude & attitude.

As I say in the post – agility is a great goal, and everyone should aim for it – but don’t make the mistake of thinking that Agile is the means to achieve it.

Driving to the airport, agile-style.

If you were travelling from A-B, and planning the journey yourself, you might look it up on Google Maps. GM would give you a route, and an estimated time for the journey - let's say it's one hour for our mythical trip. Now let's assume that the destination for our journey is the airport, as we have a plane to catch - i.e. we absolutely have to be there on time.

In this scenario, would you leave the house one hour before the flight departs (let's ignore the reality of parking / check-in / security etc. - we're on the company jet, just driving up to the plane)? Of course not - if you had to be there on time, and you were taking someone else's directions, even someone with the 'authority' of Google, you'd probably add at least 50%, and probably 100% to the estimate. Even then, you're still subject to the vagaries of the traffic - something that affects everyone, regardless of whether they've driven the route before.

If you were to approach the journey from an agile point of view, you wouldn't book the airline ticket in advance - you'd catch the plane when you got there. And you wouldn't plan the route either - you'd hire a driver, who knew the route, and simply tell him the destination. He'd make up the route as he went along, avoiding traffic problems if possible by using his previous experience. It’s pretty clear that if you just set out from A, travelling to B as fast as you could, it would take less time than if mentally started at B, then worked backwards to determine when you ought to leave A.

Agile behaviour in a software development team requires a similar faith in the ‘driver’ – in this case the people in the team. The quickest way to reach your destination is to have faith in the team to deliver, and to make sure that they understand the destination. If you then insist on them following a specific route, then you have just removed their capacity to avoid delays and dead-ends – removing the reason you hired them in the first place.

If you want to be agile, you have to trust in your team.

(And yes, this does mean that outsourcing a project cannot be agile. It also means that agile is NOT a project management methodology. It’s a way of working.)

Application Lifecycle Management

[Update: a couple of people have called me out on this post, and suggested that it would only work from the bottom up if you hire good developers. This is true. This entire blog is based on the philosophy that the cheapest and most efficient way to achieve any given goal in software is to hire a smaller number of better developers. If you have a different philosophy, then you may find this site more helpful http://hrb.fm/keHPzD.]

ALM is described on Wikipedia as:

“…a continuous process of managing the life of an application through governance, development and maintenance. ALM is the marriage of business management to software engineering made possible by tools that facilitate and integrate requirements management, architecture, coding, testing, tracking, and release management.”

The phrase itself is enough to make the blood run cold, but I’ve been struggling recently to justify why I think it’s a Bad Thing, and I think I’ve worked it out: it’s all about the direction in which processes are created and applied.

ALM comes from the Old World (aka I.T.), where working practices are created by Architects and applied downwards to development teams. It’s a process designed to commoditise development, and to manage human beings out of the equation. If the process is sufficiently detailed and watertight, then developers can become replaceable – which in turn allows you to find cheapers versions. 

This is lowest common denominator thinking – by creating a process that allows poor developers to work effectively, that same process will prevent good developers from doing what they’re good at. It’s mediocrity by design. Which in I.T. terms is not necessarily a bad thing – ERP, Accounting, Warehouse Management Systems – these are things that are: a.) operated in a controlled environment, b.) used by specially-trained staff, c.) defined by stability, not innovation.

None of this applies to web application development – which is defined in contrast by: a.) public access, b.) self-service, c.) continuous innovation, and pace of change. In this New World (otherwise known as The Web), companies are defined by the quality of their development staff – they are the asset, and they need be allowed to flourish, and not capped by  process.

The kicker to this is that process is still a good thing in this New World – but the new processes are designed not to prevent developers from getting things wrong, but to make it easier for them to get things right. ALM should exist in practice, but it should (in fact must) come from the bottom up – the processes are organic and designed by the developers, for the developers.

There’s no requirement for management to even be aware of these processes – they should manage by outcome, not intervention.

NB If this rings any bells with you I would recommend Orson Scott Card’s “software developers as bees” article - http://hrb.fm/lIOR0w