Modern Architecture Dogmas

As someone who grew up in a town whose large parts were designed by Le Corbusier, I was interested to find how ideals shaping modern architecture led to disregard for practical considerations of its users. In the paper Form Follows WHAT?, design historian and theorist Jan Michl explains how it happened:

1. First, function provided architects a metaphysical ideal to build on

Functionalists proper, those of the 1920s and 1930s, did not refer to God but rather to demands of the "Zeitgeist", "Modern Epoch" or "Machine Age". Whether references were to God, Nature or History (references to the Zeitgeist, Epoch or Age are of course references to the authority of History) they referred to Purposes of an other-than-human Intelligence. Such Purposes, in not being human purposes, were allegedly no longer subjective but objective, and as such they sanctioned the vision of objective design.

2. Architects used it to progress their professional autonomy

In suggesting that the aesthetic demands of the market were illegitimate or by definition questionable, functionalist architects and designers proclaimed in effect their artistic autonomy and joined (mentally, that is) the coveted ranks of fine artists, as Brent Brolin convincingly argued in his book Flight of Fancy . Modernist architects and designers were re-enacting the liberation process through which painters and sculptors arrived at the status of "fine" artists.

3. Focus on the metaphysical function led to ignoring the users, ...

As the modernist designer's claims to authority increased, the user's status became more and more precarious. Direct references to users, or clients, when they appear in the functionalist texts, are almost invariably of an edifying bent, suggesting that the modernist architect is in possession of authority to decide what is best for them, both in the functional and in the aesthetic sense.

4. ... encouraged architects avoid taking responsibility one's work,...

Since functionalist design philosophy claimed that the essence of designing was the search for intrinsic solutions, the adherent of the functionalist design philosophy was precluded from understanding that the 'intrinsic solutions' he arrived at were based on his own choices and that he - not functions, materials, constructions, or the modern epoch - was responsible for those solutions.

5. ... and talk only to one's professional community

The more [the designer] trusted that the functional starting point guaranteed an objective aesthetics, the less he understood that his formal solutions were in fact addressed to the aesthetic sensitivities and artistic preferences of his own peers, plus a minority of others, endowed with "cultural capital", who shared these sensitivities and preferences.

While the term "form follows function" does not have the same meaning in the IT world as it had in the modern building architecture, but there are some lessons about uncritical adoption following of dogmas that are applicable more generally.

Agile - when does it work well

Lean and Agile are often mentioned in the same sentence and many people assume they are similar. Admittedly, there is an overlap between the two methods – mostly in their focus on pull scheduling, just-in-time techniques and people - but that is where I think the similarities end.

Lean is more of a set of general operational management principles. Although it was originally developed for manufacturing it can be applied to other contexts, including services, or software development. As mentioned in my earlier posts on this subject, in IT Lean is probably best suited to live service support, although under certain circumstance it probably could be used for solutions delivery.

Agile on the other hand is a set of techniques that comes specifically from software development. Lean is more of a manager's toolbox; agile is more of a maker's toolbox. There are people out there who are trying to take Agile concept further, but I am personally too convinced about this as circumstances under which Agile works is much more specific.

Agile is often getting bad reputation. Some of that is caused by too much preaching that can be very offputting to the audience (including myself). Other times, Agile is often an excuse for shoddy delivery. Despite these negatives, my view is that using Agile can be very beneficial as can give you:

• Quick delivery of software features … due to trading off a size of the delivery unit for elapsed time to deliver it

• Solutions that are more fit for purpose... thanks to an increased quality of requirements achieved via disciplined involvement of the user

• More flexible incorporation of changes in requirements … due to generally short timescales

• Better quality of the constructed product … due to continuous integration

However, to get these benefits, one has to leave behind wide-sweeping generalisations Agile evangelists annoy the rest of the world with so often and define the right circumstances under which the approach can work. I would argue that as far as the right context, there are roughly three points that need to be thought of:

1. It needs to be used for the right type of problems

2. Delivery team needs to be very clear about the scope of the agile processes and where they integrate with non-agile ones

3. Customer and the delivery team need to find working arrangements to help deal with uncertainty in regards to budgeting

I will look at these three problems separately in the next parts of this series.

Troubles with the domain

There is a small possibility that this website will soon disappear. I bought the domain several years ago from a small reseller of domain registration services and unfortunately that company went out of business. I now have some difficulty renewing the domain, only a few days before its expires.I hope I will manage to resolve it, but in case I don't, I'm most likely to buy a different domain (name to be announced here).UPDATE: I have managed to resolve the issues and have the domain back. Expect some real posts in near future

Alt.Lean

