On the behalf of my current customer I went to PLM Europe in Frankfurt on October 9-11, a UGS User conference. UGS is one of the major suppliers of software supporting product life-cycle management (actually meaning parts, articles, hardware). After visiting three days of presentations and workshops, some more marketing than workshops, some mediocre and some really inspiring, I found that many things being said was also applicable to software. But there are genuinely different properties in software and software based products which this branch of the engineering business has yet not understood. I also realized that replacing the first letter in the PLM acronym with an A gets you ALM, Application Life-cycle Management, which has created some whoa lately. I guess I’ll have to dive into that area also.
Coder’s Dojo Sweden is open!
Yesterday Andreas Larsson and myself hosted the first ever Coder’s Dojo in Sweden. If you have never heard about it before you can visit its home page and explore more.
It was an interesting experience. Having run through the Bowling Kata a number of times, both together and by ourselves, we still found that discussing with people was a learning experience since many of the attendees did not have the experience we did. And as always, talking about something forces you to be clear in a way you don’t need to otherwise.
My personal insight with the Kata the way we played it out (inspired by Uncle Bob’s presentation of it) was how strong the urge to create new classes is in all of us. Andreas and I fell into that same hole when we did the Kata in Oulu the night before XP2006.
I also discovered that I had insights that I where not aware of with regards to the brittleness of testcases; that you should be careful to test the intended behaviour, and not the design. E.g. when doing the first test case for the Bowling Kata, don’t test that the score of the created (presumed empty) game is zero. That’s implementation! The required behaviour (and the only thing that should be tested) is that calculating the score, after all the rolls of the game, should give the correct result.
And of course, you can find a lot of thinking on the BDD (Behaviour Driven Development) on the web.
Development is Investment
One irritating circumstance in the world around development is the fact that customers and company managment tend to view the voyage of development as something that has to be calculated like any other investment. Or at least I thought it was irritating until last week.
This investment calculus that has to take place upfront drives big design upfront, detailed planning and everything bad that goes with a model with “upfront” in it.
But last week I had a discussion with my two collegues about how to draw a curve illustrating the fact that we need to get early payback from any development project or activities. I suppose you have all experienced the fact that given multiple checkpoints a long the way, as opposed to only a single at the end you are much more likely to hit the target (after all that is what being agile is all about).
We started talking about how to visualize the fact that worked hours (the most common tracking parameter for development projects in the world, it seems) is not a good way to measure, and consequently show in a follow-up diagram, project progress. Instead it is the value of the current development result that should be put on the y-axis. This is actually nothing new (what is?), already function points and earned value are classical methods to do something this.
But the real insight here is that if we just could turn this earned value (which in agile terms of course is working functions delivered) into money we would be in a position to argue all the benefits of agile thinking to management and into the contract problem area.
Why? Because to a company executive it is easy to understand that the value returned did not come from exactly what we planned but we could still cash in the same value. Dollars for dollars, as it where. This opens up a possibility to work agile in rigidly contracted environments also, if only we can formulate the contract in terms of investment and return on investment.
So how would we estimate progress in terms of ROI? Well, I guess that anyone that can guess the ROI on a completed product, given some essential functions and properties, could also do a fairly good job of estimating partial value of same. So, do an earned value estimate on each function (or story or UseCase according to your preferences), follow up on that, and handle any change in features also as a change in the earned values. Then trade one earned value for another and, if they are comfortable with the estimated values, they will have no objections to whatever changes your agile project uncovers or requires.
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.
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.
Hello world!
Welcome to my blog! This is my first post so I’ll start out by giving some retrospective words to warm myself up and introduce myself. If you have read my About, you will already know that I have developed software and systems for 25 years. During those years I have seen the software industry go through multiple evolutionary stages, each at least a little bit more evolved than the previous.
During the 80’s there where not much talk about development processes or quality. Instead everybody tried to do as good as we could and shared our experiences by simply working on the same projects. We did not succeed every time. And without deeper understanding of the relations between projects, management and development the increasing need for software caused many failures, creating a lack of faith in developers, in particular, software developers.
In the 90’s there was a surge for process and quality, probably as a reaction to the pour results in the previous decade of software development. This led to development of processes and models inspired by other, more successful, parts of the industry, such as manufacturing, buildings and road construction. During this period project where better planned, milestones and tollgate decisions where passed and taken in abundance. This created an illusion of control, but in fact, the number of successful projects did not seem to rise. So the persons advocating following processes, including myself, went to describe the processes in more detail to get even better control, planned the project in more detail to get an even better view of progress.
Development became viewed more and more as manufacturing at this level. But, at the same time models, frameworks for architectures and design patterns evolved which helped conversing over designs.
During the last decade or so I would say that we have seen some reactions to the fact that rigorous process and standard quality measures have not had the expected effect. I’m talking about the Agile movement.
When I first discovered the RUP in the early 90’s I felt a sense of revelation, “This is a good model of how I have always felt it should be done.” So I used and advocated RUP for many years. But, of course, RUP could never be applied, not as it was described. Neither did many managers understand the profound difference between classic “waterfall”/tollgate development and iterative/incremental development. So I realized that RUP was just a part of the solution, and not a brick cast in stone either. Parts where generally applicable, but some parts definitely expendable.
When I started to read about XP, the same sense of revalation dawned on me. Here I found other parts that where essential to the large picture of software development.
So, I guess, what I am trying to say in this my first entry is that there are many tools, methods, models and processes. None of them are correct, but very few of them do not contain anything of value. I am convinced that any good developer or manager of development has to take all these to heart and select the proper tool for the job.
This brings me to the real reason why I felt I had to start my own blog. I stumbled across Cedrics blog Agile People Still Don’t Get It. There are many people out there which are not insightful enough to realize that there is no one solution, or even truth. Everything is a question of balance and risk and agile techniques are about doing this balancing in a responsive way.
I hope to share my views on this balance in future blogs. Watch this space!
Here’s a test of pingbacks which I seem to have a problem to get to work…