NAYIMA
Nov
24

SimBlogging: XP Days Benelux 2008 Retrospective

‘SimBlogging‘ offers a his and hers viewpoint as Pascal and Portia timebox-blog simultaneously

From dawn …

At the crack of dawn, organisers and friends hold a standup to kick off the day. Most of the material had already been brought in and prepared the night before, after the pre-conference dinner and drinks. Tasks are quickly written on sticky notes; the wall serves as our kanban board. All the tasks quickly move to Done as everyone chips in. Participants trickle in, grab some coffee to wake up and register. XP Days is rolling.

The day traditionally starts with the Official One Minute Presentations (OOMPs), shortened to 30 seconds because of the large number of sessions, where presenters pitch their session in weird, funny and unusual ways. This immediately sets the right tone for the conference: Agile is serious, but we don’t take ourselves too seriously.

… till dusk

Every day closes with the mirror of the OOMPs, the Official One Minute Participant Presentations. For each session in turn, session participants stand up and tell us what the session was about and what they learned, so that everybody at least gets some information about the sessions they missed. Judging by the smiling faces everybody had a great day taking part in interesting sessions.

At XP Days Benelux we don’t differentiate between speakers and participants, other than that speakers get in for free. XP Days Benelux is about sharing, communication and collaboration.

Gaming into the night

Each participant could choose a persona for their badge. Nicole and Johan had devised a social game with the session proposal personas: participants should seek out people with interesting personas to create a team. Teams had to present themselves at the closing and won prizes. The persona game was a great way to meet with new people and created a lot of buzz during the whole conference.

The fun and discussions continued well into the night at the bar (with free drinks thanks to our sponsors) and at dinner. Conversations continued well into the night at the bar. The more energetic and competitive participants played board games until 2:30 at the Games Night.

House rules

At the start of the conference we explain that XP Days Benelux has only one rule:

Participants participate

Most of the sessions are interactive, participative and invite discussion. For the organisers, there’s very little work to do after the sessions start. We try to manage with a light touch. We offer the participants the context in which they can create their conference. Two examples of participants taking responsibility were:

  • Jamie and Joke stepping in to organise an Open Space session and an impromptu presentation about Agile Analysis to replace two cancelled sessions.
  • A group of participants helping the friendly ladies from Koningshof plan the asymmetric coffee breaks on Friday afternoon.

Sessions

The Critical Chain session by Christophe and Olivier let us build cars with Lego to improve our planning prowess. Not surprisingly, the two teams that collaborated and shared knowledge did better than the other teams.

Seeking to Perceive more than to be Perceived by Emmanuel and Bernard let us experiment with three communication tools, “Investigate Protocol”, “Soft Focus” and “Emic Interviewing”. The aim of the session was to come up with ideas and a plan to improve next year’s conference. There were some good ideas in the session. If you want to help make them reality, contact us and volunteer for XP Days Benelux 2009.

Vera, Portia and I ran the Business Value Game with five teams. The participants were really absorbed by the game. The standup retrospectives allowed the players to reflect on the questions raised by the game. One of the takeaway points from the session was that we need to have a (probably difficult) conversation about the way our company, our team prioritises because that will reveal what we really value.

A whole room of Agilistas was rapt listening to Portia retell the Snow White fairy tale in the “Mirror Mirror… Why Me?” session. The participants speed-networked and reflected before working together to come up with a dwarve dream team to realise their fantasy project. The session ended on a high note with the “one minute investor pitches” where the projects and the teams were presented.

Including “Working with Resistance” in the program was a bit of a gamble. Would participants be interested in an Aikido session? We’re happy that Olivier Costa proposed this session, because a packed room participated in the exercises and stood in awe at the demonstrations by Olivier and his sensei Frank. After a whole day of working with our heads and hearts, this session got our body working. The lessons for introducing change are clear: work with the other’s energy, not against it.

Done

Another XP Days Benelux is over.

We’re collecting the feedback and ideas of participants and organizers to improve next year’s edition. If you want to make XP Days Benelux 2009 better, contact us to become part of the organising team.

—

Photos by Xavier Quesada and Portia Tung

November 24th, 2008 | Category: agile, XP Days Benelux, xpday
Nov
19

XP Day Benelux – 2

Preparing for XP Days Benelux

Thursday, the XP Days Benelux start. The first sessions start at 10:00; the conference organisation is about done by then. Once the conference gets going, there’s not a lot of work for the organisers. From then on, the session presenters and participants have to do their bit. We’re not kidding when we say that “the focus of this conference is on practical knowledge, real-world experience, and active participation of everyone”.

