Category: Organisation

Posted on

XP2009 Coaching Workshop Summary

XP2009 was a nice experience. The Flamingo Hotel outside Pula in Sardinia might not have been on par with a normal Scandinavian hotel when it comes to Internet Access, hot water, and definitely not on par with Italian restaurants when it comes to food. But as usual the people visiting (139) are exceptionally experienced, nice and willing to share and contribute.

My workshop ran on Monday afternoon as planned with dozen+ people. The workshop was presented in the program with its initial title and description, so me acting on the workshop commitees feedback never made it to the actual program. But me and Andreas ran it using staying on the topic listed in the program, “Coaching Agile in Large Scale Development” as well as the ideas and discussion topics of the participants.  Jutta Eckstein participated and contributed much of her extensive experience.

Jutta proposed a discussion around “Creating a Agile Community”, supposedly as a means to inject Agile thinking and that way creating or sustaining an Agile Transition. This actually became the most important topic and after extensive discussions about what a community actually is and how to create a special one on Agile topics, we actually concluded two important things:

First, don’t try to create a new Agile community to initiate change. A new community is hard to start, and you will get limited leverage by talking to believers. Instead find the communities that already exist, and there probably are a lot already. A community is a set of people with some relation to each other, for example that they share some interest; the development team, the lunch buddies, the java experts, the sci-fi readers and the art club. Not everyone of these can be leveraged for an agile transition, but you could probably find something from the agile toolset or value base that you (or someone) can inject in most of them. But you probably shouldn’t advocate agile as such in each and every one, but stay on the topic of the network, for example talk about jUnit and how to leverage that on the Java Expert Community. And of course we talked about using the techniques from “Fearless Change” by Linda Rising and Mary Lynn Manns.

Secondly, try to create a new Agile community, but not to initiate change. Use it to make sure that the belivers, the coaches and the change agents have somewhere to draw strenght and inspiration from. Change isn’t easy so the people that try to sustain change need every piece of support they can get.

Posted on

The Theory of X and Y (and Z)

I am sitting here at the Shiphol airport, Amsterdam, waiting for my flight to Toronto. (A 4,5 hour transit so I have not much else to do but to write a new blog post…) I had a quick look at the books in the bookstore and my eyes fell on a couple of small books with the titles 50 ideas you really need to know about. 50 concepts within a specific subject described in just a page or two. One of them was about management ideas, written by Edward Russell-Walling. I flipped through it, most of the concepts where of course know to me already, but there was one I hadn’t heard of before, or maybe forgotten, The Theory of X and Y. Douglas McGregor described these two theories in his 1960 book The Human Side of Enterprise, thinking that the management style of a leader reflects his/her view of human nature. The idea is that they are two contrasting ideas about how people act and should be treated.

Theory X says that people are lazy, self-centered and must be kept in control with hard rules and firm, and detailed management. These people can only be controlled and only work if their basic lower level needs (physiological and safety, according to Maslow) are at stake. And of course Theory Y then is the opposite, people take responsibility, are full of initiative and will find their own solutions to any problem if they are treated as mature adult persons. Of course drawing on the higher Maslow levels.

Theory Z is then a mix deviced by the Hawaiian-born William Ouchi aimed at mixing American and Japanese practices.

So is the management view of people, or at least developers in your organisation, shifting towards Theory Y? Maybe that is a trend in many areas, but it is interesting to see such an explicit correlation made between American (low level needs, threats, control) and Japanese (higher level needs, inspiration, self-direction) management styles.

Powered by Qumana

Posted on

Why can Agile only apply to Software Development?

Maybe it is just me, but it seems that it is difficult to get the notion across that Agile is not limited to development of software. In Agile communities people seem to be extremely focused on development of software, preferably a web application.

I have always worked in ways which are Agile in value, mechanisms and effect. But they are applicable to development of anything, from systems including hardware to businesses and enterprises as a whole.

When I met Ken Schwaber in September 2007 we talked about his new book, “Scrum and the Enterprise”. I immediately recognized some of the patterns he seemed to paint. Or maybe the patterns matched what I had been looking for.

However, Ken seems to have had the same problem that I seem to face, when I talk to agilists about a broader perspective of Agile. Or maybe that is “out of scope” of Agile…

Posted on

Project Models Overview

On the mailing list of Agile Sweden there was recently a long thread on models for life cycle approach to software development and the Agile community received some critique for maybe not having tackled this view, and of course the favourite topic of “project” was raised. The rest of this post is a translation, with some minor edits, of a post that I did to that mailing list, where I tried to summarize my views on “projects”. This was among other things inspired by a blog by James Shore where he described his way of managing the incorrect use of the term by the rest of the world.

