Collaboration, Self-Fulfillment, and Everything

Modeling The Real World vs. Designing Software

2011-11-16T10:28:00.000+01:00

I started writing a response to comments on a previous blog post, and it turned out long enough to become its own post. The question was on whether you should relationships in the "real world" to decide on relationships in your object-oriented designs.

"Is-a" and "part-of" are concepts from object oriented analysis, where you try to model "the real world" in terms of classes and objects. That is, by looking at the problem you are trying to solve, you could come to the conclusion that a customer "is-a" person, and that a street name is "part-of" an address.

In the early days of object orientation, it was assumed that you could simply transfer the relationships you found in that analysis directly into your design for good results.

There are (at least) three reasons why this doesn't generally work well, in my experience:

when we analyze the "real world", we typically model the problem space. When we design software, we model the solution space. Although there are often similarities between the two, there is no direct mapping - in fact, finding a good model for the solution is the most creative (and important) act in developing software. Assuming that an "is-a" relationship in the problem space will directly translate into inheritance in our solution space needlessly restricts our creativity, and thereby leads to inferior solutions.

for me, the primary goal of software design is to manage dependencies in the design, so that the resulting system is maintainable and extensible (because successful software is software that will need to be changed). As a consequence, there are forces working on our designs that don't exist in the "real world", and therefore considering just "real world" relationships won't help managing those forces. Just take the famous "a circle is an ellipse" example: while true in mathematics, depending on what you need a system to do, reflecting this relationship in your design can violate Liskov's Substitution Principle, and thereby lead to brittleness and unnecessary complexity. That is, a relationship that is absolutely natural in the problem space leads to problems when transferred as-is into the solution space. Another example: both a customer and an administrator are persons, but that commonality could be totally irrelevant to the solution of your problem, and then modeling it in your design would be a waste, at best.

in the English language, there is no unambiguous rule about when to use which phrase, anyway. Yes, you could say a customer "is-a" person. You could as well say that personal information is "part-of" a customer. Or that a person "has-a" role of being a customer. It can even make sense to say that "a person is a customer". So you really can't use natural language semantics to decide which relationship to use in your code.

So, using those relationship names doesn't really take the burden off your shoulder to choose wisely which relationship makes the most sense in your specific case. And an experienced designer will - whether explicitly or by gut feel - choose the relationship that leads to the most SOLID design. and he knows how to refactor to a different relationship when his understanding of the forces in the code changes.

An Agenda for Backlog Grooming

2011-08-01T10:31:00.002+02:00

When training and coaching teams to use Scrum, I'm starting to put more emphasis on Backlog Grooming - having the whole team maintain the Product Backlog during the Sprint, so that it remains in good shape, the team keeps a grip on the vision for the project, and there are no unpleasant surprises when it comes to Sprint Planning.

Inspired by "Collaboration Explained" and Roman Pichler's blog post, I created a general purpose agenda for backlog grooming, that so far has worked quite well:

Opening - help people arrive physically and mentally, review the agenda, do a quick round robin check in, review actions from last grooming.
New Learnings - what have we learned that we want to capture in the Product Backlog? Ideas for new stories, obsolete stories, significant changes to content, estimates or priorities?
Prepare for Next Sprint - identify the stories that should go into the next Sprint Planning and make sure they will be prepared according to the Definition of Ready.
Identify Stakeholders and Dependencies for Next Sprint - focus on the question: looking at the stories selected for the next Sprint Planning, who needs to be invited to that planning meeting?
Risks for Upcoming Sprints - looking further ahead, what are the upcoming risks? Which of them should be addressed now, and how - for example by splitting stories, by scheduling investigations, spikes etc.?
Closing - any open ends that need to be addressed? Review Action Plan. Mini-Retrospective, e.g. Plus/Delta.

What are your thoughts on this agenda? What do you do in Backlog Grooming? How would you change this agenda for your team(s)?

The Shu Ha Ri of Inheritance versus Composition

2010-08-23T13:22:00.001+02:00

For ages now, there is an ongoing discussion (to not say war) in the OO communities on wether it makes sense to prefer Composition over Inheritance or not.

My personal impression is that a lot of the heated debate stems from confusing advice given to beginners with what the experts do. A useful mental tool I like to use in occasions like this is the concept of Shu Ha Ri. Here is how I currently think about it:

Shu

You are (relatively) new to object oriented design. Inheritance is rather easy to understand, polymorphism a little bit more abstract. Inheritance is easy to do, composition a lot more work, or so it seems. It's likely that you are overusing inheritance, and that you could benefit from making more use of composition. That's fine, it's the usual learning step you have to take. Once you experienced how inheritance works (and where the problems lie), it's good advice to favor composition over inheritance, so that you can learn what the pros and cons of that approach are.

Ha

You have experienced the perils of overusing inheritance. You have experienced the flexibility that composition brings you - and where investing into composition actually doesn't seem to pay back much. It's time to start experimenting with a balance of inheritance and composition, and to find your own rules of when to use which.

Ri

Thinking in terms of inheritance versus composition doesn't make much sense to you. You know that both are just tools in your quest of producing maintainable, SOLID code. And you can easily refactor code from using inheritance to composition and back on a whim, so why make a fuss about it? Just use whatever your gut tells you makes sense at the moment.

The Aha-Experience Exercise

2010-03-03T22:03:00.003+01:00

