All posts by james

Agile on the Beach

I was lucky enough to be invited back to Agile on the Beach for a second year and gave a talk on Growing a culture of innovation.

The basic premise is that in todays ever more connected world, it’s becoming more and more important for companies to innovate to retain their market share but its notoriously hard to create a culture where innovation can prosper using traditional management techniques. My opinion? You can’t create culture, but you can put people, an organisational architecture and routines in place that allow a culture to grow.

My slides on the talk can be found on slideshare here and the full synopsis on the talks page. Video will be available shortly and will be added when it is.

Java micro services talk online

I was asked to present this year at the 33rd Degree conference on Java Micro-services and i’ve finally managed to get the slides up on slideshare.

You can find them here.

I would like to thank the conference organisers since I had a really interesting week with some great feedback. I really need to write a bit more on the topic since it seemed the topic was useful and interesting for people.

Thanks everyone who attended. Hope to see you again next year.

ThoughtWorks QTB – Choose your own Programming Language

With my colleague Ian Cartwright, I recently delivered a talk on programming language adoption at ThoughtWorks EU Quarterly Technology Briefing.

The video can be found here

Synopsis

Gone are the days when your company was limited to C++ or Java. The last few years have seen an explosion of programming languages promising “10x more productivity” or a “quicker return on investment” but what is the reality behind these claims? Programming language choice has an impact far beyond the immediate, after all COBOL applications still perform billions of business critical transactions every day and an estimated 86-94%* of software cost is incurred post development. In addition, the world of computing is changing, Moore’s Law still holds, but in an unexpected way – we can no longer rely on faster CPUs to boost performance, instead we need to have multiple CPU cores. So what does this mean for language choice in the Enterprise? This Quarterly Technology Briefing will explore these dilemmas and offer practical advice on how to balance often opposing concerns; stability vs innovation; fast to market vs easy to maintain; fashion vs staff retention; etc. We’ll do this by looking at historical motivations for changing patterns of language use and ask which of those, alongside which new forces and pressures should we be considering today.

Upcoming talk on building micro services

I’m chuffed that I’ve been asked to speak at the 33rd Degree conference which runs 19th – 21st of March in Krakow, Poland.
I’m going to be speaking on building micro services in java – something I’ve been advocating for a while (and will get around to writing up sometime soon…). Talk synopsis follows:

Micro services – Java, the Unix Way

“Write programs that do one thing and do it well. Write programs to work together” was accepted 40 years ago yet we have spent the last decade building monolithic applications, communicating via bloated middleware and with our fingers crossed that Moore’s Law keeps helping us out. There is a better way.

Micro services. In this talk we will discover a consistent and reinforcing set of tools and practices rooted in the the Unix Philosophy of small and simple. Tiny applications, communicating via the web’s uniform interface with single responsibilities and installed as well behaved operating system services. So, are you sick of wading through tens of thousands of lines of code to make a simple one line change? Of all that XML? Come along and check out what the cools kids are up to (and the cooler grey beards).

This is a talk about building micro-services using simple java tools

Update: Lean and Lego – Building the Millenium Falcon

Update: The talk went really well I’m pleased to say. I guess Lego and Star Wars really appeals to most geeks…
Video and slides can be found here

I’d like to say a big thank you to the organisers – a first event and an unquestionable success.

—————————————————-
Upcoming talk: Lean and Lego – Building the Millenium Falcon
Location: Agile on the Beach – Cornwall
Dates: 15th – 16th September

I’m really pleased to be giving a talk on lean practices at the 2011 Agile on the beach conference. The talk is a slightly irreverent one, using our experiences at ThoughtWorks London of building the largest Lego set ever produced to introduce the ideas of self organisation, continuous improvement and lean practices. I’ll cover a bunch of more involved ideas from Lean too – cycle time and the like. I’m dead chuffed, as the speaker list is good and the location promises to be beautiful.

If you are interested in Agile Development or Software Engineering and live in the South West, or even want a break on the beach whilst seeing world class keynote speakers (not me) then come along – it should be fun.

Real time web – the push off

I’m participating in a bit of light-hearted fun this evening in the ThoughtWorks London office when we host a geek night with the subject of the real-time web.

There will be two “talks” – though it won’t just be powerpoint, never fear there will be demo’s too.

I’ll mainly be talking about Websockets and the stuff you need to think about when using this technology as well as demoing a performance testing tool that uses a bit of BOSH and a bit of XMPP.

It won’t just be me though, Meinhard Benn, a Strophe committer will be talking / demoing too. Personally that’s the bit I’m excited about.

