| More blogging and aggregation |
|
15 Jan 05 |
|
[print
link
all
] |
|
Last week, a new weblog by Nynke Fokma went live, called Bommelstein. Welcome Nynke! . Nynke writes, amongst other things, about Systems Thinking and (In)Congruent Communication .
Recently I've been working with Marc Evers and Nynke on a site about systems thinking, with a weblog-aggreggator containing weblogs from systems thinkers and a wiki. We made this invitation:
Have you noticed that changing your software development method changes your organisation?
Wondered why the customer can't keep up with the programming team?
What to do about it?
How to get a team to use unit testing?
Doubted whether the lack of unit testing is really the team's biggest problem?
We found systems thinking to be a simple but powerful technique for finding answers to questions like these. When seeing organisations, projects, and teams as systems consisting of interrelated and interacting parts, one enables a relaxed focus on relationships as well as the whole and can easily reveal self-reinforcing feedback loops and not-so-obvious causal relations before they trip us up.
Would you like to change the rules of the game?
Figure out what you can do as systems thinker?
With a little self-esteem and imagination?
Co-create flexible processes congruent with desired products?
Increase awareness of your self and what is going on around you?
Turning on feedback loops?
Weave your thoughts with others in a wiki?
We cordially invite you to join us on www.systemsthinking.net
|
| Passing the ball at the SOL Dutch Open |
|
15 Jan 05 |
|
[print
link
all
] |
|
Now I'm back from my trip to Consultants Camp and San Jose, I'm still sleep-deprived and jet-lagged.
Neverheless, I went to the open space conference of the Dutch Society for Organisational Learning. The theme of this day was Unlearning. I had a great day, meeting interesting people from a variety of fields. Marc Evers and I put up a play of Warped Juggle on the planning board. We had a cozy session with five participants, which gave us some new perspectives on the Satir Change Model, amongst others - Unlearning happens during the chaos phase, and with scenario planning we might welcome chaos, rather than experiencing it as painful. We put up more output from this session on the SystemsThinking.net wiki.
|
| Agile Open wiki and mailinglist open |
|
15 Jan 05 |
|
[print
link
all
] |
|
I wrote earlier about the agile open space conference we're going to organise in Belgium, in the Spring of 2005. It is most likely going to take place in first half of May. We were thinking of late april, right after the Scrum gathering. There were some public holidays in that period, so that doesn't fit.
You can now post your interest in participating at the agile open wiki. The goals of this conference are set by the participants, so you're welcome to add your goals to the wiki, or discuss them on the Agile Open mailinglist. The current round of goal brainstorming already generated some interesting ideas. We seem to be drawing people interested in Agile from inside and outside the software development community.
|
| Lean And Not Mean |
|
15 Jan 05 |
|
[print
link
all
] |
Pascal van Cauwenberghe recommended me to read The Toyota Way by Jeffrey K. Liker. I can see why now :-) I resonate with many of the ideas and paradoxes, articulated much more clearly than I can yet. I'll go into some of the ideas with quotes from the book below - I find so much to quote I recommend you read it for yourself if you're interested in the topic. The Toyota Way book focuses mostly on the Toyota Production System. As Liker says:
I want to be clear, that the Toyota Production System is not the Toyota Way. TPS is the most systematic and highly developed example of what the principles of the Toyota Way can accomplish.
I find The Toyota Way easy to read, it lends itself well to be read chapter by chapter while I'm sort of in the midst of a tornado this week: moving to a new house in Eindhoven, doing two consecutive nights of game workshops (Who's dropped the Ball with Marc Evers for xp.be in Leuven, and Game Of Goose with Nynke Fokma for Ordina in Nieuwegein), as well as working with ZeelandNet on their next round of improvement through Agile Software Development .
Misconception: TPS is a set of tools
with mysterious sounding acronyms like 5S, JIT, Kanban. Unfortunately I encounter many (project) managers who are looking for 'tools' - handy spreadsheets, planning forms, testing-tools and work practices that will solve all of their problems. Some 'tools' can enhance your productivity enormously (e.g. Test Driven Development). If you want to go beyond that, you have to go beyond the practices into the principles - that is the way I see eXtreme Programming, its values and practices form a system. I often ask people:
Do you value the practices, or do you practice the values?
The Toyota Way is, like XP, an evolving system of values and practices. Fujio Cho, President of Toyota Motor Corporation is quoted saying:Many good American companies have respect for individuals, and practice kaizen and other TPS tools. But what is important is having all the elements together as a system. It must be practiced every day in a very consistent manner - not in spurts - in a concrete way on the shop floor.
The book proves this principle applies to practice with stories about the birth of Lexus and the Prius. These stories show the work practices at Toyota continuously improve. Toyota maintains, even in times of prosperity, a crisis mentality. When there is no crisis, one is created, so participants continue to be challenged. These challenges can only be overcome by continuous learning through (amongst other things) questioning assumptions and embracing change.
Misconception: Lean equals Mean
A common mistake about the Toyota Production System (TPS) is, especially when it is called Lean Manufacturing, that it is mean. Recently, a session about Lean Thinking and the Theory of Constraints Pascal van Cauwenberghe and Rob Westgeest submitted to SPA2005 was rejected. One of the reviewers commented:
This reminds me too much of the Six Sigma style methodology we are implementing at name of company witheld that I just hate!
Six Sigma is a statistical process for optimizing large manufacturing processes. Many small-scale software and hardware companies are now applying it on processes which are too small to consider applying statistics to. TPS is not like Six Sigma. It emphatically calls on the creativity and spirit of the people involved to learn and solve problems. Terms like Eliminate Waste and Lean are rapidly interpreted by some people as 'downsizing' - I think that view is short-sighted: Eliminating waste means eliminating steps that do not add value for the customer. This means only value-creating and value-adding activities remain. This leads eventually to high-customer satisfaction and a long-term relationship with the customer, which means for Toyota a stable and growing stream of revenue, leading to high profit margins, a large cash-reserve and long-term job security for the people working at Toyota. As the book says:
Lean is about developing principles that are right for your organization and diligently practicing them to achieve high performance that continues to add value to customers and society. This, of course, means being competitive and profitable.
I see how many of the principles apply to my projects - there are many similarities with Agile Software Development and Agile Business Consultancy. I'll ruminate some more about that offline and possibly come back to that later.
|
| Extreme Programming Explained version two |
|
15 Jan 05 |
|
[print
link
all
] |
|
Rachel Davies blogs about the second version of Extreme Programming Explained by Kent Beck. Apparently it is a complete rewrite from the first version, with revised principles, practices and values. Like Mary Poppendieck, Kent Beck is now also apparently making the connection between The Toyota Way and Agile Software Development explicit.
The second edition of Extreme Programming explained now also contains more graphics apparently. The three rivers' website contains some samples: Extreme Programming in Pictures. These are nicely hand-drawn mindmaps that seem to show the systems thinking perspective behind Kents' new take on XP. The first edition of Extreme Programming Explained also had that systems thinking thing going, since the practices and values form an interconnected whole - finding out how the whole is formed was left as an exercise for the practitioner (which was educational :-) ). I hope the new book goes into some more depth explaining some of the 'soft' practices and the values.
|
| What happened to (Design) Patterns? |
|
15 Jan 05 |
|
[print
link
all
] |
|
Rachel Davies points to A history of patterns on the c2 wiki, which reminds me of something I have been ruminating over for the past month (and now I might be ranting ;-) ). The history on that page ends in 1999. What happened to Design Patterns since then? So far, I am somewhat disappointed about the effect Design Patterns has had on software development practice.
Design Patterns have had a positive effect, in that they facilitate communication amongst programmers, by giving them a common verbiage. They can use words like Composite or Decorator to abstract complex software structures and behaviour. I haven't seen many pattern languages for programmers and users (or, to stretch the building metaphor a bit further, inhabitants), like e.g. Tools and Materials, as Alexanders' 'A Pattern Language' does. The use of patterns in practice seems limited to the catalogue in the Design Patterns book - most programmers that use Design Patterns don't seem to bother reading Alexanders' books or the PLOP (Pattern Languages Of Program design) series. On the pattern languages side, I was hoping that something like 'Domain Driven Design' by Eric Evans might bridge the gap between programmers and inhabitants. These comments on bookshelved lead me to believe patterns were merely used for the format, not the spirit of the book (I have yet to read it for myself to make up my mind).
It is possible, that I'm just being impatient, and patterns are not disappearing as just a fad. If so, they are likely to reoccur again. The use of patterns is probably ancient, as this example How "Pattern Books" Fueled England's First Speculative Real Estate Market shows there where pattern books around 1600 explaining how the real estate markets worked. Maybe after the first flurry of lets' describe everything in pattern form, we might yet see some actual pattern languages (rather than mere pattern vocabularies) for use by all inhabitants of software.
|
| Five Freedoms |
|
15 Jan 05 |
|
[print
link
all
] |
Yesterday, I was reading again in Quality Software Management volume 4 - Anticipating Change by Gerald Weinberg. In chapter eight I found a description of Virginia Satir's Five Freedoms, which goes nicely with the Learning to See theme from the day before: - The freedom to see and hear what is here, instead of what should be, was, or will be.
- The freedom to say what one feels and thinks instead of what one should.
- the freedom to feel what one feels, instead of what one ought
- the freedom to ask for what one wants, instead of always waiting for permission
- the freedom to take risks on one's own behalf, instead of choosing to be only 'secure' and not rocking the boat
these originate from The Satir Model: Family Therapy and Beyond.
|
|