The Aha-Experience exercise is a simple exercise that I learned about November last year during Alistair Cockburn's CSM + Crystal course (which I highly recommend). I have since used in a four day Scrum workshop for college students, together with Heiko Stapf. I really like it, and, with the permission of Alistair, I'm hereby sharing it with you.

This exercise is especially useful for trainings that span several days. It

allows participants to reflect on their personal learning highlights,
lets them share their insights,
provides regular feedback to the trainer about what parts of the material gets the trainees attention and how they interprete it, and
organically and collaboratively lets an artifact emerge that will remind participants of their main lessons from the training.

How it works:

This is my take on how to execute this exercise. While I think that it's close in spirit to what Alistair does, there are probably also many details mentioned below that are more rooted in my personal experiences and values than in observing Alistair facilitate this exercise.

First round of gathering aha-experiences (15 min.)

Start with the exercise early in the training. A good point in time is when you covered enough material for the participants to have aha-experiences to report, but early enough that it still feels like the start of the training. Typically that will be after the first one or two lessons/exercises, not more than two hours into the training.

Hand out a block of sticky notes (extra-sticky, if possible) and a marker to every attendee. Ask them to take a few minutes to think about and write down two aha-experiences, each on its own sticky note. An aha-experience could be something that surprised them, something that got their attention, or simply something they want to make sure to remember. (It's often not too hard to come up with one aha-experience, but having to come up with a second might require some deeper digging. See it as a challenge that your trainees might need some gentle support for, in contrast to a requirement that needs to be enforced.)

When they finished writing, go around the room and ask every participant to quickly read his/her aha-experiences aloud. Thank everyone for the contribution. Don't allow discussions at this point - the goal is to just get a sense of what the group has learned until now. Don't critizise a "wrong" aha-experience, as you don't want your trainees to censor themselfes out of fear of being publicly critized. Take it as valuable feedback that you can use to adjust coming parts of the training.

After the last participant presented his/her aha-experiences, ask them to stick their notes to a wall that you reserved for this purpose. It should provide lots of space for adding more notes later during the training, and should be easily visible for the attendees throughout the training (that is, a wall in their back isn't a good choice). A front of windows works well, too.

Finally, tell participants to keep looking for aha-experiences for the rest of the training. Whenever they have one, they should immediately write it down on a note and stick it to the wall.

Keep it flowing

If you are lucky, your trainees will happily accept the invitation and continue posting aha-experiences to the wall. Just make sure that sticky notes and markers are always easily accessible. Make it your morning ritual to check all tables and replenish supplies where necessary.

Depending on the group and the room layout, you might need to gently remember the group to continue posting aha-experiences and to look at what others have written. You might even want to schedule short slices of time just for reflecting on the training and writing sticky notes. Five minutes just before lunch break have worked well for a group that otherwise wouldn't write down any aha-experiences.

Debriefing (20 min.)

As part of the debriefing for your training, give participants one last explicit chance to stick more aha-experiences to the wall.

Then let the group gather in front of the wall (you might need to make some room), and group duplicates. Everyone should look at the posted notes put together those that seem to say the same thing. If the text actually is different, it helps if they are both still readable. Encourage discussions; if the author of a note argues that it is different from another note, that should be respected and the notes not be considered duplicates.

When things settle down, hand out sticky dots. Ask participants to put a dot on every aha-experience that's important to them personally. Every participant can use as many dots as s/he wants, one dot per aha-experience.

When dots have been alloted, read aloud one to two handful of top-voted aha-experiences. Depending on the number of sticky notes and the obviousness of the distribution of dots, you might want to sort the notes by number of dots, first.

Let the group discuss observations: are there any surprises? Is there something missing? Have there been important learnings that didn't manifest in aha-experiences?

Finally, take one or more photos of the notes on the wall (the notes should be easy to read on the photos) and provide them to the participants as part of the training documentation.

Conclusion

I like the way this exercise continuously involves the participants in the training and puts a focus on their individual and collective learning. I will definitely use it again in the future for trainings that span more than a day. I wonder how well it would work for shorter trainings, or how it might need to be adjusted.

If you try this exercise or variations of it, please let me know what you learn!

Come to Agile Coach Camp Germany!

2010-02-16T18:04:00.001+01:00

I'm so excited about Agile Coach Camp happening in Germany at the beginning of May this year! Being part of such a passionate organizing team is amazing. And I think the motto "Wavemaking - gently creating radical change" is just brilliant. Talk about the creativity of teams!

Due to the size of the venue, we are limited to just 50 places, and the list is filling up quickly. So, go and register! Or get more information first, if you aren't convinced, yet.

Focus on Whose Value?

2009-12-08T18:18:00.000+01:00

Recently there seems to be a lot of talk about focusing on business value in the Agile/Lean blogo-/twittersphere. And while I think that there is value in talking about business value, it seems to me that many of those statements/discussions lack some critical aspects.

First, the often made assumption that businesses primarily exist to please their customers to make money is simply wrong, in my opinion. And actually, what happens in those businesses often disproves the assumption right away. I have seen business owners spending money on unreasonably sized fair booths, care more about the number and scope of projects worked on than their profitability, have the company grow and be stiffled by an oversized hierarchy without any apparent need etc. All these things were not done out of a focus on business value, but *to make the business owner happy*. Some of these business actually went out of the same, because what made the owner(s) happy wasn't financially sustainable in the long run.

Second, and not less importantly, there are also the employees involved. A common sentiment I see is expecting the employees (for example a software development team) to solely focus on what provides value to the customer, based on the fact that - after all - it's the customer's money they are working for. This seems to imply the main reason they are working is the money they get out of it. A quite sad perspective, isn't it?

I'd prefer for people to work on something that helps them live their passion, to find self-fulfillment. I'd prefer them by doing so in collaboration with their colleagues to be able to produce value that someone is willing to spend money on. Enough money to support the survival of the business.

Wouldn't that be a great world?

Tips for Being a Timekeeper

2009-12-04T15:19:00.000+01:00

This post is inspired by a short twitter discussion with M. le Rutte. It made me reflect on how much I tend to struggle with keeping time in a retrospective (or other meetings), and what I've learned on the way.

In my experience, keeping the time is important for two reasons: expectations and hard constraints. You don't want participants to get impatient because an activity (and, by extrapolation, the whole meeting) is taking longer and longer, so that it seems there is no end in sight. You also don't want a participant to suddenly have to leave in the midst of action because he/she has another appointment.

On the other hand, you also don't want to follow the clock slavishly. You don't want to stop the flow of a productive discussion just because some arbitrary amount of time has passed. You want to focus on the people and their interactions instead of your clock.

Finding a balance between those forces that I'm comfortable with took me some time. Here are a couple of tricks and techniques I use:

Keeping the time is a service to the attendees

This is more like a principle that informs all the other tricks and techniques: the reason to keep the time is to ensure that the participants can have the best meeting possible given the time constrains they live in. The goal is to make the best possible use of a constraint resource.

Clarify expectations and constraints

At the beginning of a meeting, it should be obligatory to restate the scheduled timeframe. Additionally, I like to ask the participants what constraints they have on extending the meeting. It's vitally important to know whether someone has to be in another meeting at the scheduled end of the current one, whether people are eager to get home for the weekend, or whether they are totally fine with taking an hour longer than originally anticipated. Also, sometimes some people are fine with not attending the meeting to the end. All of this information has a big impact on how time needs to be handled by me as the facilitator.

Timebox activities

Keeping a meeting inside its timebox is much easier if you timebox activities, too. Even open discussions can easily be timeboxed: "let's talk about this topic for ten minutes, and then see how we continue the meeting."

Use a simple timer

Use a simple timer for timeboxed activities. The timer should be easy to read for the facilitator and show the time remaining for the activity. I prefer silent timers (no alarm when the time is over, see below) with an easy user interface. There is nothing more annoying to me than having to fiddle with a complicated timer setting at the start of an activity.

Use curt timeboxes, enforce them gently

Don't stop the activity immediately when the timebox is over (unless it has come to a natural end, anyway). Wait for a good moment to intervene; keep the constraints of the group in mind. Using short timeboxes gives you some slack to work with.

Let the group decide

If you feel that the group might want to continue the activity, ask them whether they want an extension. Remind them of the consequences for the rest of the meeting. Sometimes the best the group can do is change the goal of the meeting to be able to spend more time on an important issue that surfaced.

Use a parking lot

Keep an area on a flipchart or whiteboard where you can post topics that attendees want to discuss, but which are off topic for the current phase of the meeting. As part of closing the meeting, decide for each topic what to do about it. (I got this tip from the book "Collaboration Explained", which I highly recommend.)

Incorporate breaks

A meeting that takes longer than an hour should include at least a five minute break (more and longer breaks for longer meetings, of course). Get everyone moving and open the windows to get fresh air in. A short break refocuses everyone and actually generally shortens meetings.

Plan for alternatives

When you plan activities, for example for a retrospective, it can be a good idea to think of alternatives to long activities, that you can use instead when time runs out. This allows me to react more flexibly and relaxed when something takes longer than planned.

Blowing the timebox isn't a failure

As long as the attendees agreed on spending more time in the meeting than planned, it's a good thing that you reacted flexibly to the needs of the group. Keeping the time doesn't mean rigorously enforcing the original plan, but keeping everyone aware of time issues, and deciding collaboratively and responsibly based on needs.

That's what's coming to my mind right now. What are your tips and tricks when it comes to keeping time?

Index Cards are Tools, too!

2009-11-25T11:28:00.002+01:00

Really, they are! As are white boards, pens, flip charts and all the other stuff we Agile "dogmatists" like to insist on using.

In fact, they are not just tools, but highly flexible, collaborative, simple-to-use tools. And that's not the only way they beat the "high-tech" software tools. Try to find a monitor that comes even close to the resolution of an index card. Or a company that can afford to decorate all their walls with white-board-sized computer displays.

So, please, pretty please, stop telling people that Agilists advice against the use of tools. Start telling the world that in fact we love tools, that we are in fact passionate about using the most effective tools for the job at hand. Which just more often than you might yet be aware of, means using an old fashioned low tech tool.

Scheduled Retrospectives are Good

2009-09-11T16:49:00.000+02:00

I frequently read people state that scheduled retrospectives are a smell. The argument seems to be that a well working team should talk about issues without needing a scheduled ritual to do so, or that management should be able to notice things that need to be talked about.
Well, for one thing, that sounds to me like saying that a car maintenance schedule is a smell, that it should suffice to just go to a garage when you notice a problem. Of course, a car maintenance visit has exactly the purpose of finding problems that you won't notice in your daily use of the car. The same is true for retrospectives: if you notice a problem, you shouldn't wait for the next retrospective to address it. The purpose of the retrospective is to find out about issues that for some reason you don't notice during your day-to-day work.
Additionally, it often seems to get missed that fixing problems isn't the only (and possibly not even the most important) purpose of a retrospective. It also provides the important opportunity to increase the mutual understanding on what has happened, to paint a more complete picture of the project (by assembling the individual pieces of all participants), to share learnings and generate new insights.
As an aside, holding "retrospectives" is a common practice in other professions, too. The military has "After Action Reviews" or "Lessons Learned", firefighters have "Post-Fire Critiques". These are typically held after a mission is over, to reach closure on it and learn for the next mission. I'd think that the end of an iteration/sprint makes for a good equivalent in software development.
In conclusion, perhaps there are teams out there which "don't need" regularly scheduled retrospectives. I'd say it's wrong to think of those teams who choose to have them as necessarily less advanced, though.

When to Introduce an Interface (in Java code)

2009-07-23T15:08:00.000+02:00

This is an answer to a question asked at Java Ranch: "How often should classes be programmed to an interface?" As this question gets asked regularly, I thought I'd "archive" it here...
I basically introduce an interface for five different reasons:

I want to mock an object for a unit test
a client only needs to depend on a small subset of the operations of a class (and for some reason, I can't/won't break down the class into smaller ones) (Interface Segregation Principle)
to invert the dependency between two modules (Dependency Inversion Principle)
to use polymorphism with classes that aren't related by a common superclass
I need to publish an API to a third party

In all other cases, I find that with modern tools it's so easy to introduce an interface after the fact - once I feel the need for it -, that introducing it "just in case" creates more disadvantages than advantages.

Criteria for a Scrum Tool - or any Agile tool, that is

2009-07-13T13:15:00.000+02:00

In one of the many mailing list threads on tools for Scrum teams, I posted a list of evaluation criteria that I'm quite happy with. So I decided that it might be worth a blog entry. Anyway, here they are:
In my view, there is one universal evaluation criterion for any Agile tool:

does it provide what the team needs, in the simplest possible way?

To support self-organization, I'd probably add:

did the team itself choose the tool?

From personal experience in small, colocated teams, I'd add a whole number of additional criteria for that context (in no particular order):

is it highly flexible? Can it easily be adjusted as the needs of the team change over the course of a project?
is it intuitive to use? Can I use it without having to think about it? Does it feel natural?
is it highly visible? Can I see the current data without any effort, at a glance? Even by just passing by, or by looking up from my screen for a moment?
is it highly collaborative? Can several people stand together and discuss with each other, with everyone having the same chance to work on the tool, and see and influence what everyone else is doing; concurrently on arbitrary different parts of the data? Do people notice when I look at it? Does the tool help start necessary conversations?
does it provide easy navigation between high level and detail views? Is it possible to get a feel for the state of the Sprint at a glance? Is it easy to spot anomalities, and to dive into details?

The most appropriate tools I know for those requirements (again, remember that this is for a small, colocated team) still are cards on a wall and manually updated graphs on flip chart paper.

"Fix This Defect" Is Not A Feature

2009-07-10T16:35:00.000+02:00

How to deal with defects once they escaped into the wild is a much discussed topic in the Agile community. Some people like to add them to the product backlog, others prefer to maintain separate bug lists. Most seem to agree that fixing a bug should be scheduled by the Product Owner just like features are.
At first glance that makes a lot of sense. After all, just like a feature, a defect is basically not much more than some missing functionality that might have higher or lower priority and higher or lower costs to implement than some other missing functionality.
There is an important property of defects that make scheduling their fixes a bit more complicated, though: a defect in the software system also denotes a defect in our process - a hole that allowed the defect to slip through. And not fixing that process problem will allow more defects to slip out in the future.
I would think that the team should be held responsible for fixing the process to prevent defect slippage in the future. Of course, to fix that defect, you will need to analyze the software defect enough to know what caused it, so that you can prevent similar problems in the future. And analyzing it to that depth probably means that fixing it is then actually a trivial task.
So, what should you do? I don't have the final answer. I do think that applying "Stop The Line" to software defects might be worth an experiment. What do you think?

Should Software Development Be More Like Engineering?

2009-06-17T17:16:00.001+02:00

Again and again I hear people state that "software engineering" is too young to be mature, that in the future we should expect to work "just like in the other engineering disciplines": get a specification, apply your aggreed upon engineering formulas, and build the thing, correctly, the first time.
Are engineers actually doing that?
The documentaries I see about engineering projects always show the involvement of models, virtual reality, software- and real simulations to test assumptions and get feedback from customers. They need to do that because building (and potentially destroying) the real thing is too slow and/or costly.
Not so much with software.
Which bridge would you trust more: one that has been "mathematically proven" to withstand a storm, or one that actually has survived all kinds of storms over the last year, a hundred times a day (as shown by the acceptance tests, executed by the continuous integration server)?
I have a hunch all those engineering skills, while certainly valuable, in the end are "just" a crutch, necessary because real life testing is just not realistic for them.
It is with software.

You Might Need To Leave Your Comfort Zone...

2009-06-15T17:00:00.001+02:00

Some time ago, I facilitated an interesting workshop for my team, regarding communication when there is conflict. I presented a very simple model, where the communication was put on a scale from artificial harmony, over constructive conflict, to open war. (If I remember correctly, I got this model from the book "The Five Dysfunctions of a Team".)
An interesting discussion ensued, including on whether the scale really represented a true dimension of communication, what other dimensions there are etc.
The most interesting insight to me, though, unfolded towards the end, when it became clear that most of us were working under a common assumption: That people who feel comfortable with the more open, "hostile" communication styles must do so because of greater self-confidence. The implication being that it should be their responsibility to consider the needs of those with less self-confidence, by calming down their communication style.
When this assumption finally cropped up, one of our team-mates, often berated for her communication style at that time, commented that the assumption actually didn't hold true. She didn't feel more self-confident - in fact, she felt threatened by less open, more cautious communication styles. She felt threatened by not being able to truely understand her relationship to teammates, by conflicts potentially simmering under the surface instead of being carried out in the open.
The whole team was quite puzzled once I started drawing the implication on the white board - if two people are in conflict, they really might have comfort zones that don't overlap on the above mentioned scale. No matter what they do, at least one of them will feel uncomfortable.
What do you do in such a situation? My, somewhat lame, response was that you just accept that fact and learn to live with it. If you want to have that conflict resolved, you might need to leave your comfort zone. I guess that a coach or facilitator also can do things to help someone leave his comfort zone, or to widen comfort zones.
What would you do?

The Balance of Care

2009-06-05T16:38:00.000+02:00

In "The Circle of Care", Karen describes a nice little model that helps thinking about how much you care about an issue - and therefore how much passion (and thereby energy) you should put into it.
To me, this article triggered memories of a similar insight. It has its origin in a session called "Following Your Passion Without Burning Out" at the Retrospective Facilitator Gathering 2007. One result of that Open Space session was that a small group of people met online regularly to support each other fighting burnout. With quite some success, at least for me.
At last year's gathering, I offered a small follow-up session, to report on how it went. The main insight for me, though, came with the report back to the whole group. I don't remember what exactly triggered this thought, but anyway, here it is:
What helped me most preventing burnout was getting passionate about my own well-being. That way, I didn't have to hold off my passion, which always feels kind of depressing. I just had to refocus it!
I have the feeling that this idea can be applied even more broadly. Take Karen's "going to the movies at date night" example. Say I am mildly passionate about watching a specific movie. The Circle of Care might help me think about how much I want to invest yourself into this specific choice.
On the other hand, I might find it a bit hard to make this choice in a vacuum. In that case, I might think about what else I am passionate about that might balance my passion for the movie. For example, how passionate am I about spending a peaceful, or even joyful, evening? What about making my partner happy? What else?
This thought is still in an infancy for me, but I feel that it might be in those situations, where I conciously prioritize my passions, when I make decisions that I'm most happy about.
In fact, now that I've written this down, it all seems so obvious that surely this must be old news - others must have had similar ideas, and probably some of them have written about it.
If you know of resources regarding this topic, or find this to be helpful - or think that it's total nonsense, for that matter - please leave a comment. Thanks!
Now I'm going to balance my passion for writing blog entries against my passion for helping my spouse installing new cork flooring. Already feels like a good decision... :)

Retrospective Antipatterns

2009-03-25T17:36:00.000+01:00

Are retrospectives an antipattern asks Steven. There are some interesting points raised there, and I certainly can see some antipatterns (some of which I have been guilty of, too). I don't think it's the retrospective per se that's the antipattern, though.
Here are a couple of patterns that I seem to be able to identify:

Retrospective replaces ad hoc problem solving

You need a problem solved. The retrospective is a place to identify and solve problems.
Antipattern solution: Wait until the retrospective to raise the problem and get it solved.
Consequences: Problem resolution is deferred. The retrospective gets swamped with problems. Not enough time in the retrospective to solve all problems, let alone to explore what is not yet known.
Refactored solution: If you get aware of a problem, raise and solve it outside the retrospective. Enter the retrospective with an open mind to what new things you might discover and want to tackle.

Retrospectives as reporting to management

A problem is perceived to be only solvable with management involvement/approval.
Antipattern solution: Create actions that need management involvement or approval.
Consequences: Problem resolution is dependend on management taking action. If management has different priorities, nothing happens. Retrospectives degenerate into complain sessions, where you don't even expect to be able to make a difference.
Refactored solution: For every problem, come up with at least one action that doesn't need management involvement or approval, and will improve the situation at least a bit.
Result: Continouos improvement, however small. Team members get a better feel for the power they actually have. Managers see team members take initiative. They might even get interested in getting involved in the ongoing change.

Living in the (bad) past

Retrospectives are about looking back - they even have it in their name. And I remember a lot of problems I had.
Antipattern solution: Focus on talking about what happened. Focus especially on what went wrong.
Consequences: The retrospective becomes a depressive, energy draining meeting noone enjoys.
Refactored solution: Yes, look at the past - to share stories, to further understanding, and to paint a picture of a brighter future. Focus on what you have learned, on what you want to do differently (or the same!) in the future. Try an Appreciative Retrospective.
Result: A forward looking team with the energy to make a difference.

The Silver Bullet

You have a deep rooting problem. Retrospectives are meant for problem solving.
Antipattern solution: Expect retrospectives, facilitated by someone who is barely trained for it, to be enough for solving your problem.
Consequences: The problem gets worse. Facilitator and group loose faith in retrospectives and their ability to solve this problem.
Refactored solution: Don't rely on retrospectives alone to solve your problem. Responsibly manage the problem. Get an expert involved.
Result: A chance to actually resolve your problem.

More patterns?

OK, that's enough for now, although I sense there are more. What retrospective antipatterns have you seen?

80 percent of people believe their performance is above average - and they might all be right!

2009-02-15T21:58:00.000+01:00

I've heard it stated several times yet: psychological studies show that "80 percent of people believe their performance is above average". And invariably this is used to show that people are bad at evaluating their own performance, because it obviously can't be right.
Well, it actually can, mathematically. Take a group of ten people, two having a performance of 1 (whatever that means), the other eight a performance of 2. The average performance of people in this group is 1.8 - and 80% are performing above that average. qed
My guess is that most people confuse average and median when they make this argument. I'm not sure that the people who say they are performing above average do so, too...

agile != Agile

2009-02-07T18:25:00.000+01:00

This has bothering me for a quite a while, now: people confusing the name "Agile" with the dictionary definition. Everytime I see a presentation at an Agile track on an Agile conference that starts with its own definition of "Agile" that has no resemblence with Agile Software Development at all, I want to either scream or cry.
Fortunately, William Petri has just published a blog entry on exactly this topic, where he explains in much better words than I would have used what the difference is.
Thank you, William!

"I will!"

2009-01-10T14:45:00.007+01:00

On August 9th, when Deborah and I where stuck on the highway to Niagara Falls, I told her "you know, I don't really care what we are doing, as long as we are doing it together." Little did I know the prophetic character of those rather lightly spoken words. Over the last five months, our relationship has deepened and strengthened in amazing and breathtaking ways. Yesterday¹ evening, in the presence of a small circle of family and close friends, we honored and celebrated the special bond between us, using the following vows:

My beloved Deborah, I, Ilja, take you to be my companion, my constant friend, my muse and my love from this day forward. In the presence of our family and friends, I offer you my solemn vow to be your faithful partner in joy and in sorrow, in times of plenty and in times of want. I promise to love you unconditionally, to support you in your goals, to honor and respect you, to laugh with you and cry with you, to nurture you and to grow with you through all of life's challenges. I will cherish you for as long as we both shall live.

My beloved Ilja, I, Deborah, take you to be my companion, my constant friend, my muse and my love from this day forward. In the presence of God, our family and friends, I offer you my solemn vow to be your faithful partner in joy and in sorrow, in times of plenty and in times of want. I promise to love you unconditionally, to support you in your goals, to honor and respect you, to laugh with you and cry with you, to nurture you and to grow with you through all of life's challenges. I will cherish you for as long as we both shall live.

It was a nice, small ceremony. We are both very happy, as should be apparent from the photo, taken after the wedding dinner. :)

We will get our custom wedding bands next Friday, just the day before I go back to Germany. Deb plans to follow me just a handfull of weeks later. Once we are settled in Germany, we plan to follow up with a bigger wedding party, to share our joy with all those friends and relatives we weren't able to invite to this event at short notice.

These are amazing times for us. Best wishes to all of you out there, may your life be as full of luck and joy as mine!

Our Team Room

2008-11-07T14:43:00.000+01:00

I've just recently posted a photo of our new team room to the Flickr Agile group:

Click on the image to get to the Flickr page, including a short description and the option to look at a bigger sized version.

Change is Easy!

2008-07-19T14:42:00.000+02:00

It's a truism that change is hard. Being an Agile evangelist, I experience it all the time. There is just so much resistance to new ideas, to trying new ways, that sometimes it feels like there won't ever be any significant change at all.
But the more I learn about being a change agent, the more I come the conclusion that this is an illusion. An illusion that I keep up to protect myself from the brutal truth: change is easy. People want change, they want to change, and change and implement change all the time - just not in the ways I would like them to.
Changing other people in ways that I deem appropriate, that's hard. Asking people how they want to change, and how I can help them change, that's easy. Why don't I do more of the latter?

Keep a Sense of Wonder!

2008-06-26T21:03:00.000+02:00

I'm currently reading the book "The 9 Disciplines of a Facilitator", which I find to be highly insightful. It discusses nine complementary ways of building self-mastery for facilitative leaders.
One of those ways the authors call "Sense of Wonder". It is about appreciating the unknown, about deciding that it's worth for the learning experience alone, and - in my understanding - about expecting to be surprised. That principle rang true for me from the first time I read about it. I still had some trouble really connecting to it, though - until recently...
Being an Agile evangelist for over a decade now, I've also become quite fond of Lean Software Development in the last years. And one of the principles I always liked most (in theory at least) is Stop the Line. So I regularly brought up the principle as a possible solution at opportunities that arose every couple of weeks to months. "You know, at Toyota when they have a small problem with one machine, they immediately stop the whole line..." And, not surprisingly to me, it was smashed down every single time. "Sounds interesting, but that wouldn't work here." "We wouldn't be able to produce software for months if we did that. We can't afford that." You get the idea. I didn't give up, but I also didn't expect this idea to sprout any time soon...
Two months ago, in one of our biweekly team meetings, we had a discussion about our continuous integration server, or rather about our integration discipline - the build would fail often, and it wouldn't be clear who feels responsible for fixing it. We talked a bit about some of the root causes for our problem, and then started a brain storming session on possible fixes.
One of my teammates, half-jokingly, came up with the idea that Eclipse could refuse to commit changes that would brake the build. Another teammate (who also is quite fond of Lean) remarked that that reminded her of "Stop the Line", so this made it into the list, too. No objections where raised, as we were still in brainstorming mode.
After the brainstorming, we clustered the suggestions, and one category we named - "Stop the Line". (At this time, I was more and more taking on the role of an observer, magnetized by the experience.) Then we performed a dot voting on which of the suggestions we wanted to implement. Guess what, "Stop the Line" got by far the most votes - almost everyone in the team voted for it! I felt like I was dreaming - and it was a quite nice dream. :)
So we are doing Stop the Line for more than a month now. It isn't going as smoothly as you might wish, and we are still in the process of adapting it. On the other hand, we already did implement many more improvements to our build systems than in the years before. And our team lead told me that he thinks the principle might also be applicable to bugs. Wow! :)
But most importantly, whenever I'm depressed that things are going so slowly and that some things look like they will never have a chance of being improved, that there is just so much resistance that I wonder whether it's really worth it - I can look back at this experience and tell myself: Wonders happen!

