Agile Management | NOOP.NL

PDCA vs. PDSA vs. OODA vs. BML vs. PSR vs. YMCA

In my little book How to Change the World I use the PDCA model to describe the fact that it is useful to have an iterative approach to change management and continuous improvement.

Some people prefer PDSA over PDCA because it “emphasizes learning over inspection”.

Some people prefer OODA over PDCA because they believe the PDCA model is about “analysis of complicated situations”, while the OODA loop suggests “sensing of complex environments”.

Some people prefer YMCA over PDCA because it supports a “healthy body, mind and spirit”. (Actually no, I just made that up.)

And then we have Build-Measure-Learn and Inspect-Adapt and Probe-Sense-Respond and all those other simple models that tell us to try things iteratively while learning from feedback.

I sometimes prefer LMAO because all models are wrong, though some are useful. And to me the useful ones are those that help me to change the world and enjoy my job at the same time.

If you care too much about the differences between PDCA vs. PDSA vs. OODA vs. BML vs. PSR vs. YMCA you have probably achieved too little to understand that the differences usually don’t matter.

As Jerry Weinberg said, “Don’t take your models too seriously.”

And that also applies to this blog post.

Agile Application Lifecycle Management (ALM)

How to use complexity thinking to combine Agile software development with Application Lifecycle Management (ALM).

This is a new presentation I did yesterday during a keynote for Unit4, a Dutch software company. I was asked to talk about Application Lifecycle Management (ALM).

Of course, you know me. I couldn’t resist inserting some information on Agile software development into the talk, including some slides from my earlier presentation about complexity vs. lean. But I think the audience didn’t mind. Especially the two people in the middle that were asleep.

Agile Application Lifecycle Management (ALM)

View more presentations from Jurgen Appelo.

Jurgen Appelo is an award-winning speaker, trainer, and author of Management 3.0, a management book for software development. You can hire him as a speaker or trainer, to add some spice to your discussions, workshops, or conferences.

Iterate Your Flawed Models

I recently came across the Top 15 Worst Logo FAILS ever. It lists a number of logo designs that, in all their innocence, invite all kinds of associations with some not so innocent human behaviors. I laughed so hard that part of my brain was dangling from my nose. I suppose it is proof of my wicked mind that I immediately recognized the problems in all logos.

Unfortunately, a lot less funny was someone’s comment that my six-eyed monster, which I designed as an illustration for my upcoming book, looks suspiciously phallic in nature. Despite having a wicked mind, I had never noticed this myself. But now that the association has been mentioned, I am unable to get it out of my brain. I just cannot laugh hard enough about it.

At a recent Agile Holland event two other flawed designs were presented and discussed with the audience. One of them was RUP, and the other was PRINCE2.

The RUP model is flawed because it invites associations with the waterfall process.

The design (I apologize for the unsharp photo) clearly suggests that the RUP process starts with n iterations of specification. And there are no frequent releases in this model, because a release into production (as suggested by this model) only happens in the last phase, after everything else is finished.

The PRINCE2 model is flawed because it invites associations with Big Upfront Process Design.

The model depicts lots of process boxes, and they all have arrows leaving and entering them. (Note: the picture I took here is the simplified version.) Such a design makes it hard for people to see that they are allowed to pick and choose their own elements from PRINCE2, because if they do they end up with many arrows dangling from boxes that go nowhere.

Now, don’t get me wrong. The intentions of the creators of all these models were good. The Arlington Pediatric Center never intended to be a seen as a pedophilic center. Martie the Management Model never hoped to be seen as a male, six times over. And the RUP and PRINCE2 designers never wanted to suggest that you should create a big waterfall-like process upfront.

All models are wrong. Some are useful.
And some are just badly drawn.

As the designer of a logo, illustration, or process model, it is hard (if not impossible) to predict what people will recognize in your designs. You cannot easily peek into the devious and twisted minds of your viewers. It is easiest just to show them what you’ve designed. Let them have a good laugh. And then try again.