Bigger and better than ever before

At least it’s bigger than before. The number of participants has grown steadily from 85 in the first year to more than 150 this year. We’ve always set a cap on the number of participants: 30 participants per track. That (plus or minus 10) is about the number of participants with whom you can have really interactive session.

Better?

We’ll know from the retrospective if we’ve improved on last year.

See you there

Or if you can’t be there, follow the conference via the FriendFeed XP Days Benelux room or read our presenter and attendees’ blogs.

More later.

November 19th, 2008 | Category: agile, XP Days Benelux, xpday
Nov
13

Being professional – pt. 3

A simple question

Agile Coach: OK. A professional takes responsibility and is an openminded lifelong learner.

P: Yes. A professional knows what to do and does it.

Agile Coach: That sounds a bit mercenary. It somehow feels wrong to me. Is there no more to being professional?

P: (Embarrassed silence. Then) Let me think about it and I’ll have the answer by next week. Is that ok for you?

Agile Coach: Yes. I want to become a good professional.

What is the acceptance test for “a professional”? How can we recognise one? What are the essential characteristics of a professional?

Acceptance criteria #3: A professional acts ethically according to values

A professional acts according to a Code of Ethics

The ACM and IEEE have a Code of Ethics for Software Engineers. Here is the short version:

Software engineers shall commit themselves to making the analysis, specification, design, development, testing and maintenance of software a beneficial and respected profession. In accordance with their commitment to the health, safety and welfare of the public, software engineers shall adhere to the following Eight Principles:

1. PUBLIC – Software engineers shall act consistently with the public interest.

2. CLIENT AND EMPLOYER – Software engineers shall act in a manner that is in the best interests of their client and employer consistent with the public interest.

3. PRODUCT – Software engineers shall ensure that their products and related modifications meet the highest professional standards possible.

4. JUDGMENT – Software engineers shall maintain integrity and independence in their professional judgment.

5. MANAGEMENT – Software engineering managers and leaders shall subscribe to and promote an ethical approach to the management of software development and maintenance.

6. PROFESSION – Software engineers shall advance the integrity and reputation of the profession consistent with the public interest.

7. COLLEAGUES – Software engineers shall be fair to and supportive of their colleagues.

8. SELF – Software engineers shall participate in lifelong learning regarding the practice of their profession and shall promote an ethical approach to the practice of the profession.

Copyright (c) 1999 by the Association for Computing Machinery, Inc. and the Institute for Electrical and Electronics Engineers, Inc. Read the the full version

Read the short and the long version. Replace ‘Software engineer’ by I. Does this code of ethics apply to you?

A professional acts according to a set of Values

Daniel Dennett shows in “Darwin’s Dangerous Idea” that we don’t have the time or resources (or even the techniques) to completely analyse our ethical dilemmas. Rules and values offer convenient shortcuts to quickly resolve dilemmas in a reasonably good way.

That’s why I try to act according to a set of Agile Values.They act as warning lights for potential problems.

Communication

Of course, we talk a lot, write and read a lot of documents. But do we communicate well? Do all stakeholders of our project talk the same language, use the same metaphors and have a common vision? Do we verify if we understand others, for example by using the “9 boxes” interview technique?

Collaboration

Of course, we’re all in the same room (except for the testers and the systems engineers and the support team and…). But do we all really collaborate? Do we have common goals across the whole value chain, including partners and suppliers? Are we all aligned towards that common goal? Do we succeed and fail as a team or am I rewarded for personal successes?

Feedback

Of course, we always work with short iterations. But have we built in mechanisms to give us rapid and regular feedback? Do we steer our project based on the feedback? How long can we afford go “steady as she goes”? Is our feedback cycle shorter than that? What do we do when our feedback mechanisms give us bad news?

Simplicity

Of course, we know about YAGNI and DTSTTCPW. But do we really work to keep things simple? Do we invest the refactoring time and effort to keep our software simple and malleable? Do we reflect and adapt our processes to keep them simple, lean and efficient? Do we relentlessly strive to make everything simpler?

Quality

Of course, we know that “Quality is Free“. But do we really believe that? Do we keep our standards for quality high when we’re under pressure — especially when we’re under pressure? Are we tempted to take shortcuts and “fix it later”? Do we support each other to resist the pressure to do things “slow & dirty”? Do we welcome issue reports and perform root cause analysis so that we can implement Jidoka and Poka Yoke?

