Common fears for developers
In this section, we will discuss some of the fears that developers face while working
on a software project. We need to pay attention to these fears because they can
impact the project’s success. First, we need to understand what these fears are.
Then, we need to understand their implications on the project’s success. This
understanding will help us to cope with them in the correct manner. We can also
prevent them from getting in the way of the project’s team members, when reaching
towards project’s success.
Producing the wrong product
The project will produce the wrong product if we do not clearly understand the
requirements of the users. There’s always the possibility of a gap between what we
understand and develop, and what the users want. We can try and bridge this gap,
which we will discuss later in this chapter. If we let this gap stay as it is, we will
end up producing the wrong product. The developers will be negatively affected
if the wrong product is produced. On the other hand, it is bad for the developers’
reputation. Producing the wrong product will also affect the confidence level of
the developers. If the product that was produced by the developers was the wrong
product and got rejected by the users, it will have a long-term impact on the careers
of all of the developers in the project’s team.
Product of inferior quality
While producing the wrong product is the worst case scenario, producing a product
with inferior quality also has a negative impact on all of the members of the project’s
team. A product delivered with inferior quality will reduce the confidence that the
management team has on the project’s team. This will also affect the moral of the
team members. Therefore, everyone on the project’s team fears delivering a low
Getting late to complete the project
Not all, but many projects run late. The project will be late due to various reasons.
One of the things that can make the project late is misjudgment of the requirements
and the misjudgment with respect to the technology chosen for the project. If we
choose an incorrect technology, it will cause us to run into many technical problems
while delivering the real work. The dangers of the delay with a project include losing
the project. Because of this, the organization will lose revenue opportunities. It also
affects the future business of the organization. It will also affect the team members
individually because they will be deemed as not capable of completing the assigned
tasks on time. That will have a negative impact on the image of the team members
and the organization’s leaders. A project that is getting delayed is often looked at,
as a cost center in an organization, rather than the revenue-generating engagement.
Therefore, during the next round of performance evaluation and salary reviews, the
team members who were part of the project that was delivered late will not have
many positive reviews. This will also affect their respective careers in the future.
It is important to note that when the specifications change, the resulting
implementation times can also vary. Therefore, calculating time buffers for such
unforeseen scenarios is important. In the following sections, we will discuss how
agile development will help reduce delays or help us to identify the possible delays
early in the project. This can be done by effectively collaborating with the users and
incorporating users’ feedback into the product that is being built early and often.
Too much work in too little time
If the team starts feeling that the project is getting late, then there are chances that
they will need to work for more hours (per week). Overworking has many negative
consequences in addition to the immediate problem of having to work in the nights
and kill rest. On one hand, it reduces the quality of life leading into all sorts of
problems (for example, family and relationships related problems). On the other
hand, it opens the door to a bunch of problems that will have long lasting impacts
on the individuals and organization, such as stress, getting bored with what team
members do, and deterioration of the quality of work. These long-term consequences
will have far-reaching ripple effects. Therefore, as much as possible, we need to try
and prevent doing overwork.
Overwork also results due to slip-by bugs. Rushing to fix one bug and overlooking the overall picture can result in a snowball effect with respect to bugs. Tools, techniques, and metrologies that prevent sloppy work will cut down a considerable amount of rework and save time.
Traits of agile team members
Developers always look to overcome the fears that were described in the preceding
section. The best way to overcome those fears is to ensure that they develop certain
traits. These traits should help them to overcome the problem-causing situations that
become the root causes for the above fears. In the following section, we will discuss
the traits that are desired from the team members that follow an agile process.
Any project needs competent team members. However, unlike the traditional
software development approaches, the agile process is much more sensitive to the
team member’s competence. This is because we entrust each member to deliver
working software at any given time, and everyone in the team is assumed to deliver
with expected quality. The project assumes motivated individuals, and the team is
built on trust.
The focus is to deliver early and often. Working software must be delivered to the
client at all times. To achieve this, the team should have a common focus. If the focus
is not unified, we need to waste time and efforts on getting all of the team members
to pay attention to where we are heading. Therefore, it is desirable to have all the
members in a team to focus on common objectives.
Collaboration requires good communication skills. As mentioned earlier, it is not
only about talking or writing on what one wants, but also about listening and
understanding what others want. Good communicators are also good listeners.
Agile teams are based on everyone’s ability to do the job. There cannot be situations
where some of the members need to lean on others for making a decision. It is a
different matter that others can help, but each member should be able to stand up
on their own and make their own decisions. In other words, everyone should be a
leader. There can be a designated leader to make various cross-cutting decisions,
but everyone in the team owns an important aspect of the final product. Therefore,
everyone should be able to decide what is good and what is bad for that part of the
system on which they are working.
Fuzzy-problem solving ability
Most of the problems that we need to solve, while helping users in building
applications to run their business, cannot be solved using a mathematical approach.
The real-world business problems are fuzzy. Fuzzy means that it is very difficult to
define the problem precisely. Moreover, because those problems are solved by the
software that we develop, our PHP project team should be able to deal with those
fuzzy problems. This is one of the challenging areas that developers face, as the
programming language constructs are logical and hardly fuzzy. We need to get the
team members to deal with those fuzzy aspects of the problems. It is a mindset and
technique, more than a technology.
Mutual trust and respect
Each member in the team has his or her own responsibilities, and we depend on
them to deliver on those. Mutual trust is critical when we are dealing with each
other. We can always verify on what everyone delivers. However, we need to trust
them to deliver, rather than trying to micromanage individuals by thinking that they
Respect is also as important as trust. We need to respect each individual’s ideas, their
approach, and their personal formation. Respect is most important when it comes to
interaction. Respect encourages alternative views and voices, which is the secret
of success when it comes to technically-excellent designs. Every individual in the
team should be respected so they become comfortable in being an active member
in the team.
What is agility
Agility includes effective, that is, rapid and adaptive, response to change. This
requires effective communication among all of the stakeholders. Stakeholders
are those who are going to benefit from the project in some form or another. The
key stakeholders of the project include the developers and the users. Leaders of
the customer organization, as well as the leaders of the software development
organizations, are also among the stakeholders.
Rather than keeping the customher away, drawing the customer into the team
helps the team to be more effective. There can be various types of customers, some
are annoying, and some who tend to forget what they once said. There are also
those who will help steer the project in the right direction. The idea of drawing the
customer into the team is not to let them micromanage the team. Rather, it is for
them to help the team to understand the user requirements better. This needs to be
explained to the customers up front, if they seem to hinder the project, rather than
trying to help in it. After all, it is the team that consists of the technical experts, so
the customer should understand this.
Organizing a team, in such a manner so that it is in control of the work performed,
is also an important part of being able to adapt to change effectively. The team
dynamics will help us to respond to changes in a short period of time without any
Agile processes are based on three key assumptions. These assumptions are as follows: • It is difficult to predict in advance, which requirements or customer priorities will change and which will not. • For many types of software, design and construction activities are interweaved. We can use construction to prove the design. • Analysis, design, and testing are not as predictable from the planning's perspective as we software developers like them to be.
To manage unpredictability, the agile process must be adapted incrementally by
the project’s team. Incremental adaptation requires customer’s feedback. Based
on the evaluation of delivered software, it increments or executes prototypes over
short time periods. The length of the time periods should be selected based on the
nature of the user requirements. It is ideal to restrict the length of a delivery to get
incremented by two or three weeks.
Agility yields rapid, incremental delivery of software. This makes sure that the client
will get to see the real up-and-running software in quick time.
Characteristics of an agile process
An agile process is driven by the customer’s demand. In other words, the process
that is delivered is based on the users’ descriptions of what is required. What the
project’s team builds is based on the user-given scenarios.
The agile process also recognizes that plans are short lived. What is more important
is to meet the users’ requirements. Because the real world keeps on changing, plans
have little meaning. Still, we cannot eliminate the need for planning. Constant
planning will make sure that we will always be sensitive to where we’re going,
compared to where we are.
Developing software iteratively, with a greater emphasis on construction activities, is
another characteristic of the agile process. Construction activities make sure that we
have something working all of the time. Activities such as requirements gathering for
system modeling are not construction activities. Those activities, even though they’re
useful, do not deliver something tangible to the users. On the other hand, activities
such as design, design prototyping, implementation, unit testing, and system testing
are activities that deliver useful working software to the users.
When our focus is on construction activities, it is a good practice that we deliver the
software in multiple software increments. This gives us more time to incorporate
user feedback, as we go deeper into implementing the product. This ensures that the
team will deliver a high quality product at the end of the project’s life cycle because
the latter increments of software are based on clearly-understood requirements. This
is as opposed to those, which would have been delivered with partially understood
requirements in the earlier increments.
As we go deep into the project’s life cycle, we can adopt the project’s team as well as
the designs and the PHP code that we implement as changes occur.
Principles of agility
Our highest priority is to satisfy the customer through early and continuous delivery
of useful and valuable software. To meet this requirement, we need to be able to
embrace changes. We welcome changing requirements, even late in development life
cycle. Agile processes leverage changes for the customer’s competitive advantage.
In order to attain and sustain competitive advantage over the competitors, the
customer needs to be able to change the software system that he or she uses for the
business at the customer’s will. If the software is too rigid, there is no way that we
can accommodate agility in the software that we develop. Therefore, not only the
process, but also the product, needs to be equipped with agile characteristics. In
addition, the customer will need to have new features of the software within a short
period of time. This is required to beat the competitors with state of the art software
system that facilitate latest business trends.
Therefore, deliver the working software as soon as possible. A couple of weeks to
a couple of months are always welcome. For example, the customer might want
to improve the reports that are generated at the presentation layer based on the
business data. Moreover, some of this business data will not have been captured in
the data model in the initial design. Still, as the software development team, we need
to be able to upgrade the design and implement the new set of reports using PHP in
a very short period of time. We cannot afford to take months to improve the reports.
Also, our process should be such that we will be able to accommodate this change
and deliver it within a short period of time.
In order to make sure that we can understand these types of changes, we need to
make the business people and the developers daily work together throughout the
project. When these two parties work together, it becomes very easy for them to
understand each other.
The team members are the most important resource in a software project. The
motivation and attitude of these team members can be considered the most
important aspect that will determine the success of the project. If we build the project
around motivated individuals, give them the environment and support they need,
trust them to get the job done, the project will be a definite success.
Obviously, the individual team members need to work with each other in order to
make the project a success. The most efficient and effective method of conveying
information to and within a development team is a face-to-face conversation. Even
though various electronic forms of communication, such as instant messaging, emails,
and forums makes effective communication possible, there is nothing comparable to
When it comes to evaluating progress, working software should be the primary
measure of progress. We need to make sure that we clearly communicate this to all of
the team members. They should always focus on making sure that the software they
develop is in a working state at all times. It is not a bad idea to tie their performance
reviews and evaluations based on how much effort they have put in. This is in order
to make sure that whatever they deliver (software) is working all of the time.
An agile process promotes sustainable development. This means that people are not
overworked, and they are not under stress in any condition. The sponsors, managers,
developers, and users should be able to maintain a constant pace of development,
testing, evaluation, and evolution, indefinitely.
The team should pay continuous attention to technical excellence. This is because
good design enhances agility. Technical reviews with peers and non-technical
reviews with users will allow corrective action to any deviations from the expected
result. Aggressively seeking technical excellence will make sure that the team will
be open minded and ready to adopt corrective action based on feedback.
With PHP, simplicity is paramount. Simplicity should be used as the art of
maximizing the amount of work that is not done. In other words, it is essential that
we prevent unwanted wasteful work, as well as rework, at all costs. PHP is a very
good vehicle to achieve this.
The team members that we have should be smart and capable. If we can get those
members to refl ect on how to become more effective, at regular intervals, we can get
the team to tune and adjust its behavior to enhance the process over time. The best
architectures, requirements, and designs emerge from self-organizing teams.Therefore,
for a high quality product, the formation of the team can have a direct impact.