Sign up at the site above and come along!

Agile Brazil and ThoughtWorks, Porto Alegre

I am about to fly home this evening after spending the last week in the ThoughtWorks Brazil office and at Agile Brazil where I was speaking on agile adoption.

Agile Brazil was a great success, and I’d like to offer my thanks and congratulations to the organisers of the event. 800+ folk came to hear locals and some international speakers talk about agile software development. The ThoughtWorks booth was busy the whole time and it’s clear we have a very strong brand here.

It’s been a great trip – spending time with my Brazillian colleagues has been an absolute blast, both old-skool ThoughtWorks folk and the talented and passionate new joiners here.

Highlights include highjacking a big screen in the comp-sci department of the University so that Martin Fowler and I could watch an England game, my first experience of BBQ’d cheese, giving a talk to a room that sits 1200; and meat. So much meat.

Thanks to those that made my stay such a good experience, too many to name but Danilo, Paulo, Carlos V, Phil, Amit, Gary * 2, Greg, Caio, Camila, Pat and Sameer all made me feel very welcome. Special thanks to Verônica who made sure this gringo wasn’t completely lost when out and about in Porto Alegre.

Upcoming talk: ‘OMG! Someone broke the Internet!’ – Manchester, May 19th

I’m giving a talk on push-to-the-browser at the Manchester geek night on May the 19th. Not quite sure of the location yet – stay tuned…

WebSockets: OMG! Someone broke the internet!

So we’ve finally worked out how to build massively scalable internet applications. REST and Resource Oriented Architectures are proving hugely successful; but the Internet is changing. WebSockets are a W3C supported protocol that offer developers greater flexibility when implementing the next generation of internet applications. This flexibility doesn’t come without cost. The speaker will explore the practical applications of the WebSocket protocol, it’s limitations and the impact on internet-scale software engineering. This talk is targeted at Developers, Technical Leaders and Architects. There may even be some code.

With measurement comes control

In my last post on Why your organisation won’t be Agile I made the following assertion.

If your organisation is based on the traditional command and control management model and you cherry pick a set of project management techniques from one of the flavours of agile you will get visibility but not much else.

I promised to look at some of the root causes of the golf-course-agile movement and so here is the first.

Firms design for efficiency

John Roberts in his 2004 book The Modern Firm defines two main types of activities that make up an organisation. The first type are around the value chain – the set of routines and processes that are executed in order to fulfil an organisation’s strategy. The second are the supporting activities without which a firm wouldn’t function. Think HR, payroll and finance etc.

The optimal design of your value chain activites should enable you to execute your strategy as effectively as possible. Many large traditional organisations are designed around the idea of cost-control and efficiency. Make your processes as efficient and as cost-effective as possible as a mechanism for sustaining and, hopefully growing, your profitability.

In this world, decision making responsibility typically lies with middle managers whose direct reports are the people responsible for the value adding activities and who themselves report to either C-level executives or more senior managers. Decision making at this level brings some benefits from coordination of activities across different business units or groups within an organisation. An example would be a massive conglomerate where a middle manager is responsible for all the Software Engineering groups and who is accountable for results across those groups.

Strong incentives require measurement

The key word in that last paragraph is accountable. It is reasonable to expect that this accountability is tied in some way to increased rewards or incentives for generating better results and in order to qualify for those increased rewards the Manager must be able to demonstrate these better results.

Thus, the adoption of Agile project management practices makes complete sense in this context. Especially if it is linked to toolsets that offer Management Dashboards or other automated ways to interrogate the progress of the work in your business unit/division. Indeed, not only will your Manager’s Manager have access to the information she needs to demonstrate progress against her key metrics, she can use the new knowledge to increase performance further by concentrating on the (for a given value of) under-performing teams in the business unit. This gives the manager increased information on which to base their decisions presumably allowing them to make better ones.

Innovation retardation

This centralisation of decision-making comes at a cost. The information produced for individual teams must be standardised to a common format that enables the sort of aggregated and comparative reporting required by this model. This means standardisation of processes across teams within the business unit. And that standardisation comes at the cost of effectiveness. Designing or adopting a process, then locking it down and requiring all teams to implement it may be efficient, but it will ensure that each of the teams operate at a level of effectiveness below their optimal. Mandating the adoption of process is a guaranteed way to stop your teams innovating and changing their process as they find better ways of working.

Remember this?

The best architectures, requirements and designs emerge from self-organising teams

