He describes moving to agile development from the perspective of complex adaptive systems and game theory. Agility is about moving software projects from either an ordered context or a chaotic context into a complex context. Depending on where an organization comes from, different approaches work, e.g. Scrum with or without the XP practices. 

This fits with my experiences. I see more and more agilists focusing on agile according to The Book or saying it’s not agile if you don’t do the sacred practices. It is also fits with the stuff Willem and I have been writing and presenting about Jerry Weinberg’s Cultural Patterns and Dave Snowden’s Cynefin sensemaking framework applied to software projects.

Cynefin sensemaking framework

Cynefin describes four domains, as shown in the picture below (the green arrows represent the agile choreographies Jurgen describes): the simple and complicated domains are ordered, you can see cause and effect relations there, either simple or complicated but still knowable. This means you can devise methods and processes that will lead to desired outcomes in a bounded, predictable way. 

In the chaotic domain, no cause effect relationships are perceivable. The main decision model is to act quickly, trying to reduce turbulence, sense immediately what the effects of your action are, and respond accordingly. You can try to impose order on the system or reduce turbulence a bit to move towards the complex domain.

In the complex domain, the relationship between cause and effect can only be seen in retrospect. Looking back, causes and effects seem clear and we can explain what has happened and why - retrospective coherence. If you wouldn’t know better, it looks just like you’re in an ordered domain. But only in retrospect! You can’t reliably predict what will happen and you can’t reliably determine up front which actions will lead to desired results.

Retrospective coherence trap

I see a lot of agilists stepping into the retrospective coherence trap. They assume, consciously or unconsciously, an ordered context, where following a process like Scrum, XP, Scrum+XP, … will lead predictably to desired results (i.e. working software & a happy customer or product owner).

Most software projects that make a difference exist however in a complex context, because of a complex organizational context, ever changing customer requirements, complex problem domain, and/or unknown and rapidly evolving technology (I’ve written about this before in the context of Weinberg’s cultural patterns). 

If you’re not aware that your project is in the complex domain, you might be tempted to reuse the processes of a successful project for a next project, assuming it will be similar. It might work by accident, but more often than not the context changes, not radically but enough for the process not to work as expected. This can explain why many Scrum and agile transitions still fail.

The retrospective coherence trap is also a risk when doing retrospectives if you focus mainly on what worked well without realizing things only make perfect sense when you’re looking back. In the complex domain, success stories are only retrospectively coherent and not a recipe for success.

Summarizing

• Software projects that make a difference usually are in the complex domain.
• Managing in the complex domain requires an approach that is fundamentally different from managing in an ordered domain. In the latter, it makes sense to follow known methods leading to project success or steer a project based on your (mental) models of how the project works (e.g. doing agile by the book). In complex space, you need to do numerous small interventions, experiments, short iterations, do small probes, sense what happens, and respond accordingly - the agile principle of apply, inspect, adapt.
• We often assume that we’re in ordered context, even if we’re in a complex domain. 
• We step into the retrospective coherence trap: what happens makes sense only retrospectively, making it look like we’re in an ordered context. The context will however change in unknowable ways, so doing what worked yesterday will probably not give the expected results - although when you look back, it all makes perfect sense…

I do not really care whether you should do Scrum by the book, do all the 15.7 practices, get a high rating on an agile checklist, or even whether what I do is  officially ‘Agile’. I strive to find what works for myself, for my teams, and for the organizations I work with. It all depends (the main lesson I learned at university), or context is king as Jurgen states it, and anything goes (from Against Method, required reading for agilists, but that’s another blog entry) I feel a theme emerging for the next Agile Open Europe conference ;-)

A few recommended links

• Cognitive Edge website with more information about Cynefin and related work
• Systems thinking
• Jurgen Appelo’s blog about understanding development and management

Responsibility Driven Design with Mock Objects

Object oriented design is the art of assigning the right responsibilities to the right objects and arriving at a clean, loosely coupled, and highly cohesive design. Test Driven Development (TDD) will guide you in that direction, but not far enough. TDD helps to get loosely coupled objects, because coupling hinders the test-code-refactor rhythm.

Responsibility Driven Design is an approach that goes a step further. It shifts the focus from state to interactions and responsibilities. It helps to get a highly cohesive, loosely coupled object oriented design - an approach facilitated by test driven development with mock objects.

In this workshop, you will learn how to use the CRC card technique (Class-Responsibility-Collaborator) and mock objects to evolve a design in small steps, by looking at classes and their responsibilities, relations and interactions.

After a bit of presentation and a live programming demo, we’ll run a short coders dojo so you can experience it yourself. The dojo makes this session also interesting if you are already an RDD master.

Interested in this topic, but unable to participate? We offer courses on OO Design, Test Driven Development, Mock objects, and Refactoring in different forms, from short workshops to 2-day courses. Feel free to contact us.

