Archive

Monthly Archives: August 2010

Bain on Business / IT Alignment

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

Dan Rough just asked me about my thoughts on this (2007) Bain report, and its relevance to #Rightshifting.

Firstly, it’s good to see that someone in the big bench-markers was paying some attention to effectiveness. (Question: is anyone still interested in 2010?)

Of course, the Bain argument is mainly concerned with “pragmatic” issues such as business growth and costs, whereas #rightshifting finds its root in social justice, with considerations of profitability etc. *derived* from that root. By which I mean, #rightshifting holds that profitability, business growth and lower costs all improve (dramatically) with a more engaged workforce.

I don’t quite see why Bain have chosen to make “Alignment” a different axis from “effectiveness”.Surely alignment of IT with the business (giving the business the features it needs) is a part of effectiveness? I guess it played to their focus on “Business Alignment” as a strategic (marketing) ploy back then (2007).

I’m also not too sure to what extent this report was regarding IT as a “string and tin” and/or webtone provider, and to what extent software development played a part.

I can certainly concur (from experience) that organisations that try to improve the IT / business alignment by e.g. distributing IT around the business units seem to rapidly lose any semblance of “being able to do a good job on IT projects”. So, yes, I find the “Alignment Trap” issue congruent.

Coming back to the question of relevance to #rightshifting: If we unwrap the chart and stack the four quadrants horizontally, it seems to me to be very congruent with the #rightshifting chart we all know and love. That is, I would order the quadrants, from left to right, thusly: Alignment Trap (11%); Maintenance Zone (74%); Well-oiled IT (8%); IT-enabled growth (7%).

Big Note: The above ordering only takes us to about the 2x effectiveness mark on the rightshifting chart! There’s lot’s more (empty) space on the rightshifting chart (to the right of 2x, up to and beyond the 5x mark) that this Bain report doesn’t even acknowledge.

I can certainly concur with their basic premise:: “Aligning a poorly performing IT organization to the [relevant] business objectives still won’t get the objectives accomplished.” For me, the key question remains unanswered by this report: HOW to get business objectives accomplished REALLY effectively?

Amplify’d from twitter.com

Read more at twitter.com

– Bob

The Teflon Consultants

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

I was reminded whilst writing this tweet of a disappointing discovery I made when recruiting consultants for several projects at Familiar, the software and consulting business I used to own and run in the late ’90s.

As the business grew, we had a need for some folks to help out on a couple of development improvement projects, in a consulting/coaching capacity.

When it got to meeting the potentials for a chat (always so much better than an interview, imo), I of course mentioned our “value-for-money guarantee“:

“Whenever we invoice you, just pay as much as you think our work has been worth to you”.

This is a guarantee we gave to all our clients – and continue to give, btw.

To a man (and woman), the potentials, as soon as they heard this (why had they not already read it on our website, one could reasonably wonder), looked aghast.

Not one of them could conceive of standing behind their advice in the face of such a (brutally effective) feedback mechanism. Perhaps needless to say, I did not offer any of them a position.

Amplifyd from twitter.com
  • flowchainsensei @liammclennan Equally amazing: how many consultants don’t want to take responsibility for giving advice that works

Read more at twitter.com

– Bob

The Starting of Familiar

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

Introduction

In an attempt to give folks some context to some of my more contentious remarks on e.g. Twitter, I reproduce here the story of how Familiar started out, and some of the things we achieved during my time on deck:

A Customer Quote

“One of the most rational and engaging organisations I have ever seen.”

~ G Shekhar, CTO, InfrasoftTech

Familiar Limited was a company that I started with a colleague upon my leaving Sun Microsystems’ UK Java Center in early 1997. We also had the delight of some ten other interested folks helping us form the company and its ethos from the outset.

Green Park, Longwater Ave, Reading – headquarters location for Familiar Ltd circa 1999

Familiar was a software house specialising in delivering advanced bespoke Java web applications, that also shared its expertise on how best to manage the business of software development – in the form of consulting services – with other software development organisations. In fact, Familiar was the first 100% Agile software house in Europe.

Founded on Principles

When we set up Familiar, we had between us seen literally hundreds of development organisations, and we were convinced that it was sound business sense to found Familiar on the following core principles:

  • We would run the company for the mutual benefit of all the people coming into contact with it.
  • We would institute “human systems” that treated people – employees, customers and suppliers alike – like competent, rational, trustworthy adults.
  • We would do everything possible to build a community for the long term. Success depends utterly on having the full commitment of well-informed people who really want to make a difference.
  • Work can be the most fulfilling, exciting and absorbing activity known to Man.
  • No matter how motivated, intelligent and competent people may be, they still benefit immensely from an agreed, common approach to tackling work.
  • Commonly-held “management” assumptions and traditions (for example: jobs, appraisals, standard employment terms and conditions, management authority) are sometimes counter-productive and deleterious to a healthy business.
  • All our business dealings would seek win-win-win-win outcomes (for us, our suppliers, our clients, and their customers)