The Beauty of the Prime Directive...

2008-06-17T08:27:00.000+02:00

I always knew
that there is beauty
in the Prime Directive

Workation Day - adapting Google's "20% free-time"

2008-05-18T20:13:00.004+02:00

At the end of last year, our team started trying something that we call an "Aarlaubstag". "Aarlaubstag" is a compound of the German words "Arbeit" (work), "Urlaub" (vacation) and "Tag" (day). (And, in fact, "Aar", which is a poetic word for "eagle". No deeper meaning here...) It has worked well, and we are now having one every month. But what is it? Read on...

The Context

As I wrote earlier, we had quite some laborious months at the end of last year. We were somewhat concerned about burnout and accumulating technical debt, so we discussed with our management about some compensation for the stressful work.
There were a number of proposals, such as a refactoring week, for example. Finally, we decided to have an Aarlaubstag - basically a full day of "do whatever you want".

How it works

At the Aarlaubstag, the whole developer team meets at 9 AM for a breakfast. Here we discuss what we want to do for the day, and whether we want to pair with someone.
After the breakfast, everyone goes to "work". There is literally no constraint at all on what you do (at least we haven't hit one yet).
At 12:30, we have lunch break for an hour. Typically, we eat lunch together and talk about what we experienced so far. (Sometimes, there even is some time left for my power nap.)
At 4:30 PM we meet again for a short closing. We tell each other how it went, and whoever wants to, demonstrates what they accomplished. Then we call it a day...

Results

The most interesting observation from the first Aarlaubstag was that, according to our tracking, we weren't noticeably less productive in that week than the weeks before. Reasons probably include improved motivation for the rest of the week, and the desire to have less of other meetings. We also expect some positive long term effects, for example from improvements to our working environment that get done during the Aarlaubstag.
There is a wide range of different things that get done at this free working time:

experimentation with new techniques, such as AspectJ, Eclipse RCP or GWT,
improvements to our build system and our testing infrastructure
a tool to automate the distribution of our software to our customers (which beforehand needed a number of manual steps being executed on the command line)
usability improvements to our main product
etc. pp.

The future

The list of ideas for the Aarlaubstag is unlikely to run out any time soon. It's encouraging to see what ideas are emerging when there is time to implement them.
Currently, we use the stand up meeting at the first Tuesday of a month to decide when to have our next Aarlaubstag. Typically we choose one of the Wednesdays of the month. We also keep the option open to decide to skip one month, but didn't make use of it yet. In fact, I don't see why we ever would.

Conclusion

The way we implemented the Aarlaubstag, there are some considerable differences to Google's "20% free time" (at least from what I know about the latter). First, it's obviously only 5%, not 20% (which made it somewhat easier to convince management to try it). On the other hand, it is truly free - you don't need to get managements permission for the project you want to pursuit in that time (which I understand you need to do at Google). And it's a team effort - although we don't all work on the same thing during the day, we share our experience with each other, inspire each other - and share the fun (and sometimes some frustration)!
This practice has been immensely helpful for us - much more than I would have imagined beforehand. If it sounds interesting to you, I'd like to encourage you to try something similar, something that is adapted to your team's culture. It's simple, it's fun, and it's inexpensive to try. You might be surprised what you get out of it!

A Lightweight Appreciative Retrospection

2008-03-09T19:54:00.002+01:00

In December last year, our team had to meet a challenging business goal, and to meet it we changed quite a lot of our process. We planned to hold a retrospective on the changes in the new year, to see what we would keep, and what should be changed.
As the end of the year came close, we felt the desire to have some kind of reflection at the end of the year, too. It felt strange to go on Christmas holiday without having talked about the changes at all. On the other hand, we didn't feel the need to create action items, which we wouldn't feel very connected to when coming back from holiday. Instead, we wanted something lightweight and fun - and preferably something appreciative (that is, inspired by Appreciative Inquiry, which we had good experiences with in the past).
I took on the task to design and facilitate this retrospection. For the main part, I decided to use an appreciative variant of the Like To Like exercise from "Agile Retrospectives". The session was quite well received, so I thought I'd share with you how it worked:

Setting the Stage

After presenting the goal and the agenda, I asked everyone to imagine that he or she would give a personal party to celebrate the accomplishments of the month. In round robin fashion, they should state in one or two words what theme or motto the party would have.
Although our group is always a little bit shy about these kinds of exercises, I think it did a good job on getting everyone involved and setting the mood for an appreciative session.

Game Preparation

Everyone got six index cards and a big marker. Then, in succession, I asked them to write each two cards for the top things

we had already done before December, and continued to do in December
we had changed in December
we could change in January to make it an even better month

(For that last part, I actually asked them to imagine that we were at the end of January, that it had been an even better month, and to write down the top two things we had changed for that to happen. I'm feared by my team for this kind of question... ;)

Playing the Game

From earlier games of Like To Like, we already had quite a bunch of colored index cards with adjectives written on it. So for this time, I only had to select a couple of cards which I thought had at least a potentially positive connotation. (Normally, when not playing the appreciative version, you will want to have a balanced mix of positive and negative adjectives.)
So we played one round of Like To Like, which was quite some fun. I won't repeat the game rules here - if you know "Apples to Apples", you know the drill. If you don't, I urge you to buy a copy of Diana's and Esther's book - if you are interested in retrospectives, you should do so, anyway.
After the first round, we still had enough cards left for a second round, but the team decided to go on to the next step in the agende, which was the

Open Discussion

Now we put the already played cards in the middle of the group (most of us were actually sitting on the floor or on the sofa), and the players started to reveal the cards they hadn't played yet, saying a few words while doing so and answering questions when things were not clear.
When all cards where laid open, a discussion started on what patterns were observed and how people felt about it. This part had a quite nice atmosphere, with everybody being involved and interested in listening to the views of the others. Facilitating this was a breeze. :) And I think it did a great job at getting mutual understanding on how we felt about the changes we did, and the future we hoped for.
When the discussion slowed down, it was time for

Appreciations

I invited the team members to offer appreciations, in the form they already knew from a Temperature Reading we had done earlier that year: "[name], I appreciate you for ..." As always, things started slowly, but then we got quite some appreciations, which was nice.

Closing

When we came to an end, I thanked everyone for the nice experience, and asked for feedback in kind of an informal "Plus/Delta" (again an exercise from "Agile Retrospectives"). I just wish I had written down the suggestions I got. :(

Conclusion

Never before I had so heavily adapted and remixed exercises for a custom made "retrospective". The feedback I got from the attendees was quite encouraging. And it definitely fueled my enthusiasm for appreciative retrospectives.

You Are Gonna Need A Good Design

2008-02-27T21:46:00.002+01:00

"You ain't gonna need it!" (short YAGNI) is one of the most popular, and probably also most misunderstood and misused mantras of Extreme Programming. Again and again I see it used as an excuse to not improve a design "because it already works".
I guess the following has already been stated in hundreds of places on the web and elsewhere, in some form or another - on the other hand I also think it can't be said too often:
YAGNI applies to functionality, not design. All Agile approaches I know of are quite adamant about the fact that you need a clean, well decoupled, cohesive, duplication-free, expressive and extensively tested design from the beginning. One that is optimized for the currently implemented (and needed) functionality.

"It's easier to ask forgiveness than it is to get permission" - promoting courage and responsibility

2008-02-10T11:20:00.003+01:00

When I first heard this quote, I didn't like it. It sounded to me like it promotes disrespect. It sounded to me like it said "don't waste your time caring about the needs of others, just do what you want. If they don't like it, you can fix that by appologizing."
Respect still is an important value to me today. Still, I like that quote more and more, as I begin to read it differently.
In fact, I think that neither getting permission nor asking forgiveness are what is at the core of a good change initiative. What seems to be much more important is taking responsibility for the world you live in, and fostering a discussion leading to mutual understanding.
So I see two advantages with implementing a change without asking for permission:

I take full responsibility for the change. If it affects someone negatively, I will be more inclined to get into a constructive discussion, possibly leading to an adaption of the change, instead of just answering "but it was approved by [insert some authority person here], so it's not my fault".
Discussion of the change will take place in the presence of real feedback, in the presence of actually observed advantages and disadvantages - instead of speculation, fear of the unknown, and ungrounded expectations.

To me, this is another step to understanding why Courage is an important value in Extreme Programming. And I find it amazing how good - how liberating - it feels to act courageously and responsibly.
Thank you Kent! Thank you Grace!

Collaboration, Self-Fulfillment, and Everything

Modeling The Real World vs. Designing Software

An Agenda for Backlog Grooming

The Shu Ha Ri of Inheritance versus Composition

The Aha-Experience Exercise

How it works:

First round of gathering aha-experiences (15 min.)

Keep it flowing

Debriefing (20 min.)

Conclusion

Come to Agile Coach Camp Germany!

Focus on Whose Value?

Tips for Being a Timekeeper

Keeping the time is a service to the attendees

Clarify expectations and constraints

Timebox activities

Use a simple timer

Use curt timeboxes, enforce them gently

Let the group decide

Use a parking lot

Incorporate breaks

Plan for alternatives

Blowing the timebox isn't a failure

Index Cards are Tools, too!

Scheduled Retrospectives are Good

When to Introduce an Interface (in Java code)

Criteria for a Scrum Tool - or any Agile tool, that is

"Fix This Defect" Is Not A Feature

Should Software Development Be More Like Engineering?

You Might Need To Leave Your Comfort Zone...

The Balance of Care

Retrospective Antipatterns

Retrospective replaces ad hoc problem solving

Retrospectives as reporting to management

Living in the (bad) past

The Silver Bullet

More patterns?

80 percent of people believe their performance is above average - and they might all be right!

agile != Agile

"I will!"

Our Team Room

Change is Easy!

Keep a Sense of Wonder!

The Beauty of the Prime Directive...

Workation Day - adapting Google's "20% free-time"

The Context

How it works

Results

The future

Conclusion

A Lightweight Appreciative Retrospection

Setting the Stage

Game Preparation

Playing the Game

Open Discussion

Appreciations

Closing

Conclusion

You *Are* Gonna Need A Good Design

"It's easier to ask forgiveness than it is to get permission" - promoting courage and responsibility

You Are Gonna Need A Good Design