What’s your Value?

September 9th, 2008 by franktrindade 4 comments »

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.

4 comments »

Posted in Management

Tags:

What is Lean? And Agile?

August 25th, 2008 by franktrindade 2 comments »

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.

2 comments »

Posted in Agile, Lean, Management

Tags:

About Retrospectives and Accepting Criticism

August 18th, 2008 by franktrindade No comments »

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.

No comments »

Posted in Agile, Lean, Management

Tags:

Student Syndrome

July 27th, 2008 by franktrindade 6 comments »

One of the good concepts I’ve found while reading Goldratt’s books was the Student Syndrome, which Wikipedia defines like this:

Phenomenon that many people will start to fully apply themselves to a task just at the last possible moment before a deadline. This leads to wasting any buffers built into individual task duration estimates.

During the recent discussions about estimations, which happened in many posts, Chris Leishman wrote about the 3 reasons (P’s) for estimation (which are extremely correct, in my opinion), and selected performance as one of them. As Chris wrote:

The throughput (velocity) of a team is determined by the amount of ‘work’ being done over a given time-period and is measured in terms of the estimate.

After reading this post, I realized that measuring only delivered story points in an iteration (one thing I always thought was right), might not be enough to enable the full capacity of a team.

Explaining, story points are used as de facto standard in agile projects because they provide the separation between time and effort. This way, when I estimate a story as a developer, I have no time commitment to implement that story, and therefore cannot be blamed if I take more/less time than expected (what is probable, since estimation is just an educated guess).

While this practice is good because protects the developer from bad managers, at the same time it provides a lot of room for the occurrence of the Student Syndrome, since nobody knows if the story was completed in the predicted time or not, and all the buffers that were mentally created by the developers during estimation get lost in non necessary activities, like gold plating, for example.

And what I have been noticing in projects, is that stories that get played at the beginning of an iteration generally receive a lot more attention (necessary or not) that the ones that are being done close to the iteration’s end, which proves the concept that more work could be done, if we had some intra iteration kind of measure.

Despite being against the addition of any unnecessary metric to a project, I’m starting to believe that something should be done in this case, like reestimate stories in hours, or measuring cycle time instead of story points, or any other kind of practice that brings awareness to the difference between our estimations and what is actually happening in a story level.

Cheers.

6 comments »

Posted in Agile, Estimation, Management

Tags:

Uncertainty

May 20th, 2008 by franktrindade 5 comments »

Project Uncertainty PrincipleThis 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

5 comments »

Posted in Agile, Management, Uncategorized

Tags:

Velocity, Capacity and Productivity

May 13th, 2008 by franktrindade 2 comments »

This topic comes from some discussions that went on in a mailing list I participate, and also between me and my flatmate, about how productivity should be measured in agile projects, and how is it related to capacity.

I wanted to write this post for some time right now, but today I’ve realized that somebody had already written about it, so I decided to give my opinion too :-).

I totally agree with Simon when he says that velocity is not productivity. As I mentioned in another post, one should be very careful when applying any measure, specially productivity measures, and capacity isn’t one of them, in my opinion.

One simple example that makes me reach this conclusion is bug fixing. If you consider capacity = productivity, how should you count bug fixing stories? They are certainly not adding business value, they are actually delivering business value that was supposedly already delivered, but you can’t deny that the team spent time fixing bugs, and that these points should be considered in the estimation and also in the team’s velocity.

Simon also wrote about how to measure productivity, or even better, how to say if a team is performing well. In his post, he wrote

I prefer to measure productivity in terms of the goal and getting stories done is not the goal, generating revenue is. Getting stories done is the means to achieve the goal.
…

Productivity is perhaps better represented by the revenue generated per iteration per unit of story estimation, e.g. £10,000 per ideal pair day.

This topic was also covered by Martin Fowler in this post. As Martin said,

So maybe you can’t measure the productivity of a team until a few years after a release of the software they were building.

Despite understanding what both says, I find kind of difficult to specify the performance of a software development team if you link it to the revenue generated by the project. I agree that in order to obtain the best results, the considered system should be as broader as it can be (as Deming proposed).

But I also believe (along with Goldratt) that a team has to have a goal, and this goal should be very carefully considered, since it will drive all team’s actions when they are developing software. Including the client’s business in this equation makes it too complicated, since you don’t have any control in how the client is using your work to generate revenue, and as Martin said, it could take years in order to obtain a good result.

If a team doesn’t have a goal, how could it pursue its objectives? Which are the objectives? If agile is about constant and rapid feedback, should I receive feedback based on which criteria? What should the team try to improve when performing retrospectives?

In my opinion, if you have a client that is specifying which stories are more important to the project, and that is why it is really important to bring the client inside the project, at this moment should the measure end, on stories accepted, which will deliver business value (but might not, if for some business reason the software isn’t used anymore, for example).

Until this point a team has the conditions to change and adapt itself to get better results, and deliver more business value. After it, not anymore.

Cheers.

2 comments »

Posted in Agile, Management

Tags:

Quality of Life? Does it Exist?