It’s from the Agile Manifesto and effectively states you get more maintainable, robust software if you delegate the responsibility of decision making to your teams. In my opinion you can add processes to that list .

What about this one:

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly

Deliberately reflect on how you can deliver more effectively. The assumption is that you will change your processes over time as new information becomes available to you; as you learn. If you don’t do this, then you are an idiot.

Woah there dude! Are you saying that visibility is a bad thing?!? Surely you *do* get visibility with Agile?

Of course. And there in lies the rub. You do get tremendous visibility. Having hard data on whether you are going to hit your release date 1/3 of the way through a project enables you to have far more productive conversations with your business sponsors and even pull the plug if necessary. Code coverage metrics let the team feel safe enough to refactor the codebase, fix broken windows and deploy automatically on a regular basis. Big Visible Build Monitors allow the team to be confident that their software is always deployable and that they are a revert away from working code. The point of surfacing all this information is to allow the team to make decisions based on the feedback loops that provide it.

The first candidate cause of golf-course-agile is…

Here’s the problem then. The idea of a centrally mandated process designed by middle management or process mavens for the purposes of increasing visibility reinforces centralised decision making. If adoption is driven by a need to measure or increase visibility of the work being done because strong incentives require strong measures, you will end up missing a key part of the very thing that drives the huge increase in effectiveness you get by trusting your teams.

Without the devolution of decision making to the teams that are delivering the software; without the ability to make changes to the processes they use as they find new and better ways of working; you will get visibility but little of the increases in effectiveness that come from the ability to influence your own environment, to reflect and to adapt. In my opinion you won’t be agile. Whatever it means.

Next up, Ivory Tower Process Mavens, and the systemic reasons they fail

Why your organisation won’t be agile – Part I

I’ve been peddling a talk around the place recently. Ostensibly it’s on “Why your Agile roll-out is failing”. Though Dan North got the name first. So I called mine Agile Adoption Anti-patterns. meh.

The behaviours I describe are based on my experiences over the last several years as a developer and coach. They seem to indicate a number of systemic problems that organisations face when looking to go agile.

One conclusion I reach in that talk is that you will fail unless you are prepared for systematic change in the organisational architecture, the people, the culture and routines that define your organisation.

Ok, that’s pretty strong. let me rephrase that.

If your organisation is based on the traditional command and control management model and you cherry pick a set of project management techniques from one of the flavours of agile you will get visibility but not much else.

Golf course agile

“We want to be ‘Agile'”

“Really? You want to learn how to value and trust your people? Be courageous? Build the right software at the right time? That stuff? Cool! I can help with that!”

“Umm, no. We want predictability and metrics. I want to know our velocity so that I know how lazy my developers are.”

“Oh, ok. Rename all your Six Sigma black-belts to Scrum Masters*. See how that works out for you and call us in 12 months when it doesn’t. Then we’ll chat about the rest of it. Failing that, can you just leave my card on your desk for the next CIO that comes through? Thanks.”

I used to find it was the developers who were into the idea of working in a more agile way. I think there are two reasons for this, the first is that undeniably there are shiny new tools and techniques out there that are associated with Agile. BDD, CI, Pairing etc all appeal to developers looking for ways to manage complexity in their code.

The second was that contrary to the popular image of a developer as some crusty old bearded dude (and it’s always a dude), sitting in a darkened room, only caring about copy-on-write semantics for lists, most are unbelievable passionate about their jobs and Doing The Right Thing. And incredibly intolerant of the wasteful processes they have imposed on them. Some even actually care about getting the right software out in front of their users so it can be used.

So for some of these reasons and almost certainly for a bunch I haven’t thought about, developers started getting the Agile bug years ago. It describes my reasons anyway. Plus I’m a hippy. Shrug.

Fortunately, the golfing class has now caught up. That’s a good thing right? Agile is going mainstream. Everyone and their dog is doing it. It’ll fix all our problems! Everything will be visible.

Management iz in ur progekt, wotchin ur progrez

Except I don’t really see Agile becoming mainstream. I see iterative development becoming mainstream, visibility becoming mainstream.

In fact, what I see most is that Agile is being used as another mechanism by which executives exert more control over their staff. Visibility onto a project should not mean you know who to fire when it fails. I haven’t seen much in the way of courage becoming mainstream.

In part II of this post I will talk a bit about the root causes of some of this behaviour. Stay tuned…

* Disclaimer: I’m not saying that Scrum is any more guilty of this than any other methodology, just that it is very popular. No-one ever got fired for choosing Scrum.