I think the rigid command and control mentality evident in many of models and thinking of the last few decades stems from an increasing suspicion towards larger and larger projects with continuously increasing complexity. And rightly so. As we (the engineering and technology community) have become masters of the current technology, we have tackled even more complicated and challenging projects, and of course the amount of “failures” has grown, or at least the economic impact of the failures. The natural reaction is to try to control everything down to every little detail, thinking that detailed control leads to overall control. The problem is of course that this has been the wrong solution to the problem.
Continue reading “Project Models Overview”

Posted on

A Vaccum Cleaner and an Aircraft

What is the similarity between an aircraft and a vaccum cleaner? Often product developing companies get stuck in old thinking. No surprise there, but what I mean this time is their thinking about what is their primary competence and as a consequence of this, how they need to think about their product development.

Apart from the pure software products there is a large number of products being developed out there, which, some decades ago where hardware only, but now also includes software, often increasingly so.

Since the company has successfully developed products according to rules and conditions which are valid for a hardware only product, it is often difficult to make managers on all levels to understand that once you introduce software in a product, you are in a completely different ballpark.

Software has completely different characteristics, different minimal lead times, different complexity properties which must be taken into account when organising product development. This is is not only a difference, it is also a set of opportunities to exploit. One of the more obvious opportunities is the the short lead times possible, which, if done correctly, could mean shorter time to delivery, shipment and return on investment. This means, of course, becoming more agile, but it doesn’t stop with the development - project, product and company management must embrace the agile principles and change their thinking.

If you cross a vaccum cleaner with a computer you get a computer, and if you cross an aircraft with a computer you also get a computer!

One you introduce software in your product you are stuck with new values, characteristics and opportunities. Too many developing companies fail to exploit these opportunities for rapid return on investment and improved quality.

Posted on

Organisational Refactoring

I have worked in, or in relation to, multiple large organisations. They have all been organised in functional or compentence stovepipes, most adding a project work view across, resulting in a two dimensional hierarchy.

I have always felt that this was not a good way to organise people, or work. I dislike the common project model, for reasons that I might come back to, but my main objection to the matrix organisation is that the strongest binding force between people is working towards common goals, such as the delivery of a developed system, not their function or competence.

Every time we organise people according to competence or function, we will introduce a need to do detailed activity planning, estimation and resource allocation which makes it almost impossible to be responsive to any change in the environment of the development. This is one of the main reasons that rigorous planning more often hinders a project, particluraly to become agile and responsive. For any change the detailed planning of activities allocated to persons has to be updated.

Project planning in the traditional sense, like what is supported by project planning tools like Microsoft Project, is based on the idea that there are activities that can be allocated to multiple persons/resources, e.g. 10 carpenters working full time on the same activity, when in fact most development work is divided into tasks for which a single person is working a fraction of his/her time. This fact makes detailed planning of development work a nightmare, not to mention the follow up. It has also been shown that design is inherently different from much other work in that it often is comprised of selecting one activity, of several possible, to work on, it is this that is the competence of the designer or engineer.

Organising people according to function also induces a sense of protectionism within each such function. “We here at accounting/testing/acquisition…” This often is counterproductive since many such functions have other agendas than the total enterprise, leading to sub-optimal activities.

One way of addressing this problem is to describe the processes so that they encompass the whole enterprise. Again, this works fairly well for some types of organisations, e.g. those which rely on workflows such as insurance companies. And again, development stands apart, there is no workflow that start with the customer requirement and ends with a shipped system.

For a long time I have belived that the organisation is an important view of the enterprise, and that there exists organisational patterns and anti-patterns. And after having read Martin Fowlers book on Refactoring I realized that organisations probably could be refactored too. Unfortunately I have never had the opportunity to work with this issue, but recently I visited Organisational Patterns by Coplien&Harrison. Unfortunately it focuses on Agile Software Development, (although they admit to have opted for “agile” from a marketing perspective) and not on Development Organisations in general, but since the total text of the book is available I thought I’d share this link. It is interesting to see that they present organisational patterns as an alternative to classical improvement targeting the process.

I have yet to read the whole book, but even the introduction is interesting, particular the notion of the four styles of software development, of which “agile” is the fourth and current, and its connection to social styles. I hope to have time to read the whole book in the near future.

Perhaps with this set of patterns the idea of Organisational Refactoring can come true.