April 23rd, 2008 by franktrindade 3 comments »

Today I just want to write about some thoughts that came to my head after reading the InfoQ article about Scrum adoption in China.

The article itself is very interesting, since it shows the benefits (and also problems) that companies have had when adopting Scrum. But what triggered this post was the chart shown below, provided by one of the interviewed companies, when they were asked What’s the benefit that Scrum brought to your project, your company?

What this chart shows is that Scrum improved the quality of worklife of most members of the team. And I am writing about it because I think this is one of the aspects of agile methodologies that isn’t perceived as much as it should.

When you work with agile, instead of working alone, you work in pairs, instead of holding all the problems by yourself, you share it and discuss it, instead of working as an individual, you are part of a team.

And that makes all the diference from when you work in non-agile environments, sit alone in your cubicule and interact only with your computer during all day. That makes a diference in your life.

So, if you don’t want to try agile because of the productivity aspect, at least try it for the sanity of the persons working for you.

3 comments »

Posted in Agile, Management

Tags:

Don’t Blame The Prime Directive

April 10th, 2008 by franktrindade No comments »

Don\'t make your retrospectives look like this...

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.

No comments »

Posted in Uncategorized

Software (Engineering or Development?)

April 6th, 2008 by franktrindade 1 comment »

One thing that always interests me about software is the eternal discussion, that has been going for some years now, about the relationship between software development and other engineering disciplines.

On one side stand the traditional approach folks, claiming that software projects are the same as any other engineering projects, and because of that, should be managed as other engineering projects (the favorite one is civil engineering, with house building…)

On the other, the agile practitioners don’t accept software development to be called “engineering”, and say that this is probably one of the reasons software development is in this situation nowadays (not a good one, as you may conclude).

So, what is the right answer? In my opinion, both! To the explanation…

Martin Fowler wrote something about it in this article (everybody knows which side he is in :-) ), where he explains why the traditional civil engineering approach can not work in software development. Quoting one of his sentences

Can you get a design that is capable of turning the coding into a predictable construction activity? And if so, is cost of doing this sufficiently small to make this approach worthwhile?

And I totally agree with him. If you look at UML models and other software design methodologies, there is no way to design a software in such detail so that the construction phase could be a less skilled activity, with predictable results. All you get in projects with long design phase is a lot of rework in the construction phase.

Ok, so software is not civil engineering, but is it not engineering at all? That’s what got clearer after reading the appendix F of the Rogers Commission Report, written by Richard Feynman, which investigated the Challenger Space Shuttle disaster, in 1986.

Now, if you are still paying attention, you should be asking: “What space shuttles have to do with software?”

Simple, it’s engineering. And not just that, it is high technology engineering.

Take a look at what Dr. Feynman said in his report about the space shuttle main engine (quoted from this other blog, where I’ve found all the material):

The Space Shuttle Main Engine was handled in a different manner, top down, we might say. The engine was designed and put together all at once with relatively little detailed preliminary study of the material and components. Then when troubles are found in the bearings, turbine blades, coolant pipes, etc., it is more expensive and difficult to discover the causes and make changes.

Anything rings a bell? How about that?

The usual way that such engines are designed (for military or civilian aircraft) may be called the component system, or bottom-up design. First it is necessary to thoroughly understand the properties and limitations of the materials to be used (for turbine blades, for example), …

With this knowledge larger component parts (such as bearings) are designed and tested individually. As deficiencies and design errors are noted they are corrected and verified with further testing. Since one tests only parts at a time these tests and modifications are not overly expensive. Finally one works up to the final design of the entire engine, to the necessary specifications. There is a good chance, by this time that the engine will generally succeed, or that any failures are easily isolated and analyzed because the failure modes, limitations of materials, etc., are so well understood.

Well, I don’t know what are you thinking, but when I read that, it seemed to me that somebody was talking about iterative software development. And that’s the whole point about it, software development can be compared to an engineering discipline, but to an advanced engineering discipline.

If you try to compare developing software to building houses, you try to compare 2000 years of experience to something we started to do in the last century. But even in software, if you go to well known domains, with well known technologies (not easy to find projects like that… :-) ), you can probably automate the process with different tools, making it a “less skilled task” and also a lot easier.

But in the great majority of projects, developing software is still about messing with recent discovered technologies and changing domains, and that what makes it so hard.

So, just to make a final point, software development is rocket science!

Cheers!

1 comment »

Posted in Agile, Development

Tags:

“Tell me how you’ll measure me…” (2)

April 1st, 2008 by franktrindade No comments »

Coincidence or not, after writing the last post, I’ve just received the InfoQ newsletter, which contains this article, about bonus distribution within agile teams. And what does it have to do with measures and incentives?

Well, if you want to have some great individuals, reward them based on individual performance, if you want a great team, don’t try to establish some weird criteria, and measure everyone’s performance based on the team result.

Like Mary Poppendieck cited on her book, distribution of bonus to an Agile team is like playing with dynamite.

No comments »

Posted in Agile, Lean, Management

Tags: