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.

Focus on the Right Point

This post came from a pub discussion with Liz, and actually originated from this thought I’ve been having for some time, an came back in one of my recent readings (not to say also in one of my recent projects)…

I participate in some agile mailing lists, and one question that frequently happens is what I should do about people not showing up/showing up late for the stand-ups in the morning. And normally this comes with statements like: “I’ve tried it all already: waiting, not waiting, punishing late arrivers, making them buy ice cream, etc… and nothing works”

And this situation came again to me mind while reading Ricardo Semler‘s book, Voce Esta Louco! (not published in english so far, but it means You Are Crazy!), when he describes how flexible time was introduced in his company.

To give some context, Ricardo runs Semco, a brazilian company which has business units in a lot of different areas, from shipbuilding to hotel management, but is best known for the industrial democracy that its owner has been implementing since the 80′s.

This particular situation he describes occurred when Semco, in the 80′s, was going to allow production line employees to have flexible work hours, and as expected, most of the top managers were totally against the idea, since it violated a basic principle: for a production line to work, everybody has to be there at the same time.

And ricardo’s answer for that was (free translation):

It’s obvious: if the employees are not working at the same time, the production line stops. We know it, but the adults that work in the production line also know it. And why would they put their productivity and their jobs at risk? If they are not worried about how the production line is, producing or not, then we have a much bigger problem, and the sooner we know it, the better.

And that’s what happened, one day before the program started, the employees gathered and decided what time they would start to work.

But what does this have to do with daily standups? Well, the whole example was to indtroduce the same answer I always give to these questions: if your team doesn’t show up for the standups, you shouldn’t worry about why they are late, but ask yourself why they don’t care. That’s your problem.

Agile vs. Usability?

Thre’s been a recent discussion around how agile methods face usability, mainly following Jakob Nielsen’s post about how agile, if poorly executed (that’s my opinion), can be a threat to usable software.

I don’t want to say again what was already said, and I believe that agile and usability can be a good match, as long as you know what you’re doing, but what sometimes bothers me is the common thinking around agile methodologies, that usability = what the client wants. I’ll explain.

In most of the agile projects I’ve been (not to say all of them : ) ), whenever there is some issue around how to make some feature in terms of usability, like “how should be the user experience around this operation”, the common answer is: “let’s ask the client..”.

Well guess what? The client never thought about usability in his life. Of course he used computers already, but he probably doesn’t know how to better develop an application to make it more usable. And this situation gets even worst when the client is just a proxy to the real user, who will probably not even work in the application being developed.

To give a pratical example,  if you asked a bunch of people how they would like to search for web pages in the pre-Google era, how many do you think would answer a “blank page with a text field on it”?

If this ask-the-client behaviour comes from pure lazyness or some cover-your-behind strategy, that’s another discussion, but what I think most agile teams should change in the way they work is to stop pretending that the client has all the answers, and trust a little bit more in themselves to create solutions.

And my guess is that the clients would also like it, because I don’t believe they want to spend their time answering questions like “which is the best solution for this problem: a select field or radio buttons?”.

And if you really want to trust the client to tell you how to build software, do it in a real HCI fashion, observing real users using your application and getting your answers from there.

Cheers,

Francisco.

Lean Workshop at Agiles 2008

Last October me and Danilo were in Buenos Aires, Argentina, to present a Lean Workshop at Agiles 2008.

The idea came from our perception that despite being one of the main buzzwords in the agile community, Lean and its origins are still a mistery to a lot of people, specially now in the current tool age , where kanban means a card wall with some numbers on it.

The workshop aimed at introducing Lean concepts through a hands-on activity, where the participants had to build a simple lego house in this 4 step process.

• Step 1: “Buy” the Lego(TM) pieces and sort them by color
• Step 2: Sort them again by size
• Step 3: Separate the pieces required to build one house
• Step 4: Build the house and sell it

If you are wondering how that turned out in practice, you can check the video here.

In order to go through all the Lean main concepts, the activity was divided in three phases, being the process executed differently in each one: a push system in the first, pull in the second and a single person workcell in the last.

Before every phase, we introduced the concepts that were going to be applied, and after the production, a “retrospective” was held to discuss good and bad points of the process according to the participants.

This way, we could stop and explain the needed concepts between each phase, and were able to go through push vs. pull systems, waste, kanban, kaizen, and work cells, among others.

The feedback we got was very good. All the participants we spoke to later said it was easier to understand what we were talking about when they actually implemented the ideas in practice, and felt the problems that each solution had.  What also helped is that most of the participants we’re being introduced to Lean, and this was the exact kind of public we had in mind when we prepared the workshop.