As I will.

Jurgen is an experienced author, trainer, and speaker. Why don’t you hire him to add some spice to your company event or seminar?

 Twitter -  Subscribe - Newsletter - LinkedIn - SlideShare

Latest, greatest and favoritest posts: If You Want Something Done, Practice Your Patience About Project Success and Failure I Follow My Rules, You Follow Yours

This Software Method Doesn’t Work Here

I’ve never heard a good cook say, “this recipe doesn’t work here.”

What if a cook follows a recipe to the letter, and it turns out that the result is not what the cook expected? Can he say that the recipe failed to “work”?

A recipe is just piece of text, nothing more. You cannot say “The recipe doesn’t work,” because the recipe doesn’t do any labor. The cook is the one who does all the work.

If the cook doesn’t get what he expected, my guess is that he’s just an inexperienced cook. Maybe he didn’t compensate for the bigger-than-average eggs that he used, or the hotter-than-average oven, or the low temperature in the kitchen, or the bland taste of the cheap spices he got from the supermarket.

“The recipe doesn’t work here” is probably just an excuse for “I didn’t work to understand how to adapt to local circumstances and make the recipe work.”

So…

What if someone says “this software method doesn’t work here”?

Jurgen is an experienced author, trainer, and speaker. Why don’t you hire him to add some spice to your company event or seminar?

 Twitter -  Subscribe - Newsletter - LinkedIn - SlideShare

Latest, greatest and favoritest posts: Choosing Authority Levels for Team Members Your Project Will Suffer from Power Laws I Follow My Rules, You Follow Yours

The Schizophrenia of Scrum

I sometimes get the feeling that there are two versions of Scrum.

The first version is the one that says that “Scrum is not a methodology, a defined process or set of procedures. it's an open development framework.” (Jeff Sutherland) and “Scrum is a values-based framework; it is not a methodology, not a process, not a tool.” (Tobias Mayer)

Scrum version 1 is the Agile version of Scrum. It is the one that values people over process, and principles over tools. It says Scrum is a framework that is open to change, and it can even change itself.

The second version is the one that talks about “the dangers of customizing Scrum inappropriately and the problems that arise from an incomplete Scrum implementation” (Ken Schwaber) and “A Scrum checklist as a simple tool to assess your current implementation of Scrum” (Henrik Kniberg)

Scrum version 2 is the Defined version of Scrum. It is the one that says your implementation and customization of Scrum can be good or bad, based on a small number of best practices, as defined by its founders.

But the practices that Scrum version 2 claims to be essential (like having a Scrum Master, daily stand-up meetings, and weekly sprints) are usually process-based, not value-based. People tick off best practices, not values and principles.

So my question then is, if I do Kanban, while still adhering to the values and principles of Scrum (but with my own replacements for its defined practices), am I then still doing Scrum?

If you answer 'No,' then apparently part of the Scrum framework is still about process, not about values.

If you answer 'Yes,' then apparently you think it's possible to do Scrum without anyone being able to recognize it as such.

I fear that I'm on both sides, and I'm feeling quite schizophrenic...

(image by Victor Bezrukov)

 Twitter -  Subscribe - Newsletter - LinkedIn - SlideShare

Latest, greatest and favoritest posts: In Defense of Scrum (Please Stop Pissing on It) Self-Organization vs. Emergence ScrumButs Are the Best Part of Scrum

Understanding Before Tailoring (guest post)

This is a guest post by Scott Duncan. Scott is a Certified Scrum Practitioner who has been involved in all facets of internal and external product software development with commercial and government organizations since 1972. Scott has spoken a many conferences and seminars over the years including many agile ones over the past 5 years both in the USA, Finland and Israel.