Respect

Of course, we all respect each other. That goes without saying, which is why this value was left out of the original Agile values. But then why do we still see deathmarches? Do we respect the value that each team member brings to the project? Do we respect the ‘other’ teams with whom we have to collaborate?

Trust

Of course, we trust each other. But, do you really trust everyone on the team to make correct changes to your code? Do the developers really trust their management’s judgments and decisions? Do managers trust their team’s estimates and technical choices? Do we trust the onsite customer’s choices and priorities? Do we trust that everyone on the team will take responsibility? Always?

Transparency

Of course, we’re transparent; you just have to come look at our whiteboard and burndown chart. But do we really make all information visible, including the bad news? Do we really share the project risks with everybody involved, including the customer?

Do I Pass the Test?

There are few people who would dispute the ‘goodness’ of these values or the code of ethics guidelines, yet they’re hard to follow. We’ve all seen people who’ve compromised these guidelines under pressure. We’ve all been in situations where we were at least tempted to compromise or lacked the courage to stand up for our values. I certainly have.

Read the the full version of the code of ethics and ask yourself: do I pass all of those acceptance tests?

What can I do today to improve my ‘score’?

What small step can I take today to become more professional?

November 13th, 2008 | Category: agile
Nov
09

Being professional – pt. 2

A simple question

Agile Coach: OK. A professional takes responsibility.

P: Yes. Many projects go wrong because so few people really take responsibility.

Agile Coach: Blaming is much easier, isn’t it? Is there more to being professional?

P: (Embarrassed silence. Then) Let me think about it and I’ll have the answer by next week. Is that ok for you?

Agile Coach: Yes. I want to learn more about becoming professional.

What is the acceptance test for “a professional”? How can we recognise one? What are the essential characteristics of a professional?

Acceptance criteria #2: A professional is openminded and a lifelong learner

Other people might have good ideas too

Recently I heard a bunch of “Agilistas” dismiss CMMi offhand. I know of CMMi implementations and training that were poorly done and resulted in not much more than extra overhead. Some people don’t understand the spirit and only know the letter. I’ve seen the same with Agile. Despite flawed implementations, CMMi contains a bunch of interesting ideas and techniques. The spirit of CMMi is compatible with my Agile values.

At another Agile gathering hackles were raised when a presenter dared to suggest that the Lean practice of “Standardized Work” might be usefully applied to IT work. “We’re not production workers!” they cried. Others dismissed practices because they would be used by “evil managers” to create “plug-compatible programmers”. My hackles went up when a session presenter recently dismissed first all managers then all salespeople as ignorant and evil.

A professional can’t afford a closed mind.

Other discplines, other approaches and other professions have interesting ideas. The most interesting training I ever followed was a sales training.

I like conferences where I can see and meet presenters with different backgrounds and ideas. For example, I like the diversity in subjects and delivery of the Benelux XP Days, but I worry that there are few sessions that present something I disagree with. I wonder why there are so few sessions that explain what went wrong with Agile.

I seek to perceive more than I seek to be perceived. I seek and find value wherever I can.

Mistakes are a learning opportunity

We’re trained to dislike and avoid mistakes. However, mistakes do happen. How we react to them allows us to see who the professionals are.

A professional says “Thank you!” to a bug reporter.

When we learn of a mistake we get the opportunity to do some deep learning and improvement. We learn from the answer to two questions:

  • “Why didn’t we detect this problem earlier?” What’s wrong with our tests? Why wasn’t this case covered? How can we detect this type of issue sooner? How can we improve our tests? If we do this consistently, we implement “Jidoka” so that we’re alerted immediately when something goes wrong and can fix the problem while it’s still cheap to correct.
  • “Why did we make this type of mistake?” What is the root cause of the problem? What is it that allows this type of problem to occur? How can we change our work or methods so that this type of problem can’t occur? If we do this consistently, we implement “Poka Yoke” or mistake-proofing because the cheapest issue to fix is the one that doesn’t happen.

I welcome reported mistakes as a learning opportunity.

Continuous Improvement

Standardized Work documents the best way we know of doing something. Tomorrow we’ll do better. It’s important to celebrate today’s successes. But we know we can do better next time, if we learn and improve.

A professional always looks for ways to do things better.

