Paper: Software Development’s Classic Mistakes

Approximately 500 software practitioners were surveyed to determine the frequency and severity of
common software development mistakes. Twenty of the mistakes were found to occur at least half the
time. Most mistakes had either Serious or Moderate-Serious impacts. The most damaging mistakes
included unrealistic expectations, overly optimistic schedules, shortchanged quality assurance, wishful
thinking, confusing estimates with targets, and excessive multi-tasking.
Classic mistakes are mistakes that have been made so often, by so many people, that the consequences of making
these mistakes should be predictable and the mistakes themselves should be avoidable.

Classic Mistake Descriptions:

 Abandonment of planning under pressure:

Projects make plans and then routinely abandon them when they run into schedule trouble. This
would not be a problem if the plans were updated to account for the schedule difficulties. The
problem arises when the plans are abandoned with no substitute, which tends to make the project
slide into code-and-fix mode.

 Adding people to a late project:

When a project is behind, adding people can take more productivity away from existing team
members than it adds through new ones. Adding people to a late project has been likened to
pouring gasoline on a fire.

 Assuming global development has a negligible impact on total effort:

Multi-site development increases communication and coordination effort between sites. The
greater the differences among the sites in terms of time zones, company cultures, and national
cultures, the more the total project effort will increase. Some companies naively assume that
changing from single-site development to multi-site development will have a negligible impact on
effort, but studies have shown that international development will typically increase effort by about
40% compared to single-site development.

 Code-like-hell programming:
Some organizations think that fast, loose, all-as-you-go coding is a route to rapid development. If
the developers are sufficiently motivated, they reason, they can overcome any obstacles. This is far
from the truth. The entrepreneurial model is often a cover for the old code-and-fix paradigm
combined with an ambitious schedule, and that combination al- most never works.

 Confusing estimates with targets:

Some organizations set schedules based purely on the desirability of business targets without also
creating analytically-derived cost or schedule estimates. While target setting is not bad in and of
itself, some organizations actually refer to the target as the ‘estimate,’ which lends it an
unwarranted and misleading authenticity as a foundation for creating plans, schedules, and
commitments.

 Developer gold-plating:
 Developers are fascinated by new technology and are sometimes anxious to try out new capabilities
of their language or environment or to create their own implementation of a slick feature they saw
in another product—whether or not it’s required in their product. The effort required to design,
implement, test, document, and support features that are not required adds cost and lengthens the
schedule.

 Excessive multi-tasking:
When software developers are assigned to more than one project, they must ‘task switch’ as they
change their focus from one project to an- other. They must get out of ‘flow’ on one project and
into ‘flow’ on another. Task switching can be a significant factor—some studies have said that each
task switch in software development can incur a 5-30 minute downtime as a developer works out of
flow on one project and works into flow on the other.

 Feature creep:
The average project experiences about a 25-percent change in requirements over its lifetime. Such
a change produces at least a 25-percentaddition to the software effort and schedule, which is often
unaccounted for in the project’s plans and unacknowledged in the project’s status reports.

 Friction between developers and customers:

Friction between developers and customers can arise in several ways. Customers may feel that
developers are not cooperative when they refuse to sign up for the development schedule that the
customers want or when they fail to deliver on their promises. Developers may feel that customers
are unreasonably insisting on unrealistic schedules or requirements changes after requirements
have been baselined. There might simply be personality conflicts between the two groups. The
primary effect of this friction is poor communication, and the secondary effects of poor
communication include poorly understood requirements, poor user-interface design, and, in the
worst case, customers’ refusing to accept the completed product.

 Heroics
Some project teams place a high emphasis on project heroics, thinking that the certain kinds of
heroics can be beneficial. However, emphasizing heroics in any form usually does more harm than
good. Sometimes there is a higher premium placed on a can-do attitude than on steady and
consistent progress and meaningful progress reporting. By elevating can-do attitudes above
accurate-and-sometimes-gloomy status reporting, such project managers undercut their ability to
take corrective action. They don’t even know they need to take corrective action until the damage
has been done. Can-do attitudes can escalate minor setbacks into true disasters. An emphasis on
heroics can encourage extreme risk taking and discourage cooperation among the many
stakeholders in the software development process.

 Inadequate design:
A special case of shortchanging upstream activities is inadequate design. Rush projects undermine
design by not allocating enough time for it and by creating a pressure-cooker environment that
makes thoughtful consideration of design alternatives difficult. This results in going through several
time-consuming design cycles before the system can be completed.
 Insufficient planning:
Planning can be done well, and planning can be done poorly. But some projects suffer from simply
not doing enough planning at all, i.e., not prioritizing planning as an important activity.

 Insufficient risk management:

Some mistakes have been made often enough to be considered classic mistakes. Other potential
problems need to be identified project-by-project through risk management. The most common
problem with risk management is not doing any risk management at all. The second most common
problem with risk management is not doing enough risk management.

 Lack of automated source-code control:

Failure to use automated source-code control exposes projects to needless risks. Without it, if two
developers are working on the same part of the program, they have to coordinate their work
manually and risk accidentally overwriting someone else’s work. People develop new code to out-
of-date interfaces and then have to redesign their code when they discover that they were using
the wrong version of the interface. Users report defects that you can’t reproduce because you have
no way to recreate the build they were using.

 Lack of effective project sponsorship:

High-level project sponsorship is necessary to support many aspects of effective development

including realistic estimates, adequate resource allocation, and achievable schedules, as well as
helping to clear road blocks once the project is underway. Without an effective project sponsor,
other high-level personnel in your organization can force you to accept unrealistic deadlines or
make changes that undermine your project.

 Lack of stakeholder buy-in:

All of the major players in a software-development effort must buy in to the project. That includes
the executive sponsor, team leader, team members, marketing, end-users, customers, and anyone
else who has a stake in it. The close cooperation that occurs only when you have complete buy-in
from all stakeholders allows for precise coordination of a software development effort that is
impossible to attain without good buy-in.

 Lack of user involvement:

