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.

Tom Gilb Laments the “10 Wasted Years of Agile”

[From the Archive: Originally posted at Amplify.com Aug 15, 2010]

I very much share Tom’s summary of “the state of Agile”:

Summary

The Agile Manifesto [2] was never a well formulated document, from the point of view of making sure we did the right things right. I have at least, in my principles and values here, tried, in my not too humble opinion, to show a specific alternative – how it might have been. The manifesto has of course been successful in getting a wave of change. And moving to rapid iteration is a ‘good thing’. But rapidly iterating in wrong directions is not progress. The key idea of intelligent iteration towards well- defined stakeholder values, was clearly and extensively spelled out in Principles of Software Engineering Management, which most of the leading agile gurus point to as a source of some of their agile ideas. But as some of them reflect today, they missed at least one simple but essential point – ‘stakeholder value’ needs to be the guiding light for the iterative process – not functions and stories.

Hey, we are still a young discipline. We only wasted about a decade getting this wrong. Software has been seeing failed fads come and go for 50 years. We have so many experienced intelligent people now – maybe we can get it right in the next revolution?

If the IT-project failure rate (total plus partial) goes down from about 90% (Standish) to less than 2%, you will know we got it right, for a change. Do you think we can do it right by my 100th Birthday?
~ @imtomgilb

For Tom’s full argument, see e.g.: “Value-Driven Development Principles and Values – Agility is the Tool, Not the Master” (pdf of Agile Record article) or a related Slideshare Presentation.

– Bob

Agile: Doing the Wrong Thing Righter

[From the Archive: Originally posted at Amplify.com Jul 19, 2010]

Introduction

Undoubtedly we’ve come a long way since Snowbird (http://martinfowler.com/articles/agileStory.html, http://agilemanifesto.org/history.html). And Agile seeds – when planted in fertile ground, at least – can grow successful, productive teams. Even hyper-productive teams (http://gojko.net/2010/04/20/jeff-sutherland-how-to-make-your-team-hyperproductive/).

Several conference announcements recently have trailed John Seddon’s upcoming polemic against Agile: “doing the wrong thing, faster”. Neither knowing exactly what John’s going to say on the subject, nor wishing to steal his thunder, I’m writing this piece to present my own views on why Agile has, more often that not, been doing the wrong thing righter.

One thing John and I are likely to share, though, is a Systems Thinking perspective on the subject. Hence the notion of Agile as “the wrong thing”.

Systems Thinking

Systems Thinking, in a nutshell, encourages us to take a look at wholes, not parts, and judge the worth of a system on its end-to-end effectiveness, rather than on how well individual parts operate (aka their efficiencies).

We can choose to regard any business as a system, with software development being just one part of such systems. No matter how well-run the software development team or department, the system within which it exists can still be dysfunctional and perform poorly. The introduction of Agile to a development group often only helps to enhance that one (relatively small) part of the whole system.

Some people note that Agile, and Scrum in particular, drives the discovery of these dysfunctional system behaviours e.g. throughout a business. And while I have seen that happen, few businesses have the will or insight to act on the messages coming from the agile teams. NB @dpjoyce has just tweeted about the “Red Pill / Blue Pill moment” (http://twitter.com/dpjoyce/status/18901380780).

Cognitive Dissonance

This highlighting of dysfunctional behaviours often leads, in turn, to significantly increased friction between the Agile folks and the rest of the folks they work with. Ultimately, the friction can become sufficiently uncomfortable to threaten the Agile initiative itself, improved software development outcomes notwithstanding.

I could write more (much more) on this topic, but – not least because this post was prompted by various folks wanting to talk about this question – I’m going to park my keyboard now and invite you to contribute (below)… 🙂

Career Paths for Technical Folks

[From the Archive: Originally posted at Amplify.com May 11, 2010]

In my previous Amplify entry, “Do Managers need deep technical skills?“, I suggested that folks with technical knowledge were perhaps not automatically the best choice for management positions in technical teams.

Marc Johnson then asked about my view on career development for technical folks. So here it is:

I have long thought it unfortunate that most organisations seem to have an implicit mental model of career development that assumes that to “get ahead”, folks have to get on to the general-management ladder and begin climbing.

It’s been my experience that many highly talented technical folks have little interest in swapping their technical role for a management one, but often feel that a change into management is the only way they can advance their careers.

Sun Microsystems (R.I.P.) used to have a somewhat novel take on this issue: They provided twin career ladders all the way up into the high echelons of the business, one ladder for technical folks and one for the general management folks. For a business predicated on technical excellence, this seemed to make some kind of sense.

In the more general case, I take comfort from the continuing evolution of business in general, and the role of management in particular, that suggests to me that the issue may become moot at some point in the future. Not least because I see the role of management changing (unrecognisably), and modern management skills becoming just one more skill-set of the multi-skilled worker.

Aside: By “modern” management skills I mean things like Systems Thinking, Theory of Constraints, Lean, appreciation of e.g. customer value, value streams, folks’ needs, and fellowship;. These in contrast with the more traditional emphasis on amorphous “people skills”, command-and-control, etc.

So, for technical folks in organisations that essentially require one to abandon one’s technical career to get ahead, the old saw remains true: “Change your organisation, or change your organisation.” :}

Amplify’d from twitter.com

Do Managers Need Deep Technical Skills?

[From the Archive: Originally posted at Amplify.com May 7, 2010]

Jurgen Appelo asked me yesterday to clarify my (tweeted) position that requiring managers of technical team to have deep technical knowledge (within the same technologies as the team) is “senseless” (i.e. not very clever).

So here’s my response:

There are some (few) advantages to a manager possessing deep technical knowledge in those technologies being used by the team. However, these advantages are significantly outweighed by the concomitant disadvantages.

Advantages

• Easier to win the (early) respect of the team.
• Fount of knowledge on hand when the team get stuck on technical issues.
• Better early inter-personal communication, as the manager and the team have a more congruent understanding, vocabulary, etc.
• Technical skills imply, at least, that the manager in question may have an engineering perspective and understand the software development (e.g. coding) mind-set.

Disadvantages

• Superior knowledge makes for less effective coaching, as the “expert” is often sorely tempted to provide a quick answer to move the work along, rather than allow the team to stumble and thereby learn and grow their skills. Aka “micro-management”.
• People coming from a technical background do not often have the coordination and interpersonal skills necessary to help the team achieve a highly-effective state. Consider the perspective of Deming et al: “The Team works in a System. The job of the manager is to work on the system to improve that system with the help of the team”. (Personally, I’d describe it the other way around: The team owns and improves the way the work works (the system) with the help and support of the manager).
• People with a deep technical knowledge have generally acquired that knowledge by dint of love of technology and long hours spent practising their art. Many such folks find it very difficult to set this love and these skills to one side on those occasions when the exigencies of the situation demand more focus on the development and application of their coordination and interpersonal skills.

To recap: Whereas the advantages listed above are more numerous, they are, in my opinion, far outweighed in significance by the stated disadvantages.

Personally, I would generally exclude people with deep technical knowledge from consideration for management positions, as both a favour to them, a favour to the team, and a favour to the work and its customers. Of course, there are rare exceptions. 😉

Amplify’d from twitter.com [original source no longer available]

– Bob

Postscript

[Mar 2, 2012]

Lest anyone slip into the notion that I favour non-technical managers over technically-skilled managers, please note that in the bigger picture (i.e. of organisational effectiveness), we would not have managers at all. The issue then becomes moot.