After the activity, a link with software development was made, but always making clear that creating software is not producing cars, so it is much more important to understand the principles then to apply the practices.

Cheers,

Francisco

Change!

Last week I’ve attended to the Rails Summit, first rails conference to be realized in Latin America (btw, excellent event ), and one thing that attracted my attention was what Chad Fowler mentioned in his presentation (sorry Chad, if the words aren’t exactly the same):

Real experience is equal to change. For most persons, 9 years of experience mean 9 years doing things the same way, but experience should only count if you are continually improving the way you work.

This got my attention since I frequently see people trying to use agile methods as pre-made recipes, which you can apply without thinking, as in “my team uses Scrum, or XP, or FDD, etc..”.

It won’t be the first time I say this to someone, but the Agile Manifesto states:

We are uncovering better ways of developing software by doing it and helping others do it.

So nobody should be afraid of changing the way he/she creates software, or adapting the agile practices to his/her context. The best way to develop software is the one that works for you. Change!

Cheers,

Francisco

We Need Standards

Have you ever read a project codebase (yours or not yours) where you could find different ways of implementing the same thing? Different ways of implementing controllers, of writing tests. Don’t you think that is really bad?

If you answered yes to all the questions, I can say: me too

Recently I’ve worked in this codebase that has evolved trough time having different kinds of implementation for most of its basic components: different templates, different tests, different controllers, mainly because each developer had its better way, and no one bothered to synchronize with each other.

The result is that every time you open a specific file, you are not sure what to expect. And I had worked on it!
I wonder how someone that had never seen the code would react..

When looking back in the way we developed it, I kept thinking in how it would be much better if our team could develop code as one person would, having the same way of constructing the same things, having… standards.

But standards? How about innovation? We’ll just keep doing the same s£%^ code for years this way.. I know what you might be thinking, I had the same thoughts in the first time.

But there is where I think we can also learn from Toyota. They have standards, but they can change at any time, and I believe this could be easily applied to software projects.
Just because all the team decides how to build something, it doesn’t mean that they have to do it during all the project. Agile should be evolutionary, so the current standards should be always challenged. We only have to make sure that at any given moment, everybody should know the ways we write code.

And if I’ve found some case where the way we write controller’s tests doesn’t work, I can change it, and make sure that everybody knows what I’m doing. And to do this I might need just two simple tools: communication and (maybe) a simple wiki, where the team can write the standards being used.

And how about the benefits?

Well, having coding standards, the knowledge transmission among the team will be much better, since everybody will be forced to communicate and discuss why we are doing things this way. As a secondary benefit , you’ll develop code that is much more compreensible, manteainable and well documented.

Cheers,
Francisco

South American Tour

To the brazilian and south-american audience, and also to whoever might be around there in October, I’m participating in two very interesting agile events that are happening in this month.

The first one will be “Talking About Agile” (Falando em Agile), which happens in the 23rd and 24th of October, where I and Danilo Sato, also from ThoughtWorks, will be speaking about problems with agile adoption in real world projects.

We will also be presenting in Agiles 2008, which will take place in Buenos Aires, Argentina, and will have a keynote with Mary Poppendieck, as many other great speakers. In this conference we will present the Lego Lean Game, introducing Lean concepts in a hands-on experience.

Cheers,

Francisco

What’s your Value?

Recently I have been participating in many discussions around the topic of salary transparency. And since the debate has gone online, I felt that this was the right moment to put my thoughts in a post.

To start the conversation, and make things easy to understand, I am in favour of salary transparency, and here are the reasons why. To follow the hype, I’ll also try to describe it as agile user stories…

As an employee, I want to know my colleagues salaries, so that…

I know that the company pays its employees (and consequently me) fairly, and also that I’m not receiving less than others in the same position as mine because of political decisions. And despite a common argument against salary transparency, its not enough to know my salary, or the market average to have this information. Salary is relative in my opinion, and the whole idea of having a fair salary falls apart if someone in the same conditions as me receives much more than I do.

I have a clear idea of a career path inside my company, based on more senior employees revenue, and know what are the possibilities I have if I succeed in getting a better position.

But by far the principal benefit is that I know the value that I have to the company. And this information is the most important to make me feel part of an organization or not. If I don’t know how my salary is in comparison to others, I will be always guessing how much the company I work for values me.

And this is what most people discuss about. But I want to bring another point of view to this discussion, and that is

As a company, I want my employees to know everyone’s salaries, so that…

The revenue gap between the higher and lower positions inside the company gets narrowed, and this will naturally happen when salaries are disclosed, since all high salaries will start to be questioned.