• Finishing off a closed list with today’s work feels good. It helps me to get relevant stuff done in time.
• I liked setting my email and paper backlogs explicitly aside as official ‘backlogs’ and planning to process them (little and often). It took away the pressure I felt from the big stacks of papers on my desk and the long list of emails in my inbox.
• I often have emails and other stuff that I would like to do something with, but initially I don’t know exactly what. As a result, I postpone them, think frequently about them, and, after some time, force myself to do something. Then I often find that the actual action is quite easy to do - realizing I’ve wasted time and energy on worrying about it Focusing on doing stuff tomorrow helps me to find the smallest, simplest next action that could possibly work. The trick is to think of the first tiny step I could do to get started or make progress and make it a recurring tasks for the next day(s).
• I’m good at procrastinating on answering ‘difficult’ emails. I have found out that it becomes much easier if I split the work into first writing a rough draft version (where anything is good enough for a draft) and finishing it the next day. I feel much less resistance to taking a minute to ‘just jot down my ideas’ than to writing the ‘difficult’ email. The weird thing is that the ‘rough draft’ usually turns out to be a nearly finished email… 
• Sometimes, I prefer to go with the tasks I feel energy for. Last week for instance, I planned to spend two or three pomodori on end-of-year bookkeeping tasks, regarding it as a recurring task. After I started however, I continued doing it - I felt motivated to finish most of the (boring) work. This helped me to get a feeling of accomplishment and leaves me more time for enjoyable stuff in the rest of the month.
• I also prefer to have time for unplanned things each day, things that come up and/or things I feel energy for. A Will Do list can help to get both the important things done and leave time for unplanned stuff. 
• I’m not sure doing tasks tomorrow works for all my stuff: some tasks that I don’t do rightaway (i.e. today or tomorrow), end up being invalidated or changed after some time by new information. If I would have done the task right away, it would have been suboptimal, like buying at a price that’s too high or bugging people about issues that would otherwise get resolved automatically. Real options thinking would be useful here.  
• I’m keeping the Will-Do lists for planning and doing tasks at home. There it helps me to get all kinds of not-yet-urgent tasks done that I would normally postpone forever. By making a small, feasible list every day, I get things done, without stress.
• For my business, I’m also looking at the new Autofocus system Mark Forster is currently beta testing; I like the name and it looks interesting. Furthermore, I’m working on my “project management” system, to keep track of all my different projects and to make sure that imporant stuff happens. 

So there’s no easy solution for time management. Do It Tomorrow contains a lot of useful ideas, but in the end you’ll have to keep on reflecting what works and what doesn’t work for you, and grow your own system.

1. have a clear vision
2. one thing at a time
3. little and often
4. define your limits
5. closed lists
6. reducing random factors
7. commitment vs interest

Have a clear vision

Have a clear vision of your goals, of the things you want to do and the things you don’t want to do. A clear vision directs your priorities. Setting priorities is only meaningful between projects, not between tasks that have to be done anyway (’project’ is loosely defined here as an activity that leads to some desired result and that cannot be finished in one go).

Your vision is not something static: it will change over time. So frequently revisit your vision, to keep your priorities clear as well.

One thing at a time

Focus, focus, focus! Use for example timeboxing or working with a pair (like pairprogramming) to work in highly focused way. Don’t dilute your focus by having too many projects at the same time.

Little and often

Work on things frequently, in small bits, iteratively and increment, so that results grow over time. If you want e.g. to write a book or finish a Ph.D. thesis, work every day on it. Actually doing something and keep doing it is more important than the amount of time spent.

This works for writing, uncluttering your home or office, bookkeeping, and many other larger activities.

Define your limits

Creative thinking works better within clear boundaries. An example of limits is timeboxing your activities, e.g. using the pomodori technique.

Defining limits is also important for your projects: determine the boundaries (and frequently re-determine them) to get a clear focus of what you’re doing and what you aren’t doing, instead of being busy with a cloud of all kinds of vaguely interesting and possibly relevant stuff.

This week, I’ve started to make a map of all the projects that I currently have and that I want to take on this year. Being an independent consultant, I don’t have an organisational context that sets a lot of boundaries for me so I’ll have to set them myself in order to be effective.

Closed lists

A closed list is a list that has a line under it and that will not change. For every day, you make a Will Do list, a closed list with the stuff that came in the previous day and your recurring tasks. As the list is closed, it will only shrink when you’re finishing items from the list. This will give you a feeling of accomplishment at the end of each day, when all the Will Do items have been checked. 

Anything that comes in during the day and that is not a real urgency, will be put on tomorrow’s list or below the line of today’s list. You’ll first finish all the items above the line, before doing the newly added things.

This approach enables you to plan most of the work you do, so you can work much less reactively and much less governed by self-inflicted urgencies. Your day to day planning will become more predictable and you’ll get early feedback when you’re structurally overloaded.

The Will Do list is limited by your daily processing capacity (so you will need to find out what it is), so you prevent backlogs from building up. If you get more work each day than you can handle the next day, you’ll have to either cut down on your commitments, make your systems more efficient, and/or allocate more time for the stuff on your lists.

Willem asked, what do you do when the telephone rings? It depends: you can answer the call, make a note, and take action tomorrow (unless, of course, it’s about your house being on fire). You can also decide that you won’t answer the phone during certain activities, listen voicemail later on, and get back to the callers the next day. It depends on the nature of your work and your preferences.

