The Scrum process focuses on small working teams that are used to maximize
communication and minimize overhead. The process is adaptable to both technical
and business challenges to ensure that the best product is produced. The process
yields frequent increments that can be inspected, adjusted, tested, documented,
and built on.
People performing development work are partitioned into clean, low coupling
segments. This ensures that each partition, or sub-team, can work on their part,
independent of each other. We need to carefully partition the work for the sub-teams
so that there is less overlapping. The MVC based partitioning that we discussed in
the previous chapters is a good model to achieve this.
Testing and documentation is performed as the product is built as a part of the
development work. This ensures that not only the code, but the tests and documents
are also available. Thus ensuring that the product that is being developed is
completely developed. Often, it is the case that code will be the first thing that the
development team focuses, and at the end, it will only be the code that is available.
At that time, if we try to develop tests and documents, the chances of missing
elements are high, as even the team members who wrote the code might have
forgotten what exactly they themselves did. Therefore, it is always a good idea to
perform testing and documentation as we go along.
The other key characteristic of the Scrum process is the ability to declare that the
product is done whenever required. Constant focus is on the working software and
the division of work items into working subsets. All of the working partitions, when
put together, form the working software.
Scrum uses the concept of a backlog to maintain the prioritized list of requirements
or features that provide business value to customer. The items are attended to, based
on the priority. Items can be added at any time and their priorities can be changed
based on the customer’s demand.
Sprint, in the context of Scrum, is the work units required to achieve one of the
backlog items. These work units must fit into a predefined time box, meaning that
the Sprint must be completed within a predefined time period. The backlog items
that are affected due to a higher priority backlog items are frozen to make way for
highest priority items in the list.
Scrum meetings are intended to check the health of the process and the product.
These are daily meetings of 15 minutes to discuss the following:
- What was done since last meeting?
- What obstacles were encountered?
- What will be done by the next meeting?
Demos, in the context of the Scrum process, deliver a software increment to customer
for evaluation. Based on the feedback given by the customer, backlog items and their
priorities will be updated and the next Sprints will be scheduled.
Feature Driven Development
As in most of the other agile style process models, Feature Driven Development
emphasizes collaboration among team members. The complexity of the project
is handled by using feature-based decomposition of the problem, followed by
the integration of software increments. The technical communication is done
using verbal, graphical, and textual means. Software quality is assured by using
incremental development, design and code inspections, metric collections, and
use of patterns in all areas, such as analysis, design, and construction.
In FDD, we develop an overall model that contains a set of classes that depicts
the business model of the application that is to be built.
Then, based on this model, a features list is built. Features are categorized and
prioritized and then work is broken up into two week chunks.
The project planning is then done by feature. Features are assessed based on
priority, effort, technical issues, and schedule dependencies.
Design is also done based on each feature. Classes relevant to a feature are chosen
first, and then class and method logics are written. An owner is assigned to each
class. That owner is responsible for maintaining the design document for his or her
own work packages.
The build system is also based on each feature. The class owner translates the design
into source code and performs unit testing, and the integration is performed by a
Agile Modeling (AM) is a practice-based methodology for effective modeling and
documentation of software systems in a light-weight manner.
Modeling is based on a set of guiding principles. First, modeling will be done with
a purpose. Multiple design models are used to capture different perspectives. Out
of the multiple models, only models with a long-term value are retained.
It is important to note that the model content is more important than the model
representation. In the modeling process, it is important to get to know the models
and tools that we use to create the models.
In the requirements gathering and analysis modeling phases, we need to work
collaboratively with the customer to find out what the customer wants to do with
the system. To ensure this occurs, once the requirements model is built, collaborative
analysis modeling continues with the customer.
Architectural modeling derives a preliminary architecture from the analysis model.
An architectural model must be real for the user’s environment. Also, it must be
understandable by developers because they should ensure that key characteristics
of the model are preserved while constructing the system.
Agile for the PHP team
Now that we have a good understanding on the agile principle, let us discuss how
the PHP team can benefit from the application of agile principles.
Pair programming will help in improving team bonding, team interaction, and will
help each team member to uplift their standard. We can use all of the principles of
pair programming that we discussed under the heading Extreme Programming (XP).
Body language is important, therefore, they should sit side by side so that both
partners of the pair feel comfortable.
The PHP code should be written while conversing with each other. Rather than
criticizing each other, the pair needs to collaborate. They need to discuss the
strengths and weaknesses of the PHP constructs used, conventions and guidelines
followed, and the libraries and APIs used. The pair should focus on the elegance,
efficiency, performance, and readability of the PHP code that they produce.
There are two roles that must be performed in a pair. The first role is the one who
is at the keyboard and the other role is the one who looks at the PHP code that
is written by the keyboard owner. The one without the keyboard has more time
to think, and therefore will generate more ideas than the one with the key board.
Over time, to avoid friction, it will be a good idea to switch these two roles too, on a
regular basis. This will allow both members to have ample time to think as well as to
work, so they can equally contribute with their brilliant ideas to the work at hand.
It is a common question to ask if it is worthwhile to spend two people to do the
work that can be done by one. Note that it is not really true to say that two people
are doing the work of one person in pair programming. Coding is not the most
important part of the project. It is writing the right PHP code that syncs up with
the correct design that is most important. In pair programming, while one is
writing PHP code, the other is thinking ahead, looking for potential problems and
corner cases. This will reduce bugs, increase system quality, and increase system
acceptance by the end users.
Sustainable working style
Team members should work with passion and energy on the project. To make sure
that the team members continue to work energetically, they need to have a room to
recharge themselves on a daily basis. If this is not done, the team will not be able to
work on the project with the same level of energy at all times. They will tear up, thus
hindering the project’s success towards the end of the project’s life cycle.
To sustain the team’s energy, the team needs to re-energize themselves. They should
go home on time, take a break, take some time off from work, and spend time with
family and friends.
If any team member is sick, they should be encouraged to stay at home. It is not
productive for someone to work when they are sick. Going to work while suffering
from an illness increases the risk of making other people in the team sick.
While at work, when team members feel tired, they should take a break. When team
members make more mistakes than progress, then it is a clear indication that the
folks are tired, and they should take a break. It is a good idea to have some coffee
or tea, have some chit-chat, watch some TV, or play a game. Yes, you should have
facilities in the office to facilitate those activities. It is not a good idea to only have
a book shelf with some PHP books in the recreation area. There should be some
activities that the team can enjoy.
All members of the team should be sensitive to the current status of the project.
Wandering around the work area should provide ample information about what
is going on with the project. There should be enough white boards to capture ideas
around the workspace. Rather than worrying about the neatness and beauty of the
drawn diagrams, it is more important to have the ideas captured then and there.
Therefore, it is perfectly fine to hand-draw the design diagrams and charts. There
should be no rush to computerize the stuff. We can always use digital cameras to
capture the white boards and can transfer them as notes to the computer.
For a healthy project, everyone on the team should have free and ready access to
the information. Rather than looking and trying to understand the design, team
members should be able to sense the design and reinforce that within the workspace,
as they do their day to day work.
Simple charts can help to feed information into the team, and can help to evaluate,
and thereby reinforce, the health of the project.
Some simple charts that can help you to improve the process include the following:
- Amount of pairing, as percentages, where people were working in pairs
versus where people were working alone. This chart can help us to evaluate
if we really use pair programming.
- Paring combinations, showing who pared with whom over a period of time.
These can help us to evaluate our effectiveness of paring.
- Tests per second, showing how many tests were executed over a day. Also,
showing in how many tests we passed (versus failed). This helps us to gauge
our coding quality.
- Tracking the time to fix the found issues and the number of issues opened
versus number of issues resolved. Continuously tracking the number of
outstanding issues. This will help us understand the efforts required to solve
the problems along with our ability to solve the problems quickly.
Fixing the process
Things will go wrong. Mistakes will happen. We need to learn lessons from them
and move on. To fix those problems and prevent them in the future, we need to
understand those problems, and especially why they happened. Root-cause analysis
helps us in understanding the problems and figuring out the way to fix them in the
way we work so that things don’t go wrong again.
Also, in root-cause analysis, collaboration can help us in dealing with fixing issues
in the process. We can share our conclusions and reasoning with each other, and can
get everyone’s perspective to ensure that we reach the best possible decisions to fix
To collaborate among the team members in an effective manner, it is a good idea
to sit together. Sitting together facilitates rapid and accurate communication. This
means everyone, including the experts in design, business, programming, and
testing, sits together. In this way, you have more opportunity to communicate clearly
with each other, you also have the opportunity to learn from each other.
Sitting together reduces time to solve the problems drastically. You just turn around
and ask someone who knows the subject. It also encourages you to ask for help, and
you can get help when you need the most because there is no need to postpone.
It is not a good idea to ask the team members to sit with each other, against their will.
However at the same time, the setup and layout of the work area should encourage
people to sit together. The free fl ow of communication will not be encouraged if
the workspace was arranged in such a manner that people were confined to their
personal cubicles. At least have some common working areas so that people can sit
comfortably and work with the other people, as and when they want.
One of the arguments against sitting together would be the background noise.
However, over a period of time, people will realize that the energy of the project’s
team is fl owing across the room. Thus, they will get used to the new model of
working in a shared workspace. On the other hand, if the need for privacy arises for
some activities like, meetings or calls, meeting rooms could be used for those things.
Remember, it is important to ask more questions, rather than having the team
members or pairs trying to guess the things for themselves.
When we develop software for business domains, we need to be able to
communicate what we do, what others want, what the system is all about,
and so on, to non-programmers and programmers.
Often, we are good at explaining the technical aspects related to the software and
to the use of programmer’s jargon. We are also capable of understanding what
others tell us on the software and on the use of programmer’s jargon. However, the
challenge is to explain the system and what we are doing for non-programmers, and
remember that system users are non-programmers. The idea is not to eliminate the
use of technical terms, but rather to make sure that others also understand what we
are talking about. The language that we use to describe things should be as close as
possible to the real world domain (where the software is to be used).
Ubiquitous language reduces the risk of miscommunication among team members
as well as between the team and the users. And note that even the PHP code that
we write should refl ect this language. Therefore, the function names, class names,
and the names of the variables that we use should refl ect this. Also, the language
that we use should be in sync with the jargon used in the data and business models
that we developed.
It is important to know what others are doing in the team on a regular basis. It is
always a good practice to eliminate the need for assumptions with respect to the
rest of the team. When someone is stuck, others will be able to help because others
have already gotten over that hurdle. That way, we can save tons of time, rather
reinventing the wheel.
Stand-up meetings are about people interaction and participation. It needs to feel
open and free. Therefore, it is important to do that in an open area, rather than
around a cramped area. The environment should set the feeling for energetic and
It is not required to wait for the stand-up meeting to start the day. However, it is
useful to start the day with the stand-up meeting. Moreover, the meeting should
be short and sweet. As short as thirty seconds of speaking time (per person)
The points to discuss should be crisp and clear. What did each team member do
yesterday, what each member will be doing today, and what are the hurdles, if there
are any. Moreover, pairs should also be picked, based on past experiences that other
members have, to overcome hurdles found on a given day.
Irrespective of the fact that there is benefit in having stand-up meetings, it should not
be taken as an excuse for one not to raise problems. If a pair hits a road block in the
middle of the day, they should not wait until the next morning’s stand-up meeting
to communicate about it to the rest of the team. Communicate issues as soon as the
issues surface, irrespective of the fact that there will be a meeting the next morning.
This is because others in the team might need to discard some work due to the issue,
as they didn’t know that earlier.
Demonstrate the iteration outcome
Until the product is run for real, we cannot be sure if it will run and solve the
problems that we actually have in our hand.
We can conduct weekly iteration demos to ensure that we have a running product
on a regular basis. This would cut down on integration pains by a great deal. It
also makes the team honest. They will admit to the breaks and bugs in the code or
weaknesses in the design. It is important that the team has an open mind regarding
the issues in the product that they develop.
The team needs to be honest with the problems and with the way they handle those
with the stakeholders. This will ensure that we build trust with stakeholders. If the
stakeholders lose their trust in the team, then that will not help the project in the
Weekly deployment of the product in the real deployment environment will help
the team realize the real issues.
In this chapter, we discussed the concepts related to the agile development practices
in detail. Agile practices help us to deliver software that will maximize business
value of the systems that we develop for the customers.
Agile philosophy confronts many traditional software practices. This is done to
ensure that we can deliver software that is working and reliable, in a faster and
more effective manner.
Self-organizing the teams, where each member takes the initiative and responsibility
to deliver, is recommended. The working software is at the heart of the agile
processes. These teams need to collaborate among themselves, as well as with
the system users, to ensure that the delivered software meets expectations. Short
delivery cycles, regular increments, regular demos, and deployment of the software
being developed are important traits of the agile processes.
We can use PHP effectively to capture the requirements in the initial phases. This
can be done using PHP as an effective means of building prototypes to capture the
users’ feedback. PHP programmers can pair up to minimize the possibility of bugs,
and to increase the design and code quality. Different perspectives brought in by the
various team members and the users will ensure that we get the product right.
Several flavors of agile processes were discussed in this chapter. This was done
to help you understand the various means of adopting agile concepts to the PHP
project on which you are working. Rather than just playing by the rules, it is ideal
to try and evolve the current process to suite the project needs in an evolutionary
manner. A team will not be able to go agile over night. However, slow and steady
adoption of agile principles can win the challenge.