A lot is written these days about agile methods having “crossed the chasm,” that is, moving from early adoption and more risk-taking organizations into traditional IT and more risk averse organizations. In one sense, this speaks to the benefits people have begun to realize from adopting and agile approach. In another, however, it means that some “bandwagonism” has also taken place and organizations are moving to agile because it seems to be what others are doing. And this occurs largely because many who have moved tell stories of success with an agile approach. However, like many new things in software development, not just agile methods, this adoption across the chasm shows signs of how people became involved with case technology, ISO 9001, CMM, etc. in the late 80s and 90s:

1) Those who have adopted it either do not say much about their experience or speak largely of their success with the new approach. Hardly any company wants to stand up publicly and describe how they failed at their attempt. Thus, most of the “buzz” is positive, suggesting to others that they need to be getting involved with this because success seems to be the norm.

2) The desire is to get going with “something,” so the training and consulting sought by companies is usually focused on “how-to” knowledge. This allows them, as soon as possible, to start “doing it.” To get to this stage of bringing in a new approach, some senior management probably had to be convinced to invest time and money in the effort as well as accept the potential risk that it does not go well. Thus, that management would like to see something done to prove the approach as soon as possible.

3) The new approach is likely not going to fit into the current organizational structure/culture without some (potentially significant) change. Just how much change an organization can truly tolerate has a lot to do with their risk-averseness and place on the stability spectrum. There will be well-respected, thoughtful people who will not be comfortable with what these new approaches will demand. They will want to see a more, at least, “go easy” approach for the adoption effort.

4) There will be talk of how to “tailor” the approach to “fit” the organization since it will appear only reasonable that no generic new approach can be ‘right” for each and every organization. So practices and techniques will either be swapped out for ones closer to what the organization already does or, in some cases, abandoned altogether as “not yet feasible” because of the level of change required.

5) Finally, there will be innumerable firms offering organizations a path to implementation which will support the idea of “doing” as soon as possible. Many of these will be over the chasm companies themselves who have decided the new approach is the “thing to do” to show they are “leading edge” to their customer base which is expecting them to know the new method. These companies will have some of the same issues making the new approach fit into their existing culture and offerings. In some cases, this will result in trying to make the new approach look a lot like the company’s existing approach to show the client base that no radical change has to occur. This will make clients more comfortable with the idea of adoption since it may seem to be relatively easily accommodated in an existing way of doing things.

Again, regardless of the approach, what is often missing in an organization’s early understanding of such new approaches are the basic principles (and values) behind the external practices, techniques, and how-to guidance. Thus, if an organization does not understand what is behind a given practice/technique, tailoring can limit, even destroy, the point of the practice. The point is usually more than the outward behavior the practice asks people to emulate, so changing the practice because the behavior is too challenging or, apparently, unnecessary for the current organization ends up with a replacement that may not produce the result needed (or, indeed, produces some result that works against effective adoption of the approach as a whole).

For larger, more comprehensive programs with numerous requirements and processes to implement along with the associated documentation, the impact of a change here and there may be negligible in the overall implementation. It is likely to be top-down driven and involve substantial parts of the organization with significant expectations and guidance for how new processes will be implemented. Such efforts are also likely to fit in with, or be made to fit in with, existing organizational structure. Large organizations also know how to absorb these comprehensive programs without overt opposition and failure but also without benefits that equal the cost of implementation. (Aspects of the cost can also be smoothed over as it can be hard, in a traditional, phased-based, sequential lifecycle, to completely trace and account for all the time spent. Proofs of ROI can be easy or hard to come by depending on which way people actually feel about their tolerance for change.)

So what does all this mean for agile adoption?

Agile approaches are sufficiently low on formality and high in visibility that actual resistance to change cannot be hidden very effectively. The short iterations with clear delivery goals make it hard to cover up lack of achievement of those goals. This is all good news for an agile approach. However, rationalization for tailoring agile practices to fit the organization is less easily resisted. When such tailoring misses the point of the original practice it can be harder to definitively prove that the tailoring is causing any lack of success adopting the agile approach.

