Lean Lego Game @ dtsato.com

Since me and Danilo started presenting the Lean Lego game in 2008, a lot of people have been asking for information about how to run the workshop by themselves, in their companies, etc.. During this time, we have created a presenter pack, which we happily distribute to anyone who wants to use the material for non-commercial purposes.

To make this information more accessible and easy to find, we have created a page for the game, where you can find more information about it, and how to get in touch with us and get the material you need.

Here you go: Lean Lego Game

Enjoy!

Agiles 2009

I’ve been for the past two weeks in Brazil, and during this trip I’ve had the opportunity to participate in the 2nd Latin American Conference on Agile Methodologies, Agiles 2009, which was also being sponsored by ThougtWorks.

The conference itself was great, with a really good attendance (around 500 people), including students and professionals from different south-american countries and lots of good speakers, including Brian Merick and Diana Larsen.

I had a presentation on the first morning, titled “Is Agile The New Waterfall ?”, which tried to propose a discussion about how the (unfortunately) de facto way of agile adoption might influence negatively the future of the movement. Gladly, the presentation went really well, with a fully packed room, lots of questions and good feedback from the audience.

ThoughtWorks also used the opportunity to announce the opening of a brazilian office in Porto Alegre, which was done at the ending of a very well received keynote from Roy, which talked about the industry, his views on South America and also about the company and its purpose.

We had a great time overall, and the organizers should be congratulated for the effort of making this event possible, specially when all the people behind it were working as volunteers.

In case you are curious, you can find pictures from the event here.

Lego Lean Game in Sardinia

Last month me and Danilo presented an extended version of the Lego Lean Game at XP2009 in Sardinia, Italy.

This was the first time we tried this version, and it can be considered a success, with good feedback and some people asking information to run the workshop within their companies/classes.

You can find more information about how it went on this post Danilo wrote, and the slides are also available here (if you like to see how it went, pics are here). As he said, we prepared a package with all the material needed to run the workshop, so feel free to ask us for it if you have participated and are interested in doing it : )

Porto Alegre Agile Weekend 2009

For the Brazilian crowd (or anyone who wants to be part of it), between the 25th and 26th of April will take place in Porto Alegre (my home town : ) ), the 2009 Agile Weekend, which has my friend Daniel Wildt as part of the organizing team.

This will be hopefully the first of many Agile conferences happening in South Brazil, and will serve to boost even more Agile adoption in the region.

Needless to say, I really wanted to go, but London is not close enough to Brazil yet…

Ignorance is Bliss

Throughout our lives, we study and practice the skill we find useful for an incredible amount of time, expecting to be ready when the moment comes that we have to use them.

Despite still agreeing with the practice/study paradigm, I’m starting to notice that knowing everything is not the best solution in all the situations. This thought came to my mind again when reading a recent article in the Sport magazine, about which conditions made possible to the British cycling team to win so many medals in the last Olympic Games (if you want to know more about it, you can read it here).

What caught my attention was the description of the research and development group, responsible to discover the best technologies to be used in the cycling competition. The group actually collaborates with many people outside the cycling industry, like F1 teams, and aerospace and defense companies. When asked to explain why, the head of development answered:

We really value ignorance. So we got to ask people who really know nothing about cycling. An aerodynamicist will ask: ‘Why do you do it like that?’ We’ll look at each other and say: ‘I don’t know.’ That really opens things up

This is also described by Richard S. Wurman, in his book Information Anxiety, where he describes common problems in understanding, citing the expert opinion syndrome:

We tend to believe that the more expert opinions we get, the more informed we will be. But we tend to forget that expert opinion is by no means synonymous with objective opinion. Unfortunately, most experts come with a bias that makes obtaining truly objective information almost impossible.

And when it comes to software development, this situation can be easily seen in coaching, either externally or internally. It is not rare to see coaching being done with a biased opinion, where coaches arrive with a ready-made solution that they want to apply, despite the conditions being face by the team.