Another advantage of closed lists is that you don’t have to prioritise between the items. They all need to be done and if the list is limited by your daily processing capacity, it will be finished. Prioritizing doesn’t make sense for stuff that needs to be done anyway.

Working this way gives peace of mind and reduces waste: you don’t have to spend your energy making difficult decisions about priorities. Prioritizing is waste: it’s work that adds no value, but just increases the pressure on you! You’ll have more time and energy left for actually doing useful stuff.

Forster’s recommendation is to start with the least urgent things first. If work has to be done anyway, why not do it right away?

A bright, grand idea like writing a book is not something you can finish the next day. This becomes a project, a task that recurs (a little attention every day) until the work is finished.

Reducing random factors

By preventing most ‘urgencies’, you will reduce a lot of (self-inflicted) variability in your day to day work. Closed lists system make the underlying systems problems visible. You can’t eliminate all variability and randomness, but you can reduce them substantially, giving you more freedom, making sure your important things get done, and enabling you to handle the remaining randomness better.

Commitment vs interest

You can be interested in a lot of things, but you can have only a limited amount of commitments. It is important to know your commitments, as these provide a framework for your decisions. It’s like the pigs and chickens metaphor used in Scrum (chickens are only involved, but pigs are committed). A pig only has limited ham and bacon it can provide… (the pigs and chickens metaphor has its limitations, but that’s another story)

I’ll give my interpretation of what Do It Tomorrow is about, based on what I’ve read and tried so far. Forster nicely summarizes it with the Mañana Principle:

The art of getting everything done by putting it off to tomorrow.

The motto is nothing is so urgent that it can’t be put off till tomorrow. It’s however not about letting things wait until they disappear by themselves! It is about actually doing the stuff that you need and want to do, earlier, with less stress and reduced cycle time (= the time between the arrival or conception of the task/email/thing and doing it).

You get rid of your backlogs (emails, tasks, papers, mail) and set up a system for yourself to keep backlogs away. Backlogs are ‘evil’: they are symptoms of problems in the underlying systems. With systems I mean the systems you use for managing your time and energy, for processing emails and other stuff, the way you manage all your other work and projects. Backlogs tend to hide problems. Stuff waits in your backlogs until it cannot be put off anymore, which makes it urgent without a good reason. In this way, you are driven by the urgencies of the minute, while other stuff in your backlog that does not make enough noise just starves.

Forster states that there are only a few real urgencies that really require an immediate response from you, like your house or office being on fire, your kid being ill at school, or your pc breaking down so that you can’t do your work. Most of our ‘urgencies’ are either misinterpreted as urgent or self-inflicted (caused by letting it wait until the last irresponsible moment). Most of the stuff that comes in can wait until tomorrow.

So the idea of Do It Tomorrow is to set up a system for yourself, in which you handle all of the stuff that comes in today, tomorrow. Of course, some days you get more stuff than you can handle on the next day, but that should even out over time. If not, you have a systems problem that cannot be solved in a sustainable way by just working a bit longer or putting in a bit more effort. The problem is caused by:

• working inefficiently
• having too many commitments
• having too little time for the work

According to Forster, these are the only three possible causes of time problems. Prioritizing and creating to do lists won’t help you in tackling these. 

I see a lot of parallels with lean: you establish flow of all the stuff you do, reduce variability in your work. It focuses on reducing muda (waste, inefficient way of working), mura (unevenness of work, caused by procrastination and waiting until nonurgent things become urgent), and muri (overburdening yourself with too many commitments).

In the next blog entry, I’ll give an overview of the 7 principles of Do It Tomorrow and say something about my experiences. I appreciate Willem for the evening conversations leading to these blog entries.

CITCON Europe, 3-4 October in Amsterdam; QWAN is sponsoring this event

The Agile Holland Conference, 24 October in Amsterdam; I’m one of the organizers.

The Scandinavian Agile Conference, 28 October in Helsinki (Finland); Willem and I will run our Rightsizing Your Unit Tests workshop.

XP Days Benelux, 20 & 21 November in Veldhoven (The Netherlands); Rob and I will do our Responsibility Driven Design with Mocking presentation.

See you there!

Perfect doesn’t exist. Perfect is something we aspire to, it’s elusive by design.

Striving for perfection is a trap for many organisations: the organisation becomes more and more adapted to its context, ultimately fitting perfectly (having found the best practices and the optimal way of working). This also removes all variety from the system however, making it less and less adaptable. This leaves the organisation very vulnerable to changes in its context - and its context will definitely change. This a problem in many Routine cultures.

Assuming a stable environment for IT projects is dangerous: projects are in continuous flux and lots of stuff changes.  IT projects (agile or not) are complex systems (at least the ones that aspire to make a difference). A project changes its context and is changed by its context.

If you look at it in this way, there’s actually no such thing as perfect. Maybe the organisation can be perfect for a moment, fitting its context, but then the world moves on, stuff changes, and the state of perfection is over.

Maybe we should not even talk about continuous improvement, because that presupposes you’re improving towards some goal. Managing a complex system is instead a continuous balancing act - dancing with the system, while learning more and more along the way.

Picture credits: Dancing © by pedrosimoes7

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.

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

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!