For example, take the XP practice of pair programming. Some people find pairing to be uncomfortable, intrusive, slow, not a good use of “resources,” etc. as a way to get code written. They may, then, simply abandon this practice, not knowing, perhaps, that there are other possible practices that would not as completely dispense with some of the goals of pairing (e.g., ping-pong programming, side-by-side programming). If an organization does not try to stick with the agile values and principles and understand that pairing isn’t simply about getting code written, their tailoring may easily lose the communication, feedback, visibility, trust-building, design integrity, etc. that are part of this practice.

Having experienced large organizations deciding to “go agile” and diving in after a couple days of training and minimal (or no) coaching, I believe this lack of a firm understanding of the values and principles causes much confusion and difficulty later. Indeed, from the very outset of the effort, enough tailoring may have been done such that the organization never does experience the full benefit of an agile approach. In this way, further tweaking and tailoring to “fix” the problem of less benefit than expected will seem even less divergent from the values and principles. Efforts to argue against such will seem to be, as noted above, a dogmatic stance taken by those since they may not be able to properly verbalize what the tailoring is doing to the agile approach and why they advocate sticking with the recommended agile practice(s).

For this reason, I believe it is critical, early in the training/exploration associated with an agile adoption, to make sure everyone who will be involved with or affected by the adoption effort understands the agile values and principles. In this way, when they feel they need to tailor something or as they suggest changes to their process through retrospectives, they will be better able to recognize whether the proposed change to an agile practice/technique is moving the work further from the benefits intended by an agile approach and which the practice has been design/developed to support. Indeed, without this understanding, dogmatism may arise in defense of the practices, making adoption harder because advocates may be seen as refusing to support the organization in making the transition. Likewise, without such understanding, efforts by the organization to “warp” the agile approach to more comfortably fit the “dysfunctions” that exist will not be as easily resisted since the discussion will revolved around possible minutiae of practices and techniques not the harm such changes may bring because of how they subvert the goals of agile values and principles.

(images by mshades and Wolfgang Staudt)

 Twitter -  Subscribe - Newsletter - Bookmarks

Latest, greatest and favoritest posts:
The Big List of Agile Practices
The Decline and Fall of Agilists
AINO: Agile In Name Only

The Decline and Fall of Agilists

There once was a time when being agile was being a visionary. Agile experts wrote books on how adaptive software development is about managing complex systems (Jim Highsmith), why agility is a cooperative game (Alistair Cockburn), and how being agile (or lean) requires a new way of thinking (Mary & Tom Poppendieck). The Agile Manifesto itself was a visionary masterpiece. So simple, so powerful, and so... Well, I wanted to say 'perfect', but nothing is perfect. Not even me.

Then came the agilists...

Nowadays, agilists are telling me that in order to do Scrum or XP or any form of Agile successfully, you must refactor. Sorry, not optional. Necessary. They tell me that everybody needs unit tests, and that Scrum makes things worse by ignoring important (but hard) agile engineering practices, and that you're not agile if you don't have a build integration at least once a day. According to these agilists, being agile is not about being adaptable and doing whatever it takes to make your project a long-lasting success. These days, agilists simply claim that agile is about following practices X, Y and Z. Extreme Programmers often joke that Scrum is just XP without the technical practices that make it work.

And my feelings of inspiration changed into guilt...

We have fully adopted Scrum in our organization, but our adoption of XP practices is still far from completed. Are we now inferior to others? The agilists keep saying that Scrum without XP practices will result in a build-up of technical debt, lower productivity and failed projects. Every time I was reading this, I felt there was something not right about the picture that was being painted. I felt I had to respond, but I didn't know how.

Until today...

Today all our project managers agreed that the introduction of Scrum has increased the success of our projects. I've heard our software developers confirm that (because of Scrum) they now finally have at least a chance to keep technical debt away. A chance they didn't have before. Our customers tell us that our projects are now of higher quality. And last week our CEO complimented everyone in the organization on the measurable progress we've made. (Actually, I'm still doubtful about those hard figures, but who am I to complain when the gold medals are handed out?)