User involvement is necessary for defining meaningful requirements. The degree of user
involvement can affect how quickly or how slowly issues get resolved.

 Letting a team go dark:

On some projects, management allows a team to work with little over- sight and little visibility into
the team’s progress. This is known as “letting a team go dark.” This practice restricts visibility into
project status, and the project doesn’t receive timely warnings of impending schedule slips. Before
you can keep a project on track, you have to be able to tell whether it’s on track, and letting a team
go dark prevents that.

 Noisy, crowded offices:

 About 60 percent of developers report that their work environments are neither sufficiently quiet
nor sufficiently private. For many developers, this can prevent concentration and prevent achieving
a state of ‘flow’ that is helpful in achieving high levels of productivity. Workers who occupy quiet,
private offices tend to perform significantly better than workers who occupy noisy, crowded work
bays or cubicles.

 Omitting necessary tasks from estimates:

If people don’t keep careful records of previous projects, they forget about the less visible tasks,
but those tasks add up. Forgotten activities can add 20 to 30 percent to a development schedule.

 Outsourcing to reduce cost:

Valid reasons to outsource include accessing capabilities that you don’t have in house, diversifying
your labor force, freeing up your in-house staff to focus on mission-critical or core-competency
projects, adding “surge capacity” to your development staff, and supporting around-the-clock
development. Many organizations that have outsourced for these reasons have accomplished their
objectives. However, some organizations outsource primarily to reduce development costs, and
historically those initiatives have not succeeded. Usually outsourcing motivated by cost savings
results in higher costs and longer schedules.

 Overestimated savings from new tools or methods:

Organizations often assume that first-time usage of a new tool or method will reduce costs and
shorten schedules. In reality, first-time use of a new tool or method tends to be subject to a
learning curve, and the safest planning assumption is to assume a short-term increase in cost and
schedule before the benefits of the new tool or method kick in.

 Overly optimistic schedules:

The challenges faced by someone building a three-month application are quite different than the
challenges faced by someone building a one- year application. Setting an overly optimistic schedule
sets a project up for failure by under scoping the project, undermining effective planning, and
abbreviating critical upstream development activities such as requirements analysis and design. It
also puts excessive pressure on developers, which hurts developer morale and productivity.

 Planning to catch up later:

If you are working on a project and it takes you four weeks to meet your first two-week milestone,
what is your status? You are known that you’re behind schedule, but will you stay behind schedule,
or will you catch up later? Project planners commonly plan to catch up later, but they rarely do.
Most projects that get behind schedule stay behind schedule.

 Politics placed over substance:

Larry Constantine reported on four teams that had four different kinds of political orientations.
“Politicians” specialized in “managing up” concentrating on relationships with their managers.
“Researchers” concentrated on scouting out and gathering information. “Isolationists” kept to
themselves, creating project boundaries that they kept closed to non-team members. “Generalists”
did a little bit of everything: they tended their relationships with their managers, performed
research and scouting activities, and coordinated with other teams through the course of their
normal workflow. Constantine reported that initially the political and generalist teams were both
 well regarded by top management. But after a year and a half, the political team was ranked dead
last. Putting politics over results is fatal to software development effectiveness.

 Premature or too frequent convergence:

Shortly before a public software release there is a push to prepare the software for release—
improve the product’s performance, create final documentation, stub out functionality that’s not
going to be ready for the release, perform end-to-end testing including tests that can’t be
automated, test the setup program, and so on. On rush projects, there is a tendency to force
convergence too early. If the software isn’t close enough to a releasable state, the attempted
convergence will fail, and the team will need to attempt to converge again later in the project. The
extra convergence attempts waste time and prolong the schedule.

 Push me, pull me negotiation:

One bizarre negotiating ploy occurs when a manager approves a schedule slip on a project that’s
progressing slower than expected and then adds completely new tasks after the schedule change.
The underlying reason for this is hard to fathom because the manager who approves the schedule
slip is implicitly acknowledging that the schedule was in error. But once the schedule has been
corrected, the same person takes explicit action to make it wrong again.

 Requirements gold-plating:
Requirements gold plating is the addition of requirements or the expansion of requirements
without a clear business justification. Requirements gold plating can be done by end users who
want the “system to end all systems” or it can be done by developers who are sometimes more
interested in complex capabilities than real users are.

 Research-oriented development:
Some projects have goals that push the state of the art—algorithms, speed, memory usage, and so
on. That’s fine, but when those projects also have ambitious cost or schedule goals, the
combination of advancing the state of the art with a tight budget on a short schedule isn’t
achievable.

 Shortchanged quality assurance:

Projects that are in a hurry often cut corners by eliminating design and code reviews, eliminating
test planning, and performing only perfunctory testing. It is common for design reviews and code
reviews to be given short shrift in order to achieve a perceived schedule advantage. This often
results in the project reaching its feature complete milestone but then still being too buggy to
release.

 Shortchanged upstream activities:

Projects sometimes cut out non-coding activities such as requirements, architecture, and design.
Also known as “jumping into coding,” the results of this mistake are predictable. Projects that skimp
on upstream activities typically have to do the same work downstream at anywhere
from 10 to 100 times the cost of doing it earlier.
 Silver-bullet syndrome:
On some projects, there is an over reliance on the advertised benefits of previously unused
technologies, tools, or 3rd party applications and too little information about how well they would
do in the current development environment. When project teams latch onto a single new
methodology or new technology and expect it to solve their cost, schedule, or quality problems,
they are inevitably disappointed.

 Subcontractor failure:
