Chess -

Archivos de Categoría: English

Agile 101: Broken Windows Theory

In the late 1960s, a university professor carried out a psychological experiment. He left two identical cars in two different neighbourhoods. One in a poor, high-crime neighbourhood in the Bronx, New York. The other one in a rich, quiet area of Palo Alto, California. Shortly after it was abandoned, the car in the Bronx started to have all its parts stolen. First the radio, then the tires, the mirrors, and anything of value. Yet the car abandoned in California remained undamaged. The study did not end there. When the car in the rich neighbourhood had been intact for a week, the researchers broke one of its windows. This escalated quickly, and soon afterwards the effect was the same as it had been in the Bronx. Theft and vandalism swiftly reduced the car to its bare bones in both neighbourhoods. A car with broken windows sends out a message of disrepair and negligence. It spreads the notion that anything goes. Every new act of vandalism reinforced and broadcast the idea that nobody was taking care of that car. That nobody cared.

A similar idea can be seen in the training of health professionals. If a patient or an elderly person has a stain, or gets dirty somehow, that person should be cleaned. Even if it’s only a little spot. If patients stay in that state, they will be less careful themselves in keeping clean. They will tend to feel that it doesn’t matter anymore, it’s already dirty. So their general state of hygiene, self-esteem, and thus health level will start to decline.

The results of this psychological study are applicable in many situations of our daily lives: from the care of our home to the maintenance of our car. But they’re also applicable to our jobs. For example, if you’re a programmer or a project manager, and you allow for a new version to be deployed. But you haven’t had it sufficiently tested. Or if you leave that technical “debt” unpaid in the code now —because “we’re in a hurry.” You’d be broadcasting to the whole team the feeling that anything goes. That “it’s enough as it is” and that one can leave quality aside. Sooner or later the phone will ring with complaints from users. Soon we will see a lengthy queue of reported bugs in our queue.

When we apply this theory to software, it’s helpful to explain the term entropy. In physics, entropy is the level of disorder or randomness in a system. Say you see badly indented or commented code. Or a bad choice when naming a variable or some bad design. Fix it as soon as possible or schedule its correction for the near future. Take some sort of action to limit disorder or it will expand. It will create the feeling that any patch or quick fix is valid.

If some code (or thrown-together code) will make your system deteriorate quickly, impeccably written and designed software will have the opposite effect. It will make new programmers avoid breaking something so beautifully built. They will make an effort to put in place the best code they can write. Now you know: make your life and your project easier by fixing broken windows as soon as they appear.

You can find texts like this and many other about how to manage agile projects in my book Agile 101: Practical Project Management (available on Amazon).

Book on Scrum: Agile 101, Practical Project Management
Agile 101 – Practical Project Management

Translation by Begoña Martínez. You can also find her on her LinkedIn profile. Proofreading by David Nesbitt.

From Agile 101: The role of product owner

Are you sure you need a Clippy-like assistant on your app?

Many titles could be used for the person who acts as Project Director on the client’s side: the person with the product vision that the company needs, the one that represents the company in the work team. If that person belongs to the external organisation that has ordered the work, the title which fits best might be Product Owner, like in Scrum. That’s because that person literally owns it, is the “Owner” of what will be built. If this person belongs to our own organisation—someone who will represent the “client” in the project—the title normally used is Project Manager or even Business Analyst, depending on the company doing the hiring and naming. Personally, maybe because of the type of projects that I normally manage, I’m more comfortable using the title Project Director.

Whatever we decide to call these people, their contribution to a project is key to its success. They decide which features the project will have, which ones are indispensable and which ones are not. Maybe they will be the users of the final project, and thus will have a very clear idea of which elements would be key to create a useful tool that they use daily at work. However, its usefulness shouldn’t be limited to just themselves or their department, but rather it should also take into account the requirements of the whole company.

When we start a new project, the Project Director on the client’s side and the users of the final product have lots of ideas and great expectations about the new system. Sadly, no project, no matter how big it is, accommodate each and every suggestion from its users. Some ideas would be irrelevant for most users, other features might be too expensive to implement, or they would take so long to build that the project would be delayed for too long before being delivered. It’s here where the Project Director on the client’s side, who knows the market well and has a clear vision of the product, will have to prioritise the most important features and discard those that provide less value to the final product.

To explain how far-reaching the responsibilities of Project Directors are, let’s imagine the following. Our company decides to contract the development of a new airline ticketing system. In the company, they have decided that Elena will be the Product Owner or Project Director, and she will have to transmit to the chosen company all the requirements and needs that the new system must deal with.