And all that without XP. How?

Why is it that every agilist and their uncle are warning people not to adopt Scrum without XP practices, while our organization seems to be quite successful doing exactly that? Well, to understand what's going on we need to do what the average agilist hasn't done in many years... which is to THINK, and go back to the roots of agility.

I am referring to complexity theory...

The Edge of Chaos

Agile software development has some of its roots in complex adaptive systems theory (also called complexity science). One property of complex systems is that they find themselves at the edge of chaos. That name is so badly chosen, one might think that Microsoft had something to do with it. You see, the edge of chaos is also the edge of order. It is actually the narrow edge between order and chaos. These days, scientists prefer to use the name complexity for that specific part of the spectrum.

In biology, psychology, economics, and other scientific disciplines, complex systems are the most creative, most adaptable and therefore most successful systems of all. In software development it is no different. Agility is about moving software projects to the area of complexity, right between order and chaos. And bla bla bla, there's nothing new about that. Jim Highsmith and Ken Schwaber already wrote about that years ago. So far, so good.

Now, software companies that are used to producing software in an orderly, structured fashion, will find that agile methods push them from the left side of the graph to the right, in the direction of chaos, but (if all is done well) not into chaos. This is probably what most agilists mean when they say that "Scrum is not enough". If you don't adopt a properly balanced set of practices, including technical ones, trying to be agile can harm your organization by moving it to far, from the ordered to the chaotic regime. Some parts of the system (like quality) might go out of control.

But...

Many organizations don't find themselves in the ordered regime. Most organizations that I know find themselves in the chaotic part of the spectrum. (Don't ask me why, either I am attracted to chaos, or it finds me wherever I am.) In these cases, agile methods will push them, at the very least, from the right side of the graph to the left, in the direction of order. Again, this shift must come to a halt when the projects have become complex instead of chaotic. Going too far into the ordered regime is equal to adding needless rigid structures and practices to a system that needs to stay adaptable. A requirement of having to follow practices X, Y and Z, without consideration to environmental context, would be an example of adding such needless bureaucracy. Less elegantly, context is king, and I don't give a rat's ass about Ron's lovely blue convertible. I already have a nice and shiny black monster.

So you see, for chaotic organizations, adoption of Scrum will be good, even without the XP practices. And that's what happened in our organization. We came from the chaotic part of the spectrum, and Scrum helped us to become complex. Sure, Scrum is not enough, but it's much better than nothing at all!

But, wait! I hear you say... in the end the absolute perfect process for a software project would be a combination of Scrum and XP practices, right?

Well... no!

Enter game theory...

Evolutionary Stable Strategies

An evolutionary stable strategy (ESS) is any combination of practices that enables a system to be successful and survive, in some environment. The ESS is a concept defined in game theory, but it applies just as well to economics, biology, psychology, and software development. Evolutionary stable strategies depend on their environment, and on any other ESS-es in that same environment.

With the possible exception of adaptability, there is no other single property that every ESS needs to have in order to survive. Yes, organisms benefit from having eyes and feet, but plants and bacteria seem to be thriving well enough without them. Many companies benefit from marketing and advertising, but some simply don't bother with that kind of stuff. Many software development projects benefit from Automated Tests, On-site Customers and Pair Programming. But there are plenty of others out there who are doing well enough without them, thank-you-very-much.

(Twenty years ago, long before XP, I wrote a bookkeeping program of 100,000 lines of code. I still use it almost every day. And in all these years I have found only two bugs in it. Required XP practices, My Foot!)

Game theory teaches us that there cannot be one best strategy for all participants in an environment. There is no such thing as one specific string of genes that every organism on earth must have. Because, if there was, it would be a weakness that could be exploited by other ESS-es (viruses and parasites, for example). There is also not one business model that beats all others in a capitalist economic system. If there was, everyone would be using it, which would make everyone's behavior predictable, which would be a weakness... Likewise, there is no such thing as one specific sequence of practices that every software project on earth must have to be successful.

