The Developer’s Job

[From the Archive: Originally posted at Amplify.com Sep 23, 2010]

We all know that, particularly in Agile development, developers have to wear many hats, and juggle many priorities, all the while working as a team.

My recent tweet (see at end) seems to have struck a chord – although maybe not in a good way. :} My thanks to all who responded. To save tweeting a response to everyone separately, I’ve penned this post in answer to the general tenor of the inquiries i.e.: “Well, what IS the Developer’s Job, then?”

Firstly, I have to say “It depends”. In particular, it depends on the prevailing mindset of the organisation within which our eponymous developer finds him- or herself working.

Within organisations of an Ad-hoc or Analytic mindset (the latter being by far the most prevalent of all organisational mindsets), a developer will be lucky(?) to have the opportunity to consider much else besides software. Indeed, they may be lucky to have the opportunity to consider much else besides code.

My tweeted remark (see below) was posted from the stand-point of organisations with a prevailing Synergistic mindset (admittedly, rare). Like their counterparts in lean service, lean product development, or lean manufacturing jobs, developers in Synergistic organisations at least have the possibility of being able to see their role (job) in a broader context.

Of what does this broader context comprise? We can start by recognising that developers are serving more than one master. Most times, several masters, in fact. I am speaking of course of the various separate stakeholder groups which any effective development project team must concerned themselves with serving. End-users, sponsors, project champion(s), the product owner, and the team members themselves each constitute distinct stakeholder constituencies. As does the business (organisation, company) within which the developers work. (Aside: I use the term “covalent” to describe this phenomenon).

So my answer to the inquiry referred to above, in the context of Synergistic organisations, is “the developer’s job is to understand the needs of the various stakeholders, in terms of what they each value, and to collaborate with other areas of the wider organisation in meeting those needs”.

Rare indeed, the stakeholder whose needs are confined simply to a piece of software, and even less, code. I grant you that software may be one (sometimes essential) part of the delivered solution.

As ever, I welcome a dialogue on this perspective.

Amplify’d from twitter.com

flowchainsensei OK. So there are STILL a whole bunch of software developers who think their job is about building great software. Sigh. Read more at twitter.com

– Bob

Agile. Necessary but not Sufficient.

[From the Archive: Originally posted at Amplify.com Sep 8, 2010]

For want of a nail...

On Twitter recently I wrote,

“How about taking the whole #agile debate to a different place: The role of Product Development in (technology) businesses…?”

Some folks seemed to express an interest in this idea, so I’ve penned this post to draw together some threads appearing on Twitter and various blogs over the past few weeks and months. I claim no originality in these ideas, but maybe the weaving-together may offer some new perspective.

Am I anti-Agile? That’s as maybe. For my part, I have been evolving my take on the world of work, and in particular the world of work in technology-related businesses – from banks through electronic product companies to software houses, etc. – for over twenty years now. Over that time, I have seen the interest in “Agile” grow steadily, mainly amongst developers wanting to do a better job (and cut out some of the crap from their working practices), and more recently amongst some folks outside of software development, too.

My recent concerns over Agile, similar to those voiced by Al Shalloway and a few others, stem from the observation that many folks – developers and non-developers alike – seem to be expecting too much from “adopting Agile” within their organisations. Yes adopting Agile will often make developers’ experience of work more pleasant. And yes, adopting Agile can often double software developer productivity in the medium term.

But simply applying Agile principles (and practices) within development project teams will typically buy organisations, at best, no more than single-digit improvements in their overall PRODUCT development endeavours (i.e. improvements to the bottom-line). This degree of improvement, even when realised, can often be lost in the general noise of the business, or attributed to many other factors aside from Agile adoption per se.

This marginal value is often further eroded by the increased disruption along the Product Development pipeline, most obviously at the interfaces between the development team and the other folks / departments involved in the wider Product Development effort. In many cases, this disruption, coupled with marginal (apparent) bottom-line contribution, can persuade senior management that the whole Agile escapade has not been worth the candle, with consequent dilution of support. Under these circumstances, Agile sinks back into being – at best – something for the software developers alone.

So to the title of this post. Unwittingly, in most instances, Agile adoption is the vanguard of a shift in mindset within adopting organisations. Agile only really takes hold and delivers productivity benefits with the adoption of new ways of looking at and relating to the world of work (self-organising teams, reduction or elimination of specialisms, new roles for middle-management, intrinsic over extrinsic motivation, etc., etc.).

I believe Agile (or similar) has a necessary role to play in introducing this shift in mindset into development teams. But in no way is this sufficient for the shift in mindset to take root in the rest of the organisation.

In fact, starting in Development – already often seen by the rest of an organisation as a bunch of strange people doing inexplicable things and costing unfathomable amounts of money – would not be my choice of the best place to start a movement towards a new world-view for the organisation.

And without winning the confidence and participation of the rest of the organisation in the ongoing shift in mind-set, Agile builds its own Ghetto.

In summary, the benefits of a shift in mindset throughout the Product Development pipeline can bring compelling, triple-digit percentage improvement to a business’s bottom line. It is necessary for development teams to be part of this shift in mindset, and Agile is ready-made for this role. However, limiting such a shift to development teams alone is in no way sufficient to achieve the compelling benefits of a wider shift in mindset.

– Bob