Solving problems, complicated or not, has to be done with a clear mind. We have to assume our ignorance when facing any new situation, so we can understand it better and provide the best solution.

The Wire Mistery Solved!

As a huge fan of  the “The Wire” series, as I always wondering how the Baltimore police  and its homicide department could be so bad. How could they have so many problems when trying to solve the crimes in the city?

Guess what, when watching one episode of the 5th season, I finally realized the source from all their problems, as the next picture shows…

They use Lotus Notes!

After that, is no wonder that the crime rate is so high….

I Love Banks

Deviating a little bit from the agile topics, Im writing this post to tell a little story about my relationship with a certain british bank, and how well they use IT for the client’s benefit.

I dont want to tell the bank’s name, because the purpose is not to create bad advertising or something like that, so for the moment I will just call this institution the bank of the citi.

So, beginning the story, last month I was surprised by having been charged interests in my credit card bill, despite having the feeling that I had payed in the right day. I sent my bank a message, which was replied:

our payment due date was 27th October 2008 and your payment was made on the 29th October 2008. Because the payment was late you have been charged the late fee and the interest.

Ok, but I still thought I’d payed in the right day, so I checked my account info and verified it. Second message to the bank of the citi:

my account info show the transaction was made on the 27th.

27/10 TRANSFER 538813

Why it is just considered in the 29th?

And then comes the surprise (in form of a reply):

When making a debit card payment to your credit card the timescales are up to two working days for it to clear onto your account.
If you require anything else please don’t hesitate to contact me again.

Then I thought: What?? And kept trying to understand how possibly it could take 2 working days to transfer some money electronically to the same bank.

Since I was in a good mood and the attendant had offered me his help, I decided to send another message:

I think the only question I have is how come it takes 2 days to do an electronic transfer, but probably it won’t solve my problem.

And here comes the answer:

It takes two working days for a debit card payment to clear onto accounts as it has to go through clearing and then be allocated to the correct account.

Oh, now I understand… It’s not a simple operation, like transfer the money. You actually have to subtract the money from one account, clear it (whatever this means), and then transfer it to the other one.

For some days after this whole conversation occurred, I tried to think how someone managed to build some software that needs 2 working days to perform one operation.

I thought that maybe there’s one batch job that gets the money from my account (which runs at midnight at D+1) and another one that gets this money and adds it to the other account (midnight at D+2), or  both operations happen at D+1, but then they need 24 hours to verify if the transaction was correctly performed, or there’s actually a person that goes to the safe where my account is, counts the money, and then goes to some other building where the bank account is, opens the safe and stores the money there… actually, no, this would be much faster than 2 days.

Uncertainty

This came to my mind when I was watching this lecture, given by Ricardo Semler at the MIT Sloan School of Management, in 2005.

At some point in the lecture, Ricardo talks about intuition, and how intuition is very useful to solve problems, but still is not accepted in the corporate world.

In his words, talking about the chess match between Kasparov and Deep Blue:

How is it possible, at all, for something with 4 moves (Kasparov) to play something with 4.000.000 moves (Deep Blue)?

…. There is only one thing that he has that the machine has not, and that  is intuition.

…. Where are we putting intuition to play in the corporate world?

And this thought stayed in my head. Why the majority of people find it so difficult to accept intuition and to deal with uncertainty? In Ricardo’s words, why are we willing to trick ourselves and everybody else into thinking that we have control?

And why is this topic relevant to software development?

Because that’s one of the reasons that make agile methods so difficult to be accepted. Most people are not prepared to accept that the project duration can’t be precisely measured. Or that the scope should be flexible, because we still don’t know (oh my God!) what is important and what isn’t. And that the decisions we make should not be based on a complex function point calculation, but in simply in the team’s intuition?

Instead, they prefer to develop software in ways that have failed for many and many years, but still thinking on having control over all the project. They find easier to believe in an excel-calculated estimate for the total project of 170.1234hs than in an estimate that says “roughly 1 month”, and they hope to deliver software within fixed budget, size, scope and quality (good luck with that).