If there was one best set of agile practices, it would be a weakness of the system!

In environments full of complex adaptive systems, the weakness of one system will be exploited by the other. That is how these systems co-exist, and co-evolve. When you know exactly how other systems (competing businesses, competing projects) are working internally, they will be predictable, and exploitable, and you can find ways of using that information for your benefit. This is why there will never be one best way of doing software projects. The idea of "required agile practices" borders on the naivety (or arrogance) of thinking that the human genome is the only best possible DNA string in the world. (See: why ants rule the world.)

Agile vs. Agilists

Agility is about staying successful in ever-changing environments. That's it. There's nothing more to it.

This includes defying any expert who claims that practice X is essential for your organization. Because, quite likely, practice X happens to be something this expert is very good at, and is willing to assist you with, for a considerable consultancy fee. (Remember, I was talking about viruses and parasites...)

Some agilists are saying that perhaps we should start by giving up on the "Agile" brand name. It's never been clearly defined, which has allowed a lot of dysfunctional projects to call themselves "Agile." But what these agilists mean, is that it has never been clearly defined which practices are the core of agile. And rightfully so, because there are none! If there were, it would mean prescribing one evolutionary stable strategy for all systems. Which would defeat the very purpose of being agile. Agile has never been some specific set of practices. Nowhere on the Agile Manifesto does it say that you have to do automated testing, pair programming, refactoring, or whatever. In fact, an "agile practice" should be considered a contradiction in terms as soon as people consider it to be mandatory!

It would be reasonable for us to expect from agilists that they understand the basics of complexity theory and game theory. That stuff has been at the very roots of agile software development. If they knew that stuff, they wouldn't be telling us silly things like "do practice X or you won't be agile" and "doing just Scrum will only make things worse". Unfortunately, that is not how things are these days. The glory days of agile visionaries seem to be gone. The agilists squabble over xp vs. scrum, lean vs. scrum, kanban vs. scrum, fdd vs. scrum, and who-knows-what-else-and-my-mother-in-law vs. scrum. Scrum is the norm. So if you find some faults with Scrum, people will probably think you're very smart. Or something.

Oh well, the agilists are not what they used to be.

We are faced with a global armada of agilists who know absolutely nothing of complexity theory and game theory. Yes, they know words like emergence and self-organization, because everybody's using them. But do they know where those words came from? And do any of them know what a phase transition is? Or a fitness landscape? Or an adaptive walk? Or an attractor?

