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.

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

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…

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.

Software development has characteristics that make it possible, and even natural; to handle the result of it in manners different to the way we do in other engineering disciplines. One example is that the time between a design change and its actual implementation in something that can be delivered can be extremely short, seconds, even. It is nothing but natural that “Agile” as concept was born in this environment. But many people seem to think that it is only in this environment that “agility” can exist. My own view is that “Agile” is a structured way of tackling the unknown, or uncertain, future, and despite this uncertainty, be able to deliver as good a result as humanly possible given the actual circumstances. (We have come to learn that the alternative, i.e. to guarantee the result upfront through command, control and exercise of power and forced promises, is not possible even in theory.) But it is unfair to blame the current confinement of agile principles to the software discipline on the Agile movement. It is after all the people around us that are hard to convince. And we need to face these very strong counter forces, if we intend to win over them. (Most of us have probably heard Craig Larman talk about his parallel to the bloodletting as the “true” way of fighting the diseases of the Middle Ages.) But let us work together to find methods and opportunities to break away from the grip of these powers, so maybe we can do it in less than a hundred years.

Projects, as a form for organizing work, has been promoted as the most effective for decades. I think there are a number of reasons for this:

1) a group of people working towards a common goal is more efficient than single individuals
2) if you define a measurable goal it is possible to objectively decide if it has been achieved
3) a goal can be subdivided into activities that can be estimated giving a resource budget
4) given a resource budget you can calculate the cost and thereby the ROI of the investment into the project
5) when you have an investment budget you can follow up against it

Since the term “project” can loosely be interpreted as “a number of people working towards a common, measurable, goal” it is possible to fit the term to almost anything. Which of course also has been done. So, naturally, there are projects of all shapes and forms, and we who criticise the project form (ok, I’ll only speak for myself!) occasionally get a little undiscriminating since most models has over-interpreted the term project, or at least not drawn the conclusions that the project form has some drawbacks and must be supplemented with other models and views.

I am sure that item 1) above does not imply hundreds of developers, testers and architects spread over half the globe, which is not uncommon these days. I think it means what we today talk about teams. So the current scale of projects was not even envisioned when the project form was “invented”.

Item 2) is aimed at focusing the work on a result, e.g. a delivery. But what if the goal is something more elusive? An improved enterprise, maintenance of an existing investment such as an IT system or a software product? Then the goal is no longer limited and nearly unattainable. This is obviously also a problem.

3) is often interpreted as “activities that can be performed by one type of persons with a particular competence”, e.g. 30 masons in four weeks, or 5 requirements engineers in 5 months. By doing 3) we can do 4) and 5) which obviously is very important to any investment. But it only covers the “cost” side, not actual progress or even delivered value.

My main concern with the “project model” is that its interpretations are mostly locked in “resource and cost monitoring”.

While estimating activities like analysis and requirements work, design, implementation and test etc. may be useful to get an initial cost budget, it is however no progress tracking to follow-up actual hours worked in the manner that e.g. the “Earned Value” models does it. When you actually start the project you need to turn from resource budgeting to progress tracking in real measurable results in the “product”. (E.g. software functionality, work model of the enterprise or whatever is the actual result.) These measurable results must become our items for tracking progress.

Another big weakness of the project model is when it is used in a “matrix” organisation. In such an organisation you often find allocation of people from a competence oriented line organisation to a set of concurrent projects. In this situation it does not take long before people with some important competence is “working” 20% for 5 different projects, which of course is not possible even in theory. (My presentation from the conference “Agile i Sverige 2007” contains a demonstration of this problem.) Used in this manner the project model becomes a tool to pretend to be able to cope with more work than there are resources for. This pretence does not become evident until the projects needs to signal delays (which, given the project manager “chicken race”, is as late as possible. The common counter measure is to raise the priority of the project in the deepest crisis, which usually doesn’t mean that other projects are deferred and work on them suspended or diminished, since their delivery schedules where already “committed”…

IT as support to an enterprise is a form of project that has a very high degree of continuity to it. For these projects the investment calculus is almost impossible to do in the classic project manner. Instead a present value analysis akin to the one performed for other capital assets like machinery, freighters and industrial buildings seems more appropriate. There is an investment, certainly, but also a non-negligible cost for maintaining, sustaining and operating. Active Maintenance is a good term for how to handle these circumstances. (Actually, this term, which is even better in Swedish, is the title of a report written by Peter Tallungs, then at Kentor, currently at Objectware.)

Some product development would look very much like this. I am referring to software products like Microsoft Office, SAP etc., where continuous development is the only survival strategy. Here also, Active Maintenance seems like a feasible model, even if there is some need for the investment view before taking on new product development, development of new functionality for diversifying the product or for markets where break-even need to be reached or surpassed.

There is also much product development that is very much “project”, even though it contains a great portion of software. Development of almost any product that is manufactured in larger series (mobile phones, set top boxes, cars…) is very much more goals oriented since the start of a product batch is kind of “final”. This is another facet of the project concept.

Even in companies with this kind of product development I often see a form of products that might be called the “Scandinavian model”, a kind of internal platform products. Developing and maintaining a platform of common functionality that is adapted to different customers, markets or application areas drastically reduce the “cost to market”. F-Secure, a Finnish anti-virus company, presented its approach at the Scrum Gathering in London 2007 and was the most recent example I’ve seen. I don’t know how common this strategy is in other parts of the world, but I see the same strategy in many of the companies I have worked with. In these situations the standard project model is quite insufficient.

I am convinced that there are a lot of projects out there run by cross-functional teams of 10 or less full time members, working iteratively towards their delivery, tracking their progress using concrete results, not hours worked. For these projects the project model is no problem, it does not get in their way, and probably is beneficial to someone.

But problems with the project model do not only exist with organisations, customers and managers. Has someone seen a CM tool that in its “New” menu has “Product” instead of “Project”?

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.

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.