Companies sometimes subcontract pieces of a project when they are too rushed to do the work in-
house. (“Subcontractor” can refer either to an individual or to an outsourcing firm.) But
subcontractors frequently deliver work that’s late, that’s of unacceptably low quality, or that fails to
meet specifications. Risks such as unstable requirements or ill-defined interfaces can be magnified
when you bring a subcontractor into the picture. If the subcontractor relationship isn’t managed
carefully, the use of subcontractors can undermine a project’s goals. (Note: This question deals
specifically with subcontracting part of a project—other items focus on outsourcing full projects.)

 Switching development tools in the middle of a project:

This is an old standby that hardly ever works. Sometimes it can make sense to upgrade
incrementally within the same product line, from version 3 to version 3.1 or sometimes even to
version 4. But the learning curve, rework, and inevitable mistakes made with a totally new tool
usually cancel out any benefit when you’re in the middle of a project.

 Trusting the map more than the terrain:

Project teams sometimes invest more confidence in the plans they create than in the experience
their project is giving them. Sometimes they will trust the delivery date written on a plan more than
the delivery date implied by the project’s track record. If the project reality and the project plans
disagree, the project’s reality is correct, and the plans must be wrong. The longer a project team
trusts the plans rather than the project reality—i.e., trusts the map more than the terrain—the
more
difficulty they will have adapting their course successfully.

 Unclear project vision:

The lack of clearly defined and communicated vision undermines the organization’s ability to make
and execute project-level plans that are consistent with organization-level goals. Without a clear
understanding of the vision, people draw their own conclusions about the purpose of the project
and how it relates to their day-to-day work, and they make decisions that run counter to the
project’s business objectives. The unclear vision contributes to changes in project direction,
including de-
tailed requirements; detailed plans that are misaligned with project priorities; and, ultimately,
inability to meet schedule commitments.

 Uncontrolled problem employees:

Failure to deal with problem personnel (e.g., a prima donna programmer) can threaten
development effectiveness. This is a common problem and has been well-understood at least since
Gerald Weinberg published Psychology of Computer Programming in 1971. Failure to take action to
deal with a problem employee is the most common complain that team members have about their
leaders.
  Undermined motivation:
Study after study has shown that motivation probably has a larger effecton productivity and quality
than any other factor. On some projects, management can undermine morale throughout the
project. Examples include giving a hokey pep talk, going on a long vacation while the team works
through the holidays, and providing bonuses that work out to less than a dollar per overtime hour
at the end.

 Unrealistic expectations:
One of the most common causes of friction between developers and their customers or managers
is unrealistic expectations. Often customers simply start with unrealistic expectations (which is
probably just human nature). Sometimes project managers or developers ask for trouble by getting
project approval based on optimistic estimates. A Standish Group survey listed realistic
expectations as one of the top five factors needed to ensure the success of an in-house business-
software project.

 Wasted time during the fuzzy front end:

The “fuzzy front end” is the time before the project starts, the time normally spent in the approval
and budgeting process. It’s not uncommon for a project to spend months or years in the fuzzy front
end and then to come out of the gates with an aggressive schedule.

 Weak personnel:
After motivation, either the individual capabilities of the team members or their relationship as a
team probably has the greatest influence on productivity. Hiring from the bottom of the barrel can
threaten a development effort. On some projects, personnel selections were made with an eye
toward who could be hired fastest instead of who would get the most work done over the life of
the project. That practice gets the project off to a quick start but doesn’t set it up for successful
completion.

 Wishful thinking:
Wishful thinking isn’t just optimism. It’s closing your eyes and hoping something works when you
have no reasonable basis for thinking it will. Wishful thinking at the beginning of a project leads to
big blowups at the end of a project. It undermines meaningful planning and can be at the root other
problems.”

Paper Standing on Principle:

You may be asked to cut corners on the quality of the work you do or the way you do it. Sometimes, the person
making the request is a manager who doesn't appreciate the value of the quality activities you practice, or someone
who feels budget and schedule pressures you may not. Sometimes, it is a customer who wants you to address only
her specific needs.

Customers and managers alike may press you to skip key engineering steps from time to time. It would be nice to
think we are beyond the stage of "don't bother with those specs, start writing code," but this call of the software
dinosaur still echoes throughout the land.( pero esta llamada del dinosaurio del software todavía resuena por toda la
tierra.)

Sometimes you have no choice: Do what is asked of you, or head out the door. But people working in a quality-
oriented software engineering culture will do their best to follow established and intelligent practices in times of
crisis, as well as in normal times.

An ethical decision, or a choice between doing what is right and doing what you are asked to do, remember this
principle: Never let your boss or your customer talk you into doing a bad job.

Integrity and Intelligence: With Customers:

The customer is not always right; however, the customer always has a point. Don't be blinded by the notion that you
are hearing the "voice of the customer" and therefore must do whatever that voice says. Much of the value that a
systems analyst adds to the application development process comes from looking for solutions that address the true
user needs with creativity, efficiency, and thoughtfulness.

Customers think in terms of what functions they personally will use in the application, not those that should be
included because of their potential value to other users.

So the lesson here is Look beyond the local interests of the primary customers to see whether you can easily
generalize an application to meet a broader need.

Don't let resistance by your customer or your manager inhibit you from making smart strategic decisions.