As Ricardo cited, it doesn’t matter if you are wrong, but you have to be precisely wrong.

Cheers

Don’t Blame The Prime Directive

I’ve been wanting to write this post for some time now, but just now I figured out what I wanted to say, so let’s do it!

What triggered this post was this article published in InfoQ, replied also in this other blog, about a discussion around the Retrospective Prime Directive, which, for those who don’t know, goes like this:

“Regardless of what we discover, we understand and truly believe that everyone did the best job he or she could, given what was known at the time, his or her skills and abilities, the resources available, and the situation at hand.”

I don’t want to comment here the whole article, since it’s a big one (and you should read it) , but I just want to make some points about it (3, to be exact).

Number One

I sincerely believe in the prime directive, and I think that all the persons in the team should also believe in it, and not “pretend” to, as suggested by someone in the article. As Mary Poppendieck pointed (actually Deming and Juran) , when an individual is not performing as expected, most of the times is a systemic problem, and not related to that specific person. Before blaming and pointing fingers, people should look at the system, and try to understand why that person is acting that way. What she said:

“both Deming and Juran observed that when a worker made mistakes, about 80-85% of the time it was due to a problem with the system, not the individual. I have found this to be generally true. It’s not that individuals don’t get tired or sloppy, because they do. But a system that does not ever allow a worker to get tired or sloppy is a bad system.”

Number Two

Here at ThoughtWorks, usually before a retrospective, a safety check is performed. This practice ensures that every member of the team can say anonymously how comfortable he/she feel about to discuss any problem that may arise. If you have a major trust problem in the team, probably that will be shown in the safety check, and then the retrospective should not even start before addressing it.

And if everybody is comfortable talking about anything, then I don’t see why they shouldn’t discuss any specific topic, if that’s affecting the team’s performance and as long as the retrospective doesn’t become a blame game, with criticism and finger pointing. The objective should always to improve the team’s result. As pointed before, probably if someone is acting in a way that isn’t positive for the team, probably that someone has his/her reasons, and could benefit from hearing that he/she is affecting the team’s result.

Number Three

But if you believe that some member of the team is deliberately acting against the team’s objectives, with intention of sabotaging the result in some way, then your problem isn’t really the prime directive. The problem is in reality much bigger, and I don’t think the retrospective will help you to solve it.

Cheers.

“Tell me how you’ll measure me…”

Reading some posts on the web, I’ve found this one, written by Liz Keogh, which talks about perverse incentives, i.e. , situations when an incentive is given to reach some goal, but instead of helping, it works against the objectives of the people who proposed the incentive.

I agree with all Liz has said on the post, and while reading the post, I couldn’t help but thinking about something that was written in The Goal, a book I’ve read a while ago:

“Tell me how [and when] you’ll measure me, and I’ll tell you how I’ll behave”

I think this sentence says it all. People should be very careful when proposing ways to measure and (especially) evaluate persons. What they don’t realize is that the metric that is used will define how the persons will behave when trying to perform their jobs.

If you measure tests written, you’ll have lots of tests , if you measure number of bugs found, guess what you’ll have?

So what I should measure? How should I rate my employees? Well, that’s easy. The only metric you should use is the ultimate goal of your company or team, as broad as it can be. And that’s one of the reasons why I believe agile projects work, because the main metric that is always used, is the business value delivered to the client (ultimate goal, remember?).

I’m not saying that people can not use all kinds of metrics, like code coverage or any other, to develop software. I’m just trying to explain that all the other metrics, besides the goal of the project, have to be used as secondary way to see if the project is going fine. There is no benefit in having a 100% tested code, if you can not deliver any business value to the customer. What is he paying for?

So, as a last thought, when you are thinking about incentives, think with care, and make sure the incentives you are giving aren’t going to be perverse!