I can have easier salary negotiations with my employees, and this situation will also naturally happen, since nobody will ask for huge raises when they know that this will be seen by everyone in the company. And if they ask, it is simple to explain why they cannot get it.

But again, by far, the most important point is that I want my employees to feel like the company belongs to them, and the only way of doing that is being as transparent as I a can.

As cited in this New York Times article about salary transparency, most people carry a mental image of where they stand in relation to their fellow workers and significantly that image is likely to be wrong. Besides that, most employees believe that the company they work for is much more profitable than it is in reality.

This way, I want to give my employees all the information I can so they can see that their salaries are fair, and don’t feel cheated by the company. As Ricardo Semler wrote in his book Maverick, a company that doesn’t share information when times are good loses the right to request solidarity and concessions when they are not.

And since I’ve been in many discussions around this topic, I’d like also to talk about some of the common arguments against salary transparency that I’ve heard so far.

“The employee’s privacy should be respected…”

I agree, and I don’t think that salaries should be posted in the internet or that salary disclosure should be mandatory. I just want companies to foster an environment where salaries are discussed, and persons who want can publish their salaries and also ask and question other people’s salaries without this being a taboo. And after you have some salaries open, it is easy to have an idea about pay levels accross the company, and also to start questioning why some persons don’t want to talk about their salaries… : )

“Work conditions are not based only on the salary…”

That is also true, and also not a reason to keep salaries secret. Employees are adults, and so they are able to understand that the work environment and other benefits are also important when choosing a job, and part of the “value” that they have to the company. And if in the end they still don’t feel valuated, maybe it’s better for both parts to end the relationship.

“Knowing all the salaries is a burden, because you start to evaluate persons based on how much they make…”

This is another one from the series “my employees are 10 years old”. If someone doesn’t want to know how much others make, he/she will just not read the document or not ask questions. But I believe that most employees are mature enough to understand that performances are not linear functions. And persons should be evaluated, in my opinion, by how much they make. Not just, but also by that. If someone performs the same job as me, and provides the same results, why should he earn more than I do?

Well, I wanted to say more, but this post is already too long. Now the debate continues.

What is your opinion?

Cheers,

Francisco.

What is Lean? And Agile?

In my recent readings about Lean, I’ve found a very informative table, which tried to clarify the myths around what is and what is not Lean, and contained the following information:

Myth – What TPS is Not

• A tangible recipe for success
• A management project or program
• A set of tools for implementation

Reality – What TPS is

• A consistent way of thinking
• A total management philosophy
• An evironment of teamwork and improvement
• A never-ending search for a better way

Despite Lean not being a set of tools, all we see in the IT industry about it is a lot of … tools. Cycle-time, kanban, flow, pull systems, you name it and someone has already announced it as the latest solution to software projects.

I’m not saying that this tools won’t help us developing sotware, but we will sure miss a lot from what Lean has to teach us if we don’t start thinking about principles, i.e., the second part of that list, the philosophy and the thinking.

And if you start to think about Lean principles, you’ll see that they don’t differ much from the Agile ones (at least what I think about Agile ). If you read about an environment of teamwork and improvement, can you tell if they are talking about Lean or Agile?

But again most people, when thinking about Agile, think about practices and not principles. Instead of being collaboration and communication, Agile for them is pair programming, iterations and retrospectives. And this is where I think the solution is. Stop thinking about what is the next set of tools that will make us better, and start thinking about which are the principles we are following and how to better apply them.

About Retrospectives and Accepting Criticism

I believe the most important point in any agile methodology is the possibility of improvement that is offered to the team through constant feedback and also practices like retrospectives.

However, I notice that sometimes teams are not used to question their own behavior, and make the same mistakes over and over again. This was also brought to my attention in one of the mailing lists I participate, where was questioned if teams do enough continual improvement.

These days, while reading the Toyota Way, I got some better understanding about it . According to the author:

Teamwork never overshadows individual accountability at Toyota. Individual accountability is not about blame and punishment, but about learning and growing.

And more important, in the words of Andy Lund, who is a program manager at Toyota and grew up in Japan:

People who have not been to Japan may not understand that the objective is not to hurt that individual but to help that individual improve – not to hurt the program but to show flaws to improve the next program. If you understand that deeply, you can get through that constructive criticism. No matter how good a program or a presentation someone makes, we believe there is always something that can be improved, so we feel it is our obligation. It is not an “obligatory negative”, but an obligatory opportunity to improve–it is the heart of kaizen

And that is exactly what happens in practice. People interpret suggestion and observations as negative criticism, and don’t see that the only way for a team to continually improve is to continually question its own behavior and face its weakest points.

Cheers.