Occasionally, you may encounter a customer who is a self-styled software engineer and who therefore wishes to
provide a lot of technical input into how you design his application. This is usually a case of someone having just
enough knowledge to be dangerous. The project leader must resist letting such customers become technically
involved in design and implementation (unless, of course, the customer really does know what he's doing). Focus his
energy on the requirements, or get him involved with testing and writing user aids, but do not let the customer drive
the technical aspects of the project. The rule to remember is Make sure you know where the customer's software
expertise stops. Do not allow the customer to intimidate you into making poor design decisions.

Developers must base their relationships with customers on mutual trust and respect.

when customers come to developers with changes in the established requirements baseline, we have to make sure
they understand the impact of the changes they are requesting. New or modified requirements may not look so
attractive once the customers know the cost, in terms of dollars or delivery time, of a late change. By the same
token, if schedules slip as the project progresses, the customers have to be kept informed, even if they don't want to
hear it. (De la misma manera, si los cronogramas fallan a medida que avanza el proyecto, los clientes deben ser
mantenerse informados, incluso si no quieren oírlo.)

Be honest with your customers. The project stakeholders are entitled to accurate information, whether or not it is
good news.( Sea honesto con sus clientes. Los interesados en el proyecto tienen derecho a recibir información veraz,
sean o no buenas noticias.)

If you agree to a commitment, the other people involved expect you to do it. If anything changes, let them know as
soon as you can, so you can work out an alternative.( Si acepta un compromiso, las otras personas involucradas
esperan que lo haga. Si algo cambia, hágales saber tan pronto como pueda, para que pueda hacer ejercicio. una
alternativa.)

Integrity and Intelligence: With Managers:

A colleague was once asked by a manager to estimate the delivery time for a planned large software application. He
replied, "Two years." The manager said, "No, that's too long. How about six months?" My colleague’s response was,
"Okay." Wrong answer!

My colleague simply said what the manager wanted to hear, undermining his own credibility as a software estimator
and project leader. To no one's surprise, the project extended beyond two years. Agreeing to unattainable
commitments is unprofessional and unfair to all involved, including yourself.( Aceptar compromisos inalcanzables es
poco profesional e injusto para todos los involucrados, incluido usted mismo.)

How should this all-too-common situation have been handled? Here are a few approaches to try; there is no
guarantee that any of them will work with unreasonable managers or customers, but try them first before caving in.

1- Explain your estimating method to the manager, and ask on what basis the manager's estimate is smaller.
Historical metrics data can help build your case.

2- Offer to provide a more precise estimate after some initial exploration of the project scope and general user
requirements. Estima y después le decis, no inventes.

3- Present a range of estimates: best case, most likely, and worst case, with the approximate probability of meeting
each one.

4- Negotiate for a larger team, fewer features, phased delivery, or reduced quality as ways to achieve an aggressively
accelerated schedule. Make sure the stakeholders understand these trade-offs: They will not get something for
nothing. ( No obtendrán algo a cambio de nada.)

5- Redo your estimate with some different assumptions of project size, resources, or other factors, to see how close
you can come to the manager's shorter goal. Make sure the assumptions are clearly communicated to everyone
involved in the decision-making.

6- Make a counteroffer, showing the manager what fraction of the system's functionality realistically could be
delivered in six months.

Concealing (ocultar) a project's scope from management is even more irresponsible than agreeing to a schedule you
cannot possibly meet.

The Five Dimensions of a Software Project:

There are five dimensions that must be managed on a software project: features, quality, cost, schedule, and staff(no
solo gente sino recursos).

These dimensions are not all independent. For example, if you add staff, the schedule may be shortened (although
not necessarily) (aunque no necesariamente) que es lo q dice la de ADR de las 9 embarazadas, and the cost may
increase.

The trade-offs (Las compensaciones) among these five dimensions are not simple or linear. For each project, we
need to decide which dimensions are critical and how to balance the others so we can achieve the key project
objectives.

Each of these five dimensions can take one of three roles on any given project: a driver, a constraint(restricción), or a
degree of freedom.

A driver is a key objective of the project. For a product that must ship on time to meet a marketing window of
opportunity, schedule is a driver. Commercial desktop software, such as word processors and spreadsheets, are
often created with features as the driver.

A constraint (restricción) is a limiting factor that is not within the project leader's control. If a team of immutably
fixed size is assigned to a project, staff becomes a constraint. Cost is a constraint on a project being done under a
fixed-price contract, while quality will be a constraint for a project to develop software that runs a piece of medical
equipment or an airplane's flight control system.

Any project dimension that is neither a driver nor a constraint becomes a degree of freedom. (Grado de Libertad).
These are factors that the project leader can adjust and balance to some extent, to achieve the overall project
objectives. For example, on some internal information system projects, the drivers are features and quality, and staff
is a constraint, so the degrees of freedom become schedule and cost. The implication for this profile is that the
features demanded by the customers will all be included, but the delivery time for the product may be later than
desirable.

All five cannot be drivers, and all five cannot be constraints. This negotiation process helps to define the rules and
bounds of the project.

A constraint gives the project leader no flexibility, a driver has low flexibility, and a degree of freedom provides a
wider latitude to balance that dimension against the other four.

A graphical way to depict this is to use a Kiviat diagram.

Si seria restricción estaría en la primera línea o casi al inicio de calidad, pero como es un driver tiene un poquito más
de flexibilidad que la restricción o costrain. Incluso no lo sé, pero si sería constrain capaz estaría en el eje cero la
calidad.

Be sure to document the negotiated goals for driver dimensions, the limits for constraint dimensions, and the range
of values associated with those dimensions that are degrees of freedom.

Another way to apply the five-dimension model is to renegotiate when the world changes. If new requirements
come along that simply must be included in the upcoming release, ask management what you should adjust to
accommodate this request: (Cuando cambia lo acordado)

¿Perjudico alcance? ¿Perjudico tiempo? ¿Perjudico recursos o costos? ¿Perjudico calidad?

Sirve para saber que perjudicar si lo acordado cambia.

To conclude: One characteristic of both a healthy software engineering culture and a mature software development
process is that project expectations and commitments are established through negotiation. To avoid unpleasant
surprises late in a project's life cycle, the stakeholders all have to understand and agree on their objectives and
priorities. Not everyone may be happy with the outcome of the negotiations, but people can commit to realistic
schedules and deliverables only if all the parameters are discussed honestly. Unstated or unrealistic goals will rarely
be achieved.

Paper: TimeBox Development:

Timebox Development is a construction-time practice that helps to infuse a development team with a sense of
urgency and helps to keep the project's focus on the most important features. The Timebox Development practice
produces its schedule savings through redefining the product to fit the schedule rather than redefining the schedule
to fit the project. (Timebox redefine al Proyecto en base al tiempo que hay en lugar de redefinir el cronograma para
que se ajuste al proyecto).

The success of timeboxing depends on using it only on appropriate kinds of projects and on managements and end-
users' willingness to cut features rather than stretch the schedule. ( El éxito del timeboxing depende de usarlo solo
en los tipos apropiados de los proyectos y en la voluntad de la administración y los usuarios finales de cortar
funciones en lugar de que estirar el horario.)