I do. (And I bet most of them don't.)

Some of them are even thinking of dropping the agile name. Well, I couldn't care less, because it doesn't matter if you call it rapid, adaptive, agile, lean, or gobbledegook software development.

The agilists will fade away. But complexity is here to stay...

OK, now it's time to sit back, relax, and enjoy the comments section of this post. Actually no, I will not relax. There's still plenty of stuff to do. Like, for example, figuring out how to introduce those bloody XP practices in our organization. Because I believe that some of them could actually be quite useful for us as well.

(picture by jurvetson)

Follow me on Twitter - Subscribe with a reader - Subscribe by email!

Latest, greatest and favoritest posts:
Simple vs. Complicated vs. Complex vs. Chaotic
Eat Chaos, Poop Order
A Theory of Everything for Software Development

Copy-Paste Reasoning (or Adapt, Skip Adopt)

I have a bit of trouble with people adopting other people's opinions and arguments without adapting them where needed. Some people don't analyze a situation before applying their copied ideas. And worse than that: some people tell others that they are wrong, without bothering to investigate if their copied arguments actually hold within an unknown context.

I call it copy-paste reasoning.

Examples?

"You shouldn't do fixed price, fixed scope contracts, because..."
Fine, but that doesn't help me if that's the only thing my biggest customer wants.

"Big up-front requirements are wrong, because..."
I know, but my customer just handed me a 200 page requirements study and he pays me to implement it.

"Teams must be cross-functional, with all roles represented in the team, because..."
Sure, but the customer contracted another party for front-end design, on the other side of the country.

"You have to do iterations of four weeks each, because..."
Right, but that doesn't help me much if my project only lasts for three weeks, does it?

"You're wrong when your people carry out evaluations with on-line forms, because..."
Wow, are you psychic? Are you able to understand our people from the other side of the ocean?

I appreciate any kind of advice from any source, including advice that doesn't translate well to our context. It is an opportunity to learn and to understand how our situation compares to, and differs from, the world outside.

Context Matters, Always
Despite popular scientific terminology, there is no such thing as a "bad gene" or a "good gene". The effects of genes on an organism is context-dependent. It depends on the other genes and on the environment. Even the most malicious genes can turn out to be beneficial to some organisms in some environments.

Likewise, software development practices are always context-dependent. You cannot tell someone else what to do, without understanding their context. Even if you're 95% right, people will only be digging their heels deeper when you don't acknowledge that their situation is slightly different.

Adapt, Skip Adopt
I am in favor of doing things the agile way. However, sometimes the adopt-adapt sequence doesn't work. Sometimes you have to go straight for adaptation, because adoption of the practice straight from the book is impossible.

Sometimes people tell others that they are wrong when they skip adoption and go straight for adaptation. But they are wrong! They are using Copy-Paste reasoning.

That's why I suggest that you use only Copy-Paste Special...
and then carefully select your options!

Follow Your Mind, Not Your Rules

This article was a guest post on Raven's Brain. I am publishing a copy here for completeness.

Last week I drove all the way from The Netherlands to Slovenia --which is a 1200km trip-- to pick up my boyfriend, who went there earlier (by plane) for a conference. The idea was to spend a long weekend enjoying whatever this little country had to offer.

Spontaneous and Unconventional
In an earlier post I explained why I didn't travel to Slovenia by airplane, which would have been faster and only slightly more expensive. It's because I like driving, and I was looking forward to a nice relaxed 12 hour trip --all by myself with a stack of my favorite CDs-- that would take me through Germany and Austria. It was a spontaneous idea. I was eager to find out if my unconventional trip would give me some compelling new views and surprise encounters. And it did. But not in the way I had hoped.

Bad Idea?
On my trip through Europe I encountered so many road works it led me to believe Europe's Post-war Reconstruction was still far from being finished. A couple of big traffic jams made my ETA climb faster than Jerry Yang's chance of being kicked out of Yahoo. And maybe worse: I didn't get to see much of the foreign countryside either. The Germans have shielded off many of their highways with a number of trees that should easily compensate the CO2 emissions from their entire car industry. And the only things I remember of driving through Austria were the inside walls of numerous tunnels, the backsides of numerous trucks, and my rapidly dwindling amount of cash. (The Austrians make you pay through the nose for using their infrastructure.)

Maybe Not!
Did I regret going to Slovenia by car? Well, maybe for a short while. But after picking up my boyfriend in the town of Bled, it turned out they had already shown him around, and he had seen just about everything there was to see of this little country (which is caves, horses, mountains, and some more caves.) So we quickly decided to head for Croatia, where we had a nice evening and a delicious sea food platter in Rovinj, down by the sea. And the next day we drove to Italy, just a few hours away on the other side of the Adriatic Sea, where we spent two days eating pasta and watching gondolas in Venice. I'm sure we would have organized our time differently if I had simply gone to Slovenia by plane.

Spontaneous ideas trigger themselves!

Solving problems the unconventional way opens up room for even more alternative ideas. It's as if spontaneous ideas, once started, are self-generating. Let me give you some examples:

• On AgileSoftwareDevelopment.com I wrote about having automated our project evaluation process. It's a very unconventional idea, but it works for us. And it has opened up other new possibilities for data-mining historical projects.
• Our offices are housed in a famous old coffee factory. The building --being a monument-- allows for only few modifications. Therefore our unconventional floor plan flies in the face of common best practices for office space management. But never mind, because people love it! We never expected it, but our office is now one of the main incentives for people to apply for a job. And the renovated building itself got a European award yesterday.
• For important announcements in our company, I had the idea of introducing the Bell of Success. The bell (a heavy old ship's bell with a cord) is situated in the middle of our big office space and it is rung (loudly) once every few weeks, when we've landed an important new contract, or delivered a great new web site. Everybody immediately comes together for a 5-minute celebration around the coffee machine. Sure, we could have posted these successes on our intranet. But this is more fun!

New Risks
Naturally, unconventional ideas can lead to unconventional risks and problems. I am still surprised I survived traffic on the highways in Italy. The Italians drive like mad men. And it's a wonder we could find our way out of the country, as the road network seems to have been modeled after Italy's most famous kind of pasta. And I've learned that, when you're heading for Switzerland, you must realize that "Genova" is not the Italian name for "Geneva". And once we finally found Switzerland, the Swiss welcomed me with a gigantic traffic jam and food poisoning. This I found particularly uncalled for, since the Swiss are among the few people left in the world I haven't offended yet in any of my previous posts. But I might come to that later...

Defined Process vs. Empirical Process
Ken Schwaber, in Agile Project Management with Scrum, tells us that agile projects should follow empirical processes, not defined processes. I would translate it to this: Be prepared to ignore the textbook rules, and open up your mind to reinvent your processes along the way. Do what it takes to reach your goal by being smart and spontaneous. Don't just stick to conventional ways, even when they seem to work adequately. Rules and conventions are useful and important, but it's nice to escape from them once in a while. And even if your alternative solution doesn't work, it may have opened up some unexpected new opportunities...

Follow your mind, not your rules!

I carried out my last spontaneous act when were having a wonderful dinner in Venice. I had never planned to do this. It just crossed my mind earlier that day because the location, the weather, the surroundings and the food were simply perfect. I had the idea, thought about it for two hours, and just couldn't think of a better time nor place.

I asked my boyfriend to marry me.

Spontaneous ideas, once started, are self-generating. I'm sure there wouldn't have been a dinner in Venice if I had taken the plane to Slovenia.

Interesting? Not? Tell me about it! Or check out some of my other favorite articles:

Why Managing Small Projects is Harder

Specialization is Good

Why I Would Never Hire Steve Yegge

Scope, Resources and Processes: Change Everything!

As an agile writer, I like to write articles in multiple iterations. Feedback from readers is essential to me. There's no such thing as gettings things right the first time around. Not for programmers, and not for writers. So I've decided to give the readers of this site a chance to be the first to read my latest article.

The article is called Project Change, a Way of Life (PDF, 2.27MB) In this article I try to link complexity science with agile software development. I attempt to show why there is no such thing as a best software development method, why managing scope is a too simplistic interpretation of “embracing change”, why corporate standards for processes are a bad thing, and why you will never get things exactly right.

The article includes comparisons to biology and other types of complex systems, several little nuggets of wisdom, and some personal experiences involving my car. Here's a little sample of what you can expect...

For biological systems the search across the fitness landscape is not an intelligent one. DNA is mutated in random ways, and species do their adaptive walks in all directions, including every wrong one. But natural selection comes to the rescue by making sure that the individual organisms that happen to have landed (blindly) on a higher position on the fitness landscape are the ones most successful in reproducing themselves. Human-made systems apply a different strategy. We cannot afford to simply try out every combination of features, resources and processes. In our case not natural selection but conscious selection comes to the rescue. Humans have the intellectual capacity to make an educated guess on where the higher peaks are, even though the fitness landscape is an abstract thing. We balance features against qualities, we fire and hire employees, we discard and select tools, and we add and rework the processes in our software projects, hoping (and often expecting) to walk in the right direction, improving the fitness of our systems along the way.

Go ahead! Download the complete article, and tell me what you think!