Thinking tools like Systems Thinking, Theory of Constraints, Lean and Agile help me to make sense of the situation, see places to intervene and find creative ways to make things better. Personal Agility tools like Congruence, Agile Fairytales and other games allow me to become a better person, colleague, friend and coach every day.

I have done my best today; I can do better tomorrow.

Invest in learning

All of this improvement and learning costs time, effort and money. Companies and people facing difficult times fear they have none of these three. Yet, when the going gets tough the smart keep learning.

A professional invests in learning.

I meet new people at work, conferences, training and talks. I learn something from each person I meet. Every situation has interesting angles that make me see new things. Books, both fiction and non-fiction, make me travel to different worlds, introduce me to new people, new ideas. I read about a subjects that are outside of my normal expertise and work. For example, this year I read about physics, evolution, consciousness, free will and philosophy and I re-read fairytales.

I set aside time and money to keep learning. I will keep learning for the rest of my life.

November 9th, 2008 | Category: agile, lean
Nov
07

SimBlogging: AYE 2008 Retrospective

‘SimBlogging‘ offers a his and hers viewpoint where Pascal and Portia timebox-blog as a pair on the same topics simultaneously

What Went Well

I finally got to see Heathrow Terminal 5, where I met up with Portia. We got an upgrade on our ticket thanks to the friendly British Airways lady at the checkin desk. A good start.

10 hours later, in Phoenix, the heat, sun, blue skies, pools, palm trees and cacti are a bit of a shock after grey, dreary and wet Brussels and London.

Our “Mirror Mirror on the Wall… Why Me?” Agile Fairytale BOF was met with enthusiasm and we kept playing the game during dinner and drinks, resulting in plenty of “Aha! moments”.

We played the “Quality vs Speed” game that looks at the tradeoff between releasing early and finding/fixing bugs. We managed to win thanks to our clear, simple and adaptive process built upon our shared team principles of “Quality AND Speed”. We might have done better if we had collaborated with the other teams, but at least we shared our process with the others. During the retrospective we discussed if the model of the game is still relevant to Agile projects. When we work with short timeboxes and give priority to DONE stories (without known bugs), the main tradeoff is one of time vs scope. And then we can apply the Business Value principles, which is another game altogether.

Several other sessions provided new learning or illustrated material I already knew:

  • Experiencing the coping stances and congruence by sculpting the stances.
  • Selling ideas to management (or anyone else for that matter) where we experimented with different techniques to sell ideas to a manager. I got to play the manager, which is always fun. I tried to be helpful and sympathetic to the person who came to me with their idea, but I failed to help the “seller”. Clearly, management is not as easy as it sounds.
  • In the “Just Enough Leadership” session we got to experiment with the “wisdom of the crowds” to see if a team came up with better rankings. The session included collected metrics, including one measure of correlation between individual and team scores that might indicate who led the team. We didn’t go very deep into the metrics, but correlation does not mean causation. In our team, we switched leader very quickly. We led by example: someone said “Lets…” and the others followed. If you have a good idea, there isn’t any need for endless debate to come to a consensus. Go for it and see if you’re followed, because a leader is defined by their followship.

Although “I’m an Introvert”, I enjoyed the many discussions and talks with photographers, magicians, testers, jokers, would-be Evil Queens, managers, bloggers, stars and coaches from many countries that make up the audience of the AYE conference.

We ended our travels in Phoenix with a visit to the Heard Native American museum, where we learned more about the Inuit and Pueblo people with their “Katsina” and scary ogres.

Complaints with recommendations

The AYE “conference“, is a 5 day training course with 5 trainers. Either make it a conference with a set of diverse presenters who bring different perspectives or call it training.

The conference kicks off with the warmup tutorial (also known as the “Steve and Don show”) which explains the basic tools and terminology and MBTI types. Many participants wrote their MBTI type on their nametags. Is this a way to advertise “this is how I am and want to be treated”? The emphasis on MBTI types throughout the conference is a bit too strong for my taste. I see MBTI types as preferences, not something “that I am” and that can’t be changed. I would recommend:

  • ensuring that there is a clear disclaimer about MBTI, that these are preferences, that this is a default that we will fall back on when we are stressed. Our MBTI type is not a fixed pattern that determines how we work and act.
  • working with mixed teams, instead of by MBTI type, so that we can be more effective by exploiting the diversity of the team, one of the lessons of the “Mirror Mirror on the Wall… Why Me?” Agile Fairytale.
November 7th, 2008 | Category: SimBlogging
 
  Older Entries »