Timebox Development is a means of harnessing the same sense of urgency that accompanies preparing for a
vacation except that it usually accompanies preparing to work hard instead! When you follow the Timebox
Development practice, you specify a maximum amount of time that you will spend constructing a software system.
You can develop as much as you want or whatever kind of system you want, but you have to constrain that
development to a fixed amount of time. This sense of urgency produces several results that support rapid
development.

It emphasizes the priority of the schedule. By making the schedule absolutely fixed, you stress that the schedule is
of utmost importance. The time limit, or "timebox," is so important that it overrides all other considerations. If the
project scope conflicts with the time limit, you reduce the scope to fit the time limit. The time limit itself is not
allowed to change.

It avoids the 90-90 problem. Many projects get to the point where they are 90 percent complete and then stay at
that point for months or even years.

It clarifies feature priorities. Projects can expend a disproportionate amount of time quibbling about features that
make little difference in a product s utility.

It limits developer gold-plating. Within the bounds of what was specified, you can often implement a particular
feature in several ways. Developers are left to choose an implementation based on their own goals for quality,
usability, or level of interest in the feature's design and implementation. Timeboxing makes it clear that if there is a
2-day version of a feature, that is what you want.

It controls feature creep. (Feature creep: Es la expansión continua excesiva o la adición de nuevas funciones en un
producto, especialmente en software) Timebox Development helps to control feature creep in two ways. First, if you
shorten the development cycle, you reduce the amount of time people have to lobby for new features. (Achicamos
tiempo de Desarrollo entonces no hay espacio para que la gente agregue nuevas funcionalidades.) Second, some
feature creep on long projects arises from changing market conditions or changes in the operational environment in
which the computer system will be deployed. By cutting development time, you reduce the amount that the market
or the operational environment can change and thus the need for corresponding changes in your software. Entiendo
que si bien parece una desventaja hace referencia a que gracias a timebox no se hacen largos los proyectos y no
llega a ver un cambio de estado.
It helps to motivate developers and end-users. People like to feel that the work they're doing is important, and a
sense of urgency can contribute to that feeling of importance. A sense of urgency can be a strong motivator. (El
mejor lejos, muy real).

Using Timebox Development:

Timebox Development is a construction-phase practice. Developers implement the most-essential features first and
the less-essential features as rime permits. The system grows like an onion with the essential features at the core
and the other features in the outer layers. Construction in Timebox Development consists of developing a prototype
and evolving it into the final working system. Timeboxes usually last from 60 to 120 days. Shorter periods are
usually not sufficient to develop significant systems. Longer periods do not create the sense of urgency that creates
the timebox's clear focus. Projects that are too big for development in a 120-day timebox can sometimes be divided
into multiple timebox projects, each of which can be developed until 120 days.

Timebox Development cycle. Timebox Development consists of constructing and evolving an Evolutionary
Prototype with frequent end-user interaction.

After the construction phase, the system is evaluated, and you choose from three options:

• Accept the system and put it into production.

• Reject the system because of a construction failure. It might have insufficient quality, or the development
team might not have been able to implement the minimum amount of functionality needed for the core
system. If that happens, the organization can launch a new Timebox Development effort.

• Reject the system because it does not meet the needs of the organization that built it. A perfectly
legitimate outcome of a timebox development is for the team to develop the core system that was identified
before Timebox Development began, but for end-users to conclude that the system is not what they wanted.
In that case, work begins anew at the system-definition stage.

The people who evaluate the system include the executive sponsor, one or more key users, and a QA or
maintenance representative. Technical support and auditing personnel can also be involved in the evaluation.
Entrance Criteria for Timebox Development

Timeboxing is not suited for all kinds of development. Here are some guidelines you can use to be sure it is suitable
for your project.

Prioritized list of features. Before timebox construction can begin, the functions and design framework of the
system need to be defined. Realistic schedule estimate created by the timebox team. An estimate for the timebox
construction should be created by the development team. The construction team needs to estimate both how much
time they need (usually 60 to 120 days) and how much functionality they think they can implement within that
period. From a motivation point of view, it is essential that the team create its own estimate. Timeboxing is an
ambitious practice, and it won't succeed if developers are simply presented with an impossible combination of
schedule and functionality goals.

Right kind of project. Timeboxing is best suited for in-house business software (IS software). Timeboxing is an
evolutionary prototyping practice and should be built with rapid-development languages, CASE tools, or other tools
that support extremely rapid code generation. Highly custom applications that require hand-coding are usually not
appropriate projects for timebox development. Before beginning a timebox project, verify that you can build the
project with the available tool set and staff.

Sufficient end-user involvement. As with other prototyping-based activities, the success of Timebox Development
depends on good feedback from end-users.

The Timebox Team

A timebox-development team can consist of from one to five people. The full "timebox team" also includes end-
users who have been designated to assist the construction team. These end-users are often dedicated full-time to
their role of supporting the construction team. The timebox team needs to be skilled in developing systems with the
rapid-development software that will be used. There is no time to learn new software on a timebox project.

The timebox team needs to be highly motivated. The urgency created by the timebox development practice itself will
provide some of the motivation. The ability to achieve a level of productivity rare within the organization should
provide the rest.

Variations on Timebox Development: Hacer minis timeboxs, separando un gran Proyecto que no sería propio para
timeboxs.

Managing the Risks of Timebox Development: Here are some of the problems with timeboxing.