Elena has a very clear vision of what she wants and is extremely enthusiastic about the project. So are the IT, marketing, and sales department heads, who have prepared an exhaustive list of features that the new product should include. Even in informal conversations, every day the future users of the system make new feature requests. Elena doesn’t want to miss anything important and conscientiously writes down all these requirements in a notebook.

Two months later, Elena realises that the team carrying out the work in the development company is delivering from 4 to 6 new features every week, and this seems to be their maximum capacity. She is happy with the work they are doing, but she has a problem: in her notebook she gets about 10 new feature requests every week. The list is growing and soon she will need a new notebook.

First of all, she asks the work team to double their efforts and deliver 10 features a week. Unfortunately, not many more features are delivered, and worse yet, she can tell that the quality of those features has gone down. On occasion, they even have to stop everything and correct previous deliveries. If things go on like this, frustration and stress will take over the project.

From now on, Elena must decide what should and shouldn’t be done. Not every feature will be included: at least not now. Some will have to wait for future versions. And of course, the idea of including a Clippy-style assistant to the purchase process for flight tickets will get a clear “NO.”

But, which features should she have developed first? Which criteria should she apply? Elena realises that there isn’t a direct relationship between feature cost and value added to the final project. Some features are easy to build, but some others take a very long time to develop while not actually providing a lot of value to the final product. If she asks the work team directly how many days each of those features would take, she will know what was the approximate cost would be. If she asks the users to score importance of each feature from 1 to 5, she will be able to calculate the value for her company.

If there are two features that have the same approximate cost, but one has value 1 and another one has value 3, they will clearly add the second one. If there are two features with approximately the same value for the company, but the first one would be ready in 5 days while the second one would be ready in a few hours, it’s also quite clear which one they should work on first.

Elena knows that the value and cost of each feature aren’t absolute values, but just approximations. We don’t know how much an apple weighs, but we know it’s about 5 times bigger than a strawberry and that people like the strawberry more (at least, the people who will pay for it like it more), so the strawberry would be built first. It’s an easy way to decide what provides more value, faster, to our project.

Communication is one of Elena’s main responsibilities. She must be in contact with the work team, but also with the people in her company who have something to say about the product that is being built. She has to be able to say “no” when necessary: she has to be practical in this sense, making this decision swiftly and directly. And also, she should know her business inside out, to make sure that everything that gets built will actually provide value to the company. I would say that Elena has quite a lot on her plate, don’t you think?

You can find texts like this and many other about how to manage agile projects in my book Agile 101: Practical Project Management (available on Amazon).

Translation by Begoña Martínez. You can also find her on her LinkedIn profile. Proofreading by David Nesbitt.

Oracle XE, Forms 6i and a trip to Ecuador

Quite some time ago I had to deploy an application developed with Oracle Developer 6i (also known as Forms & Reports). Another public institution bestowed upon our customer, a museum, a system that would help them to catalogue, inventory and keep track of their works of art loans.

To avoid costs of licencing, as their data volume wasn’t high at all, we decided to use, as database, the free Oracle Express Edition 10g license. The cataloguing system provided required an Oracle database as storage.

But, as soon as we double clic the application icon on screen, a Windows console was opened and closed in a blink of an eye. No log, no error messages, nothing.

We thought a lot about this, we queried Oracle Metalink, web pages and forums on Oracle development but no clues at all.

Ultimately, after many Google searches, we found the solution to our problem at the Oracle Users Group of Ecuador, precisely in a Paola Pullas’s post and the comments which followed.

It seems that a patch needs to be applied to Oracle XE 10g to make it work with Developer 6i. Besides that, it was needed to set the database character UTF8, that way you could make it work with tilda and accents. So here are the steps we had to follow:

First of all, we had to ask our DBA to connect to the XE database as SYSDBA and to execute these commands to change the character set:


After that we had to apply in our Oracle Developer installation the following patch: Oracle Developer Patch 18 (number 4948577).

Hope it still helps someone. Sure there are many people out there that are still maintaining a system like this one.

Blank Totals in Oracle BI Discoverer

Another technical post. This time about how to solve the Blank Totals problem in Oracle Business Intelligence Discoverer:

I worked years ago as an EUL administrator with the Oracle Discoverer tools. We found a problem that troubled us during days: Grand Totals for some columns were empty despite of containing data that should be shown. The info was visible only when there was only one record to be added up but only an empty cell was displayed when there were more than one.

That seemed to us like a glitch or bug in this tool but it came out to be a technical decision of the tool’s designers. Let me explain:

When we got two folders related to each other as master-detail but, at the master’s folder we have got the numeric field that is going to be added up, we will get into trouble as the addition should add the master records numeric fields as many times as detail items are in our database. That’s probably not what we want.

