Free e-books about architecture and .Net programming

If, unlike me, you don't have a stack of books awaiting for you to read them, you should probably take a look at this page, where Anoop Madhusudanan lists 7 free e-books. It's always better when it's free, isn't it ?

To that list, I would also add two free resources about Domain Driven Design by Eric Evans. First this document available on domaindrivendesign.org and second Domain Driven Design Quickly, from the guys of InfoQ.

If you are interested in DDD, you can also take a look at the Time & Money project.

Agile Testing Days 2010 - Day 2 : Lisa Crispin's key note

I continue summarizing what happened at the Agile Testing Days in Berlin, starting with one of the key notes, given by Lisa Crispin called Limbo Lower Now : An Agile Approach to Defect Management.

In this talk, Lisa used the metaphor of Limbo dancing to explain why we should try to progressively lower the bar by reducing the number of defects in our applications.

In a traditional approach to defect management, bugs have to be documented in a Defect Tracking System (DTS), which provides information for analysis and metrics, and can be considered as a knowledge base.

However, Lisa explained how Mary Poppendiek told her once that defects should be considered as a queue of rework, or waste. In a more Lean approach, the ultimate goal of a team should be to tend towards zero defects. Bugs should be considered as technical debt and addressed as soon as possible. The thing to do would then be to write a test to reproduce the defect, fix it and move on. The test documents the bug and prevent it from ever coming back. It's also a kind of metric.

According to her, using a DTS presents some advantages

• Knowledge base
• Pioritizing
• Tracability
• Distributed teams
• Visibility
• Metrics

The major disadvantages of a DTS being

• Overhead
• Communication impediment
• Duplication with tests
• Inaccuracy
• Some bugs will never get fixed so why track them

Hence her recommendations

• Always write a test before you fix a bug to prevent it from coming back.
  
• Fix a bug immediately when it's found during development. This eliminates the need of logging it in a DTS.
• Consider defects that are found after development as stories in your backlog, so that you can estimate and prioritize them.
• Don't waste time on tracking things that will never be fixed : feature to be rewritten, low risk issues.
  
• Defects should be considered as a team problem. Do what works for your team.
  

Agile is all about inspect and adapt. You can start simple, with no DTS at all. Then if needed, you can log bugs on index cards, put them on your storyboard and treat them as any other story in your backlog. Eventually you can end up with a DTS if you feel that something is still missing. You can even duplicate the DTS issue on a index card to get the best out of both.

Lisa ended her talk by insisting on one point. Whatever your approach to defect management, do not loose tack of the ultimate goal, which is to prevent defect in the first place.

All in all, nothing really new in this talk. Lisa basically summarized what I have been doing within my team on my current project. Unfortunately, we are not yet at a zero defect level for our application. But we are getting close to it. Bugs found during development are not logged, since they are fixed right away. Major defects are eliminated from one sprint to another, and several minor issues are fixed in the mean time.

Agile Testing Days 2010 - Day 1 : Tutorial with Linda Rising

As promised, I will try to summarize and share my thoughts about my three days of attendance at the Agile Testing Days conference in Berlin in a series of posts.

This fist post is about the first day of the conference, where several tutorials were organized, each one being held by one or several well known speakers in the Agile world. The line up was quite impressive and the choice was difficult. To be completely honest, after having read all the tutorial summaries before registering, I wanted at first to attend to Lisa Crispin's tutorial. But it was already complete so, after numerous hesitations, I reduced my choice to two options : Linda Rising or Michael Bolton. I finally made up my mind and decided to focus my first day on communication aspects, by attending to Linda's talk. Do I have any regrets about this choice ? Absolutely not. Not that I wouldn't have liked to see the other speakers, but Linda was really inspiring.

I was the first one to enter the room that morning. Linda was already there and after a brief hand shake, she told me : "There will be only three of you with me today, so pick a seat and make yourself comfortable". The two other participants arrived just a few seconds later, and seemed as surprised as I was, that so few people would attend. After each one of us had introduced himself, explaining who he was, where he came from (Poland, Germany and France) and what role he had in his organization, Linda started talking, slowly and with eloquence, articulating every of her thoughts with examples, quotes, references, stories or experiments.

The day was split into two different presentations

• In the morning : Patterns for Improved Customer Interaction
• In the afternoon : Influence Strategies for Practitioners

Her Patterns for Improved Customer Interaction, she gathered them through interviews she had done, with many different people and personal experiences. What she calls Pattern mining.

Most of these pattern are common sense, but "Common sens is very uncommon" said she, quoting Horace Greeley for the occasion. She stated to explain that It's a relationship, not a sale is the top of a pyramid that is build on a base constituted by Know yourself, Know the customer and Build Trust.

All she said made so much sense. In my opinion, each one of the patterns is extremely simple to understand, even though very difficult to achieve. But as most things in Agile, it's the fact that all the patterns work together, that makes the big difference. Patterns are actually built on top of each other and that's what makes their strength.

Once she had explained these 4 main patterns, she had us read some short role play to explain the various lower level patterns, which she calls implementation patterns, among which you find :

• Listen, Listen, Listen
• Be responsive
• Meetings around the meetings
• Personal integrity
• Take your licks
• Be aware of boundaries
• Mind your manners

She ended the morning by summarizing that the customer is, before everything else, a human being, who just wants to be heard instead of monetized. Her advice : empathize by understanding the customer's point of view.

After a well deserved and copious lunch, the four of us came back to our large room to talk about what she called herself weird and scary stuff that would probably make us uncomfortable : Influence strategies

Even though people tend to think they cannot be influenced and they take their decisions in a rational manner, Linda explained that cognitive science has proven we actually all take decisions based on emotions, that we afterward try to rationalize using concrete explanations : lists of positive versus negative points, analysis, statistics, etc.

She based her presentation mainly on six of Robert Cialidini's strategies for influencing people

• Liking : we like attractive people and we like those who are like us
• Reciprocity : give a little, you might receive a lot
• Social proof : everybody else is doing it
• Commitment / Consistency : the first step is the most important
• Authority : if the expert says so...
• Scarcity / Exclusiveness : limited edition, for members only

Of course, most people would think that these are strategies that work on other people, not on smart people like themselves. But Linda proves with many examples, stories about experiments that have been lead sometimes decades ago, that all this is actually true and works on all non autistic or clinically depressed people.

Of course, there are some ways to resist these strategies or to work around them, but most of the time, even though you recognize the strategy, you will let yourself get caught.

Linda ended up the day on a positive note, saying that we can make these strategies useful. That all in all, they are just tools, which you need to learn to use, like any other, and which can be used for good reasons.

I must admit I ended that day at the same time excited by all these new things I had learned, but also a little overwhelmed, not knowing what I would do with all this. I think me writing this post is the beginning of the digestion process. I will probably need more time to really integrate this new knowledge in my day to day life, but I am really glad I chose Linda's tutorial. She is a very clever person with a long and rich experience of our industry, a great speaker who takes you with her while telling her stories, and above all, a very nice human being, extremely funny, daring and accessible.

Turn your presentations into stories

Johannes and I just attended our last session of the Agile Testing Days conference in Berlin. I will definitely try to find some time to blog about that in the next few days,  since there were very interesting talks there.

But, for the moment, I just wanted to bring to your attention a tool that really made a difference for some of today´s presentations. Prezi is like a giant canvas, or whiteboard, where you  can insert any kind of media (text, pictures, videos, etc.) and chain them in some kind of flow, with zoom or rotation effects, to build a very dynamic presentation that seems like a story, instead of a boring slideshow.

I am already a fan, and I am pretty sure you are going to see a lot more of these presentations in a near future.