Attempting to timebox unsuitable work products. I don't recommend using timeboxes for upstream such as project
planning, requirements analysis, or design—because work on those activities has large downstream implications. A
$100 mistake in requirements analysis can cost as much as $20,000 to correct later. No usar para diseño de
arquitectura de un Sistema caro y complejo.

Sacrificing quality instead of features. If your customer isn't committed to the timebox practice of cutting features
instead of quality, don't use a timebox. Developers have a hard time meeting conflicting goals, and if the customer
insists on a tight schedule, high quality, and lots of features, developers won't be able to meet all three objectives at
once. Quality will suffer. Once quality begins to suffer, the schedule will suffer too. The team will produce feature-
complete software by the timebox deadline, but the quality will be so poor that it will take several more weeks to
bring the product up to an acceptable level of quality.

Side Effects of Timebox Development: (Esta bueno lo que dice, no tiene efectos colaterales, solo es el tiempo, si
tenes un tiempo corto no es en efecto o propio del timebox que tengas problemas de usabilidad, calidad etc.).
Timebox Development's influence is limited to shortening development schedules. It does not typically have any
influence—positive or negative—on product quality, usability, functionality, or other product attributes.

The Bottom Line on Timebox Development

Timebox Development has been found to produce extraordinary productivity at DuPont, where it was initially
developed. DuPont averages about 80 function points per person month with timeboxing, compared to 15 to 25 with
other methodologies. Moreover, timebox development entails little risk. System evaluation and possible rejection is
an explicit part of the practice, but after its first few years of use, DuPont had not rejected a single system developed
with timeboxing. Scott Shultz, who created the method ology at DuPont, says that "All applications were completed
in less time than it would have taken just to write the specifications for [an application in].

Keys to Success in Using Timebox Development:

Here are the keys to success in using timeboxing:

• Use timeboxing only with projects that you can complete within the timebox time frame (usually from 60
to 120 days).

• Be sure that end-users and management have agreed to a core feature set that the timebox construction
team believes it can implement within the timebox time frame. Be sure that features have been prioritized,
and that you can drop some of them from the product if needed to meet the schedule.

• Be sure that the timebox team is signed up for the ambitious timebox project. Provide any motivational
support needed.

• Keep the quality of the software high throughout the timebox.

• If you need to, cut features to make the timebox deadline. Don't extend a timebox deadline.

Paper: When Good Enough Software is Best.

Our users would like us to develop software instantly, at no cost, and with no defects. But that’s not possible in
today’s world.

The concept of good-enough software is beginning to challenge some of our basic assumptions about software
development,

Misapplied Ideal: In the past, we often negotiated critical success factors once, at the beginning of the project, then
tried to optimize a few other parameters the customer was often unaware of. defects. In other situations, “feature
richness” may be the most important factor; in still others, cost may be the only thing the user cares about.