(...continued from Deconstructing Lean's costs and benefits)

I like Lean's coherence and its focus on methods of achieving business change,  but I have some doubts about applicability of its mainstream form to IT. This post describes why and sketches out some speculations about alternative models to use for IT.

What is waste
To help you understand why I think the mainstream Lean may not work that well for IT, I would like to revisit Lean's concept of waste. Because systematic and continuous elimination of waste is how Lean achieves its results, the decision on what counts as waste is the key to results you get. Yet, considering how important the concept of waste is,  its definition as applied to IT seems to be rather dubious.  There are the seven types of waste, but those apply to manufacturing and its translation to IT services seem rather questionable. You even can't compare categories of waste between different authors. Go and have a look at Poppendiecks and John Bicheno's definitions (quoted in Lean Services). You will realise they are so different you even can't even put them in the same table for comparison purposes!

The difficulty is that that the definition of waste is context specific, and therefore varies across industries, companies and possibly across functions. For a start, it is quite obvious that types of waste will be different between manufacturing and service industries. Inventory is, for instance, one of the biggest types of waste in manufacturing; unfinished code and documents may be a nuisance, but their cost is nowhere near a courtyard full of half finished products. But the types of waste will also differ even between different types of service organisations. What can be thought of as waste in transaction-oriented businesses (think haircuts, Matalan suits, Wagamama meals, ... or IT live service support) will be quite different from tailor-made business  (e.g. interior design, bespoke shirts service,... or many IT projects).

To illustrate my point, let me define a number of examples of waste in IT, all of which will be real and yet none of them will fit the categories of Lean Software Development: Loss of credibility due to incapability to deliver projects predictably,  delivery of projects that are not needed, use of inadequately skilled people, people on standby waiting for their turn on the project, solutions that do exactly what business users 'want', yet fail to meet the real business need, solutions that do exactly what is the business need, but are not supportable, etc. etc.

It may seem a list like this is arbitrary... that's it... until we revisit the first Lean principle.

Customer value

My main point of contention with mainstream lean is its preoccupation with process, and its effficiency, which are to me only one of the many possible customer values. If you want to disagree with efficiency as a central point, there is a need putting up some framework around customer value to help deal with its seeming randomness.

There are undoubtedly several ways how to do this; the framework that can be useful in our case is Treacy & Wiersema's value disciplines. The idea is simple: every organisation has three choices as to where to create long-lasting value: customer intimacy, product leadership or operational excellence. According to Treacy and Wiersema, every organisation should aim to be excellent in one of these disciplines and aim at doing OK at others.

I would argue that what is considered waste will differ depending on which value discipline you will see as core:
- Operational excellence - losses in productivity
- Customer intimacy - any issues affecting customer relationship
- Product leadership - failure to use creativity, loss of innovative ideas

This makes clear (at least to me) that mainstream Lean, including its techniques, is most suited to operational excellence problems. I have not thought about this too much but I suspect that other value disciplines will need rather different methods to address their 'waste' (probably more in a category of  relationship building, consulting skills, communities, individual skill, though there is undoubtedly going to be some process too). Having said that, there is still a space to use Lean to get to an acceptable level of efficiency, at which it is invaluable.

Please add your comments if you disagree or have additional insights.

Unintended consequences

Some fun thought experiments combining few EconPapers:

Aral, Brynjolfsson & Van Alstyne found out that "asynchronous information seeking such as email and database use promotes multitasking while synchronous information seeking over the phone shows a negative correlation." Add to that the conclusions of the paper by Nick Bloom from LSE that shows that "technologies that reduce information costs enable agents to acquire more knowledge and 'empower' lower level agents. Conversely, technologies reducing communication costs substitute agent's knowledge for directions from their managers, and lead to centralization".

Now substitute 'communication technology' with 'twitter' and 'facebook' and watch the results...

Rather than the empowerment of workers, you may get the exact opposite... Maybe it is the time for social networking advocates to make social computing improve the quality of information, or they risk ending up with the results that are exact opposite of what was intended.

Social Computing Case Studies

In the last post I asked a (rhetorical) question about case studies for social computing software. I had a quick look around to answer my own question, and in fact I found quite a few of them. Most case studies are from knowledge-heavy industries/functions, but you can get a decent view on which functions you can get business benefit in:

• Idea management (collecting ideas on process innovation, product innovation)


• Idea crowdsourcing (Dell)


• Customer forums


• Knowledge sharing / management: Rio Tinto,


• Collaborative planning, forecasting & replenishment: Aerochain


• Customer outreach


• Customer communities - Nike, Avon


• Understanding customers (social networking analytics)


• Viral marketing: Quicksilver

An important point is that these tools need to be used in to enrich/enhance/change existing business processes rather than as a standalone technical solution. As Sameer Patel puts it, "... data, and intelligence normally buried in closed process centric activity and systems were pushed into people centric social realms for improvement, only then to be put back into process systems in their newer highly optimized forms." A brilliant example of how this could work is German Fidor Bank.

Sources: Beyond enthusiasm, CIMA Report on e2.0, Sameer Patel: Why Process Barfs on Social, Rio Tinto videos on Communities of Practice and Denis Howlett's Glimpse to the Future.

Reading notes - value of social computing

I need to re-learn to write shorter and more frequent posts, so here comes a shorter piece, while I am working on the continuation of my post on Lean.

I spent two years working for a extremely cost-sensitive customer, followed by a year in business development, so I am now rather sensitised to the whole cost/value discussion. Considering I am interested in the practical applications of social computing, I find the ongoing discussion about business value of e2.0 rather interesting and almost personal subject. Today I came across  Aral, Brynjolfsson & Van Alstyne's paper called Information, Technology and Information Worker Productivity that is interesting by a virtue of being one of the few fact-based contributions to the discussion.

One of the key conclusion of the paper is that "the structure and size of workers' communication networks are highly correlated with performance." This seems to be a proof of the ultimate impact of one's social network on company performance (in hard numbers sense, rather than in woolly e2.0 will make you more in tune with the universe, which must lead to better business value sense).

The only thing that makes me wary is the fact that the research was done using data from a recruitment agency. I  be still careful about generalising this conclusion beyond the knowledge-heavy services industries / functions. We now seem to know how w2.0 fits into a broader enterprise technology landscape and there seems to be case studies from knowledge heavy industries. The question is, do we have any from process-focused and less knowledge-heavy functions?