Guided by Practices

Given the above principles, this led us to institute a number of key mechanisms to advance these principles:

  • People were encouraged to participate in the community on whatever basis they felt most appropriate for their circumstances (for example, as employee, contractor, sub-contractor, apprentice, consultant, etc.).
  • Equity was available to anyone that participated in the community.
  • People were invited to each choose their own personal terms and conditions, including rates / salaries, working locations, hours, tools, and so on.
  • People were continually encouraged to synthesise and evolve their joint working practices (with a baseline set of working practices to make this as painless as possible).
  • People were invited to choose their own assignments, tasks and deliverables.
  • Narrow specialisms, such as sales people, managers, and so on were conspicuous by their absence. Everyone was encouraged and supported to become so-called “Generalising specialists”.

And the product of these principles and mechanisms? A hugely engaged and participatory workforce, and a really humane community, which produced a number of essentially defect-free software products, and pushed the envelope in terms of what was possible from a software development organisation.

As an example, here’s just one quote from a continually-surprised customer:

“With INControl, Familiar gave us one of the most successful extranet application projects in CWC history.”

~ Cable & Wireless Communications

– Bob

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.

Amplifyd from twitter.com

Read more at twitter.com

– Bob

What Next for the Agile Community?

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

[Update: Dave’s original post no longer available online – there is a copy at agilevoices]

Whereas I disagree in large part with Dave Nicolette’s full blog post – which I have excerpted (below) – I applaud the sentiments expressed in said excerpt.

Specifically, I profoundly disagree with his assertion that Agile has “crossed the Chasm”. Certainly many organisations have been and continue to dally with it, but the number that have taken it to heart in a *sustainable* way are few indeed (and even yet fewer in Europe and the UK).

My applause for the excerpted sentiments stems from my sharing Dave’s view that “we” (the Agile community) have indeed lost sight of process issues and even more, people issues, particularly “in the large” i.e. across the organisation.

Worse yet, few in the community (Dave included?) have yet realised that the root cause of failure to sustain agile adoptions has been, and will continue to be, not realising the nature of the challenge we face (of which I have written recently, elsewhere: [link – TBD] ).

Amplify’d from dnicolet1.tripod.com

In my view, there are three broad areas in which IT work was completely dysfunctional throughout the 1980s and 1990s, and problems in these areas gave rise to various attempts at improvement, including agile:

  • Process issues – The mechanics of taking ideas from concept to cash.
  • Human issues – Job satisfaction, commitment, motivation, enjoyment, and work-life balance.
  • Technique or (as we would say it today) software craftsmanship – doing work that teaches us something and in which we can take pride.

We have lost sight of these areas of focus (with some notable exceptions) and have become distracted by the attempt to perfect specific activities for their own sake. This is not a proposal for 90 minutes of congratulating ourselves. I think we need to figure out which way we want to take “agile” thinking from this point forward…if anywhere.

Read more at dnicolet1.tripod.com

– Bob

The Nature of the Rightshifting Challenge

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

Hi Pascal,

The Challenge of Sustainable Agile Adoption

You ask about the nature of the challenge of sustainable agile adoption, as I see it.

Most folks see the challenge as mostly one of getting one or more development teams working in an “Agile” way, with the implicit assumption that if we can make that happen, then those teams’ customers will begin to appreciate the benefits, and move progressively towards a wholesale adoption of Agile.

Misconceptions

Sadly, this is not the nature of the challenge. The real challenge is to help organisations – those seeking more effective software (and product) development practices, at least – to change their mindset, aka world-view.

It’s Really about Shifting Mindsets

The majority of organisations contemplating or attempting Agile adoption have a prevailing “Analytic” mindset (see the Marshall Model mindsets chart). The Analytic mindset is not fertile ground for the Agile way of being, characterised as it is by command-and-control management, Theory-X beliefs, functional silos, local optima, efficiencies, etc.

Any sustainable agile adoption must look to a shift in mindset in the host organisation as a whole, else expect eventually to be spurned.

Use Means Relevant to Mindset Shift

Agile adoptions are often a veiled attempt to get to grips with the Synergistic mindset (this characterised by e.g. systems thinking, a focus on end-to-end performance, Theory Y beliefs, etc.). Yet, because the nature of this challenge is most often unrecognised, few relevant or effective means are employed to address the challenges of this transition.

– Bob