Quality of Life? Does it Exist?

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.

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.

Software (Engineering or Development?)

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!

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

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.

“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!

Good News!

Enough of this developer non sense! Here is the solution:

Introducing Mingle Proj-o-matic

Regards.

The Turning Point

As you may have noticed, with the language change (from portuguese to english), I decided to also change the blog’s name, since the previous one wasn’t saying very much.

The new name is based on the book I’m currently reading (and recommend), The Turning Point, by Fritjof Capra, which can be described like this (from Wikipedia):

It begins by outlining and tracing the history of science and economics, highlighting the flaws in the Cartesian, Newtonian, and reductionist paradigms. It narrates how such viewpoints have grown inadequate for modern technology and ecology needs, then argues that science needs to develop the concepts and insights of holism and systems theory to solve society’s complex problems.

Just to show you why I am really enjoying this book, here goes a sentence extracted from it (it has been already posted before, but it was in Portuguese, so I thought about translating it… free translation from the portuguese version):

“The complexity of our technological and industrial systems has now reached a point where many of these systems can not be modeled or managed. Failures and accidents occur with increasing frequency, unexpected social and environmental costs are continually generated, and more time is consumed maintaining and regulating the system than providing useful goods and services.” – Fritjof Capra – The Turning Point

Despite being from 1984, I think this specific sentence could be used to describe the vast majority of software development projects now in 2008 (just 24 years later), and that’s why I’ve chosen this blog’s title. Because I believe that the software development industry is reaching its turning point, the paradigm is changing (not as fast as we want, that’s true), and this blog is meant to be just another forum to discuss the new ideas being proposed (and also the old ones, when they are better than the new.. ).

Well, that’s it. Hope you enjoy!

Cheers.