Dreamfeed

I’d like to invite you to join us at the Agile2008 conference, from 4-8 August in Toronto (Canada). The program has been published recently and contains a huge amount of great sessions… warning: choosing which sessions to go to will be extremely difficult this year! Keynote presentations will be delivered by James Surowiecki (author of The Wisdom of Crowds), Robert C. Martin, and Alan Cooper (author of The Inmates Are Running the Asylum).

The conference has adapted the metaphor of a musical festival: it is organized as a collection of stages - mini conferences around specific themes.

Together with Linda Rising, I’m responsible for the stage on agile and culture. Our stage program has three parallel tracks of tutorials, workshops, experience reports, talks, about topics like managing change and resistance, agile transition experiences, politics, ethics, story telling, jazz improvisation, and haiku-driven development.

We expect up to 1600 participants. Last year the conference sold out very quickly, so don’t wait too long to register.

Willem, Rob and I proudly present the first release of our courses and workshops brochure. We’ve bundled the descriptions of a number of existing and new courses and workshops, together with some practical information, to give you a clear overview of what we have to offer:

If you’d like to receive a paper copy of the brochure, please let me know and I’ll send you one.

Would you like to get more out of your projects? Are you juggling multiple projects at the same time? Are you an ‘accidental’ project manager, managing projects in addition to your ‘regular’ job? Are you working as a Scrum master, agile coach, or agile project manager and your projects refuse to go by the book? Are you involved in complex, cross-functional projects that you want to bring to a successful end? Or are you just interested in challenging ideas about project work?

You only get so far with tools, techniques, methodologies and frameworks, schedules and breakdown structures. The real leverage lies in the people involved. If you’d like to become more effective in getting the best from the people involved in your projects, participate in the experiential Mastering Projects workshop we’ll run on 14-16 May in Epe (in the beautiful center of The Netherlands).

Gert Heres and I are proud to announce that we will bring David Schmaltz and Amy Schwab from True North pgs Inc. over from the US to facilitate their 3 day Mastering Projects workshop. David is the author of the book The Blind Men and the Elephant: Mastering Project Work - How to Transform Fuzzy Responsibilities into Meaningful Results and he has served, among other things, as faculty for Jerry and Dani Weinberg’s Problem Solving Leadership Workshop.

We won’t waste your time with theories how project should work. You won’t get an official project management certification either. Instead, you will learn how to get the best from the people involved in your projects, not only from the ‘official’ project members but from the whole community around your project.

It’s a very intensive, practical, experiential workshop, where you will learn techniques and strategies that work, applying these to the project you bring in.

Mastering Projects is a 3 day residential course. Participation costs € 2075, this includes everything - course, materials, breakfast, lunches, dinner, 2 nights lodging, beautiful surroundings, and drinks at the bar

For more information see the workshop website or the brochure ^{[PDF, 178 Kb]}. Note that this is a very special, one time event with only 20 places available, so be quick to register!

I’ll be offering a new course eXperience Refactoring, together with Willem van den Ende and Rob Westgeest. We’ve been playing with the idea of designing a hands-on course for some time. With some pressure from clients, we finally decided to go for it

It is a two day course about the ins and out of refactoring software, in a responsible and cost effective way. The first public appearance will be on 4 and 5 March, 2008, near Eindhoven (The Netherlands).

In this quite unique course, you will learn how to improve the design of existing software step by step, while continuing to deliver value to your customers. It’s a very practical, hands-on course: we don’t think you will get very far by just hearing and reading about refactoring, so our approach is to let you learn by doing, practicing, and receiving feedback.

The course provides approaches and techniques to work more effectively with legacy software and to prevent new software from turning into a mess. We cover topics like code and design smells and breaking dependencies to get your tests in; we’ve also added a bit of systems thinking to help you see design debt and refactoring in an organizational context.

Check out the course page for a full description and information on how to join - don’t wait too long: we only have a limited amount of places.

Picture credits: Look what I have done! © by Elsie esq.

After quite a few hours of hard work, Willem and I have finished our whitepaper on the Promise is Debt pattern (PDF, in Dutch). We frequently encounter this pattern in IT organisations: it’s a common destructive pattern of behaviour, where people overpromise to compensate for underdelivery; they fail to live up to the expectations, and then overpromise some more again…

We apply systems thinking and diagrams of effects to get a grip on the underlying dynamics and we identify a number of leverage points to break the vicious cycle.

The whitepaper is currently only available in Dutch. We intend to create an English version as well.

Lots of IT projects are said to fail - many people are complaining, calling shame on the IT profession. An example is the recent article Okay to fail from the CIO Weblog, which talks about poorly run projects and underperformance.

Most IT projects are not in a predictable context, but in the complex domain - as I’ve argued before. In the complex domain, failures are a necessary part of the learning process, part of the way you make sense of what’s happening. IT projects are not in the domain of ‘best practices’, you don’t have complete (mental) models of how projects work, you can’t predict them.

A more sensible strategy is to probe, sense, respond (or apply, inspect, adapt in agile terms) - i.e. try something, look what happens, and base your actions on this information. What does trying something mean? Raymond Salzwedel describes it in 9 principles of safe-fail probes:

In the complex world (…), we rather need to create ways that allow unpredictable things to happen, and then to have a plan to deal with them, and learn from them. Moreover, we can even create situations that will test the stability (or lack thereof) of a complex system, and then observe the results. If it goes wrong, that is OK - it is allowed to. We can call these types of interventions or events, Safe-Fail.

So, failure is good, failure is a necessity. It’s a means to a higher end. Please stop complaining and whining about failing IT projects; stop calling IT such a bad boy; stop burning the guilty at the stakes - that doesn’t change a thing, it only creates fear and prevents any learning from happening. Leave out judgment and take what’s currently happening as information. Use failures as probes in the complex space of IT and learn from them.

Not only accept failures, also plan for failures as part of portfolio management: take into account that a part of your portfolio will not deliver what you want. That’s ok, it’s part of the organizational learning process.

Some tips on what to do when a project goes awry:

• Don’t panic! What’s happened, has happened; postpone judgment, regard the failure as information, run a retrospective to learn from it.
• Allow peope to fail in your organization. In particular, check your reward system - it probably rewards success and punishes failure. Your organization will learn most from its failures however (this is not an easy change…)
• Make sure the people involved get a soft landing and an opportunity to recover - failure is necessary for learning, but being part of a failing project can be ugly and stressful, provoking strong emotions.
• Work in an agile way to help you fail early and often. Working in an agile way helps address risks and uncertainties early on. You can detect wrong assumptions and other problems in a matter of weeks instead of months or years; this saves a lot of financial and emotional investment. Furthermore, it enables you to run a lot of small projects as experiments.
• Set up projects as safe-fail probes: small and incremental; make sure that if they fail, you can afford it and you will learn something.
• If you want to label a project as a failure, investigate why. When is something a failure? Donald Gause and Gerald Weinberg define a problem as a difference between what you perceive and what you desire. A failure then means that you tried to make the difference smaller, but it is still there (or it’s even bigger). Investigate the project from the viewpoint of your desires and perceptions, how these changed over time, and how the project has affected both.

References

• Donald C. Gause & Gerald M. Weinberg, Are Your Lights On?: How to Figure Out What the Problem Really Is
• Carmine Coyote, How to make more - and better - mistakes
• Norm Kerth, Project Retrospectives: A Handbook for Team Reviews
• Dave Snowden, Safe-fail or Fail-safe

Do you want to get more out of your failures? Would you like to learn how to use safe-fail probes to get more out of your IT? Feel free to contact us.