Let’s see an example. If we got a master folder with data from official tourist guides, which includes their fares, like this:

Id.     Name       Salary
1       Pedro        2.000€
2       Juan          1.000€
3       Marta        1.500€

And if, on top of this, we have a detail folder, where we get the list of languages spoken by each tourist guide, it would look like this:

Id.     Name       Salary       Language
1           (Pedro)        2.000€          English
2          (Juan)          1.000€           English
2          (Juan)          1.000€           German
2          (Juan)          1.000€           Swedish
3          (Marta)        1.500€           German
When we create a Summary or a Total, Discoverer will show us that Pedro’s fare is 2.000€, Marta’s 1.500€ but it will display ‘_____’ (blank cell) instead of the Juan’s fare. Whether the tool showed a result, it should be 3.000€, but that is not the real fare for Juan. It is only aggregating three amounts as Juan speaks three languages.

There is a few workarounds to fix this:

  1. Maybe the amount being added should not be at the Detail folder. Should the database design be reviewed?
  2. Check if the relation between master and detail folder is 1 to 1 but it is mistakenly set as 1 to many.
  3. If everything above is right, there is one more thing that you can do: Tell Discoverer that it should add up those amounts anyway. To do so, follow these steps:
    1. Activate the ‘Show the sum of the values displayed in the contributing cells‘ option at the Discoverer Desktop settings.
    2. Set the properties AllowAggregationOverRepeatedValues and AggregationBehavior to 1 instead of 0 at the prefs.txt file that you can find in Discoverer server path $ORACLE_HOMEDiscovererutil.

This latter case should be taken being aware of what that implies. Even if it were a perfectly valid solution for the case you are trying to fix, it could exist another report, now or in future, run at the same patched server, which wouldn’t allow the administrator to see there is a problem (fan trap) and totals or summary fields are displaying wrong amounts as they are being added up two or more times (like the Juan’s fares).

How to make estimates come out the way you want (don’t fool yourself) – From Agile 101 book

Now, let’s hear a quick story about how we fool ourselves when somebody requests a quote for a job. It may have happened to you at some point.

A client has requested a quote. He has an idea in mind and wants to know how much it will cost and how long will it take. He made some calculations in his head and comments briefly on the numbers he is considering.

You arrive to your office and meet with the experts in these types of projects. After mulling it over for quite a bit you agree on how long it will take and the level of difficulty. You’ve had to do a little convincing, so they’re not so overly cautious, because after all it doesn’t look like a difficult project.

However, the final quote reached is way higher than the client had foreseen. Furthermore, if that vision were to be true, the project would not be finished by the deadline . You’ll need to reduce that estimate by at least 50%. Here’s how to do that in 5 easy steps:

You’ve done this before. You’ll be faster this time. You’ve carried out similar projects on other occasions, so you’ve surely learned from your mistakes. Also the problems that came up other times won’t necessarily happen this time (10% less). Are you sure you won’t have some new problems?
The clients said they wanted something simple. It won’t be that hard to do.

We’ll do something basic —we’ll cut on the complex stuff (10% less). The clients know their business well and it’s easy for them, but, what about you? Do you know everything you need to know about their business?

We’ll really keep a eye on costs. Some other projects weren’t monitored very closely, but this time you’ll be especially watchful of every hour spent, and you won’t let costs go through the roof (10% less).

We’ll put our best technicians on it. It’s a major project for an important client. We’ll put our best people on it (10% less, even though you don’t know whether they’ll be available on the date you need them).

We’ll make an extra effort.
If push came to shove, and we saw we were about to miss the deadline, we would ask every stakeholder to make an additional effort for a few weeks. If it’s necessary, we’ll even add some extra technicians halfway through so we can finish on time (10% less). Remember Brooks’ Law: adding extra staff to a project that’s late will only delay it even more.

And there we are. With just a little bit more work, we’ve been able to cut the initial estimate by 50%. Actually, to make the estimate match the budget, we’ve convinced ourselves that we can do the work in half the time. Sad to say, stats show that software projects take an average of 120% more time than initially estimated, and that final costs are normally 100% more than was budgeted at first.

You can find texts like this and many other about how to manage agile projects in my book Agile 101: Practical Project Management (available on Amazon).

Translation by Begoña Martínez. You can also find her on her LinkedIn profile. Proofreading by David Nesbitt.

Esta web utiliza cookies propias y de terceros para su correcto funcionamiento y para fines analíticos. Contiene enlaces a sitios web de terceros con políticas de privacidad ajenas que podrás aceptar o no cuando accedas a ellos. Al hacer clic en el botón Aceptar, acepta el uso de estas tecnologías y el procesamiento de tus datos para estos propósitos. Más información