When Best Isn`t: Shrinkwrapped software may be clumsy and limited in its functionality, our customers tell us, but
it’s cheap and they can put it into service tomorrow morning. ( El software retractilado puede ser torpe y limitado en
su funcionalidad, nos dicen nuestros clientes, pero es barato y pueden ponerlo en servicio mañana por la mañana.)

Late is never Better(a lo ultimo no Podemos cambiar, ya estamos adaptado a lo inicial): Suppose the time has come
to acquire a word processor. You have a choice of products A, B,C. But now suppose you already have a word
processor, perhaps B, and you’ve been using it for a year. Some of its features are slightly annoying, but it’s
adequate for your mundane word-processing tasks. B’s quality isn’t all that great: it crashes once a day, and you’ve
become accustomed to saving your documents every 15 minutes. Would you switch? Maybe – but maybe not. What
if product C required you to convert all your existing word- processing documents to a different format? What if it
required you to switch to a different operating system? You might well conclude that product B was good enough.
Do The Math: Software project managers today must be aware that each parameter - cost, schedule, staffing,
functionality, and quality – is potentially critical. Y hace un gráfico de 3 ejes, X,Y, Z donde pone en cada eje una
variable.

Negotiating A Successful Project: Some commercial project-estimating packages let managers explore trade-offs
among these parameters when they establish the initial project estimates and plans, but they rarely allow for
dynamic renegotiations once the project has commenced. Renegotiation may not be all that important on a project
that only takes three months. But if a project lasts more than a year or two, renegotiation is almost inevitable in
today’s turbulent business environment.

Paper: There are no Small Changes:

There are no small changes when you’re committed to delivering quality software. A background in consulting,
where you are paid for your time, teaches you to ask a few questions before proceeding with ‘small changes’.
Agreeing to features is deceptively easy. Coding them rarely is. Maintaining them can be a nightmare. When you’re
striving for quality, there are no small changes.

Paper: Scum in a nutshell:

Scrum: Un Framework de trabajo en el cual las personas pueden adaptar problemas complejos haciendo que la
productividad y la creatividad lleguen a su máximo valor. Scrum es fácil de entender, pero difícil de ser un “master”.

The Product Owner (PO):

 He owns the product Backlog as se has to maximize ROI (Return of Investment)

 He is responsible of expressing backlog items and prioritizing them.
 The product owner discusses and agrees with stakeholders what to do, why and when to release.
 Collaborate with the development team on the details of the product backlog during the sprint.

The development team:

 Is a cross – functional (interdisciplinarios creo yo) team with an optional size between 3 and 9 members.
 They are self-organizing. No one (not even the Scrum Muster) tells the development team how to turn the
product backlog.
 Scum recognizes no titles for development team members other than developers.

The Scrum Master:

 is responsible for ensuring Scrum is understood and enacted (promulgado, que se este respetando). Realiza
esta tarea asegurándose que el equipo de scrum se adhiera a la teoría practicas y reglas de scrum.
 Is a servant leader (Un líder que ayuda, un líder sirviente) for the scrum team, supporting the product owner
with managing the product backlog and coaches the team in self-organization and cross functional
collaboration.
 Help to removing impediments to the development team’s progress.
 The scrum master leads and coaches the organization in its adoption of scrum.

Scrum Values: FROCC

 Focus
  Respect
 Openness
 Commitment
 Courage

Product Backlog:

 Is an ordered list of Product Backlog items.

 The product backlog items are requirements for changes to the product.
 These items are ordered by priorities, and highest items needs to be more detailed.
 The list of items is constantly changing and updating. The PO is responsible for reflecting the changes in the
product backlog.

Sprint Backlog:

 Is a list of product backlog items selected by the development team for delivery in the sprint, plus a plan to
deliver the increment.
 Only the development team can change its sprint backlog during a sprint.

The Increments: Is the sum of all the product backlog items completed during a sprint and the value of the increment
od all previous sprints.

Others:

 The heart of scrum is a Sprint, a time-box of one month or less during which a “Done”, useable, and
potentially releasable product increments is created.
 No changes are made during sprint that would endanger the sprint goal.
 The scope may be clarified and re-negotiated between the product Owner and development team.

Planning:

Daily:

Review:

Retrospective:
Refinement (Not official form Scrum):

Paper: Scrum for Dummies.

Scrum and the Agile Roadmap to Value:

Scrum is an implementation of agile project management. The roadmap to value is a high-level view of an agile
project and is a guide for your project. It includes the following stages:

 In Stage 1, the product owner identifies the product vision. The product vision is a definition of what your
product is, how it will support your company’s or organization’s strategy, and who will use the product. On
longer projects, revisit the product vision at least once a year.
 In Stage 2, the product owner and business stakeholders create a product roadmap. The product roadmap is
a high-level view of the product requirements, with a loose time frame for when you will develop those
requirements. Identifying product requirements and then prioritizing and roughly estimating the effort for
 those requirements are a large part of creating your product roadmap. On longer projects, revise the
product roadmap at least twice a year.
 In Stage 3, the product owner creates a release plan. The release plan identifies a high-level timetable for the
release of product. An agile project will often have many releases, with the highest-priority features
launching first. Create a release plan at the beginning of each release.
 In Stage 4, the product owner, the scrum master, and the development team plan sprints and starts creating
the product within those sprints. Sprint planning sessions take place at the start of each sprint, where the
scrum team determines what requirements will be in the upcoming sprint, and the development team
breaks those requirements into specifics tasks necessary to create the functionality.
 In Stage 5, during each sprint, the development team has daily scrum meetings. In the daily scrum meeting,
you spend no more than 15 minutes organizing the priorities of the day and discussing what you completed
yesterday, what you will work on today, and any roadblocks you have.
 In Stage 6, the team holds a sprint review. In the sprint review, at the end of every sprint, the scrum team
demonstrates the working product created during the sprint to the product stakeholders.
 In Stage 7, the team holds a sprint retrospective. The sprint retrospective is a meeting where the scrum team
discusses how the sprint went and plans for improvements in the next sprint. Like the sprint review, you
have a sprint retrospective at the end of every sprint.

Scrum: Agile Software Development Manifesto

Scrum is a team approach to project management that aligns with the Agile Manifesto. The Agile Manifesto is an
intentionally streamlined expression of the core values of agile project management. “We are uncovering better
ways of developing software by doing it and helping others do it. Through this work, we have come to value:

 Individuals and interactions over processes and tool

 Working software over comprehensive documentation
 Customer collaboration over contract negotiation
 Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.”

Paper: A Leader’s Framework for Decision Making

The Cynefin framework: Helps leaders determine the prevailing operative context so that they can make appropriate
choices. Each domain requires different actions. Simple and complicated contexts assume an ordered universe,
where cause-and-effect relationships are perceptible, and right answers can be determined based on the facts.
Complex and chaotic contexts are unordered—there is no immediately apparent relationship between cause and
effect, and the way forward is determined based on emerging patterns. The ordered world is the world of fact-based
management; the unordered world represents pattern-based management. The very nature of the fifth context—
disorder— makes it particularly difficult to recognize when one is in it. Here, multiple perspectives jostle for
prominence, factional leaders argue with one another, and cacophony rules. The way out of this realm is to break
down the situation into constituent parts and assign each to one of the other four realms. Leaders can then make
decisions and intervene in contextually appropriate ways.
Paper: Fundamentals of Function Point Analysis

Function Point Analysis is a structured technique of problem solving. It is a method to break systems into smaller
components, so they can be better understood and analyzed.

In the world of Function Point Analysis, systems are divided into five large classes and general system
characteristics. The first three classes or components are External Inputs, External Outputs and External Inquires
each of these components transact against files therefore they are called transactions. The next two Internal Logical
Files and External Interface Files are where data is stored that is combined to form logical information. The general
system characteristics assess the general functionality of the system.

Objectives of Function Point Analysis: Frequently the term end user or user is used without specifying what is meant.
In this case, the user is a sophisticated user. Someone that would understand the system from a functional
perspective --- more than likely someone that would provide requirements or does acceptance testing.

Since Function Points measures systems from a functional perspective, they are independent of technology.
Regardless of language, development method, or hardware platform used, the number of function points for a
system will remain constant. The only variable is the amount of effort needed to deliver a given set of function
points; therefore, Function Point Analysis can be used to determine whether a tool, an environment, a language is
more productive compared with others within an organization or among organizations. This is a critical point and
one of the greatest values of Function Point Analysis. (El análisis de puntos de función se puede utilizar para
determinar si una herramienta, un entorno, un lenguaje es más productivo en comparación con otros dentro de
una organización o entre organizaciones Este es un punto crítico y uno de los mayores valores de Function Point
Análisis.)

Function Point Analysis should be performed by trained and experienced personnel. If Function Point Analysis is
conducted by untrained personnel, it is reasonable to assume +the analysis will done incorrectly.

The Five Major Components:

External Inputs (EI): Is an elementary process in which data crosses the boundary fromoutside to inside. This data
may come from a data input screen or another application. The data may be used to maintain one or more internal
logical files.

External Outputs (EO): An elementary process in which derived data passes across the boundary from inside to
outside. Additionally, an EO may update an ILF. The data creates reports or output files sent to other applications.
External Inquiry (EQ): An elementary process with both input and output components that result in data retrieval
from one or more internal logical files and external interface files.

Internal Logical Files (ILF’s): A user identifiable group of logically related data that resides entirely within the
applications boundary and is maintained through external inputs.

External Interface Files (EIF’s): A user identifiable group of logically related data that is used for reference purposes
only. The data resides entirely outside the application and is maintained by another application. The external
interface file is an internal logical file for another application.

All components are rated as High, Low or Average. After the components have been classified as one of the five
major components (EI’s, EO’s, EQ’s, ILF’s or EIF’s), a ranking of low, average or high is assigned. The value adjustment
factor (VAF) is based on 14 general system characteristics (GSC's) that rate the general functionality of the
application being counted.

Conclusions:

Accurately predicting the size of software has plagued the software industry for over 45 years. Function Points are
becoming widely accepted as the standard metric for measuring software size. Now that Function Points have made
adequate sizing possible, it can now be anticipated that the overall rate of progress in software productivity and
software quality will improve. Understanding software size is the key to understanding both productivity and quality.
Without a reliable sizing metric relative changes in productivity (Function Points per Work Month) or relative
changes in quality (Defects per Function Point) cannot be calculated. If relative changes in productivity and quality
can be calculated and plotted over time, then focus can be put upon an organizations strengths and weaknesses.
Most important, any attempt to correct weaknesses can be measured for effectiveness.

Paper: Comparing Effort Estimates Based on Use Case Points with Expert Estimates

This paper reports the results from a study conducted to evaluate a method for estimating software development
effort based on use cases, the use case points method, by comparing it with expert estimates. The results support
existing claims that the use case points method may be used successfully in estimating software development effort.
They also show that the combination of expert estimates and method based estimates may be particularly beneficial
when the estimators lack specific experience with the application domain and the technology to be used.

The Use Case Points Method: It is based on the function points method, and the aim was to provide a simple
estimation method adapted to object-oriented projects. The method requires that it should be possible to count
the number of transactions in each use case. A transaction is an event occurring between an actor and the system,
the event being performed entirely or not at all. The four steps in the use case points method are as follows:

1. The actors in the use case model are categorized as simple, average or complex. A simple actor represents
another system with a defined API; an average actor is another system interacting through a protocol such
as TCP/IP; and a complex actor may be a person interacting through a graphical user interface or a web-
page. A weighting factor is assigned to each actor category:
 Simple: Weighting factor 1
 Average: Weighting factor 2
 Complex: Weighting factor 3
 The total unadjusted actor weight (UAW) is calculated by counting the number of actors in each category,
multiplying each total by its specified weighting factor, and then adding the products.

2. The use cases are also categorized as simple, average or complex, depending on the number of transactions,
including the transactions in alternative flows. Included or extending use cases are not considered. A simple
use case has 3 or fewer transactions; an average use case has 4 to 7 transactions; and a complex use case
has more than 7 transactions. A weighting factor is assigned to each use case category:
 Simple: Weighting factor 5
 Average: Weighting factor 10
 Complex: Weighting factor 15

The unadjusted use case weights (UUCW) is calculated by counting the number of use cases in each category,
multiplying each category of use case with its weight and adding the products. The UAW is added to the UUCW to
get the unadjusted use case points (UUPC).

3. The use case points are adjusted based on the values assigned to a number of technical factors (Table 1) and
environmental factors (Table 2). These factors are meant to account for effort that is not related to the size
of the task.

Each factor is assigned a value between 0 and 5 depending on its assumed influence on the project. A rating of 0
means that the factor is irrelevant for this project; 5 means that it is essential.

4. Karner proposed a factor of 20 person hours per use case point for a project estimate. Schneider and
Winters recommend that the environmental factors should determine the number of person hours per use
case point [13]. The number of factors in F1 through F6 that are below 3 are counted and added to the
number of factors in F7 through F8 that are above 3. If the total is 2 or less, use 20 person hours per UCP; if
the total is 3 or 4, use 28 person hours per UCP. If the number exceeds 4, they recommend that changes
should be made to the project so the number can be adjusted. Another possibility is to increase the number
of person hours to 36 per use case point.

Problem statement

The description was as follows: The system will be the IT part of a service for shopping through the Internet and the
delivery of products to the customers’ homes. The service should be available through a call-centre or the Internet.
The system will consist of an order taking facility for both the server and the clients. A list of functional and non-
functional requirements to the system was included.

Use case model: The use case model contained 4 actors, 2 primary and 2 secondary, and 22 use cases. Both the
actors and the use cases were described using a template as shown in Appendix A. The use cases were described
with much detail, and they are similar to the use case models in the case study reported in [3].
Development project: The system was developed over a period of 3 months, and 8 people were involved. The total
effort was therefore approximately 24 person months. The development project was similar to the projects
described in [3] in terms of length, total effort, number of people involved and also with regards to functionality.

Results: This section presents the estimates produced by the groups and the use case points method together with
actual effort for the project.

Conclusions and Future Work The use case points method produced estimates that were quite close to the actual
effort spent on a development project. They were closer to the actual effort than most of the estimates produced by
the groups of professional software developers. The estimation method gave a best estimate with Magnitude of
Relative Error (MRE) equal to 0.21, while the Mean Magnitude of Relative Error (MMRE) for the estimates made by
the groups of experts was 0.37. This supports earlier results indicating that when a use case model for a project is
available, the use case points method may support expert knowledge. The results also show that the combination
of expert estimates and method based estimates may be particularly beneficial when the estimators lack specific
experience with the application domain and the technology to be used.