The way we do development is based on the same fundamental ideas that all
lightweight or agile methodologies are based on. The key point is that we
welcome change because we believe our methodology is built to adapt to
uncertainty. This preparedness to change eliminates the need to guess
everything about the final product in the early stages of the project. This
process of guessing is what in heavyweight methodologies is called requirements
gathering and design stages.
The second point is that all development is iterative. Depending on the size of
the project we strive to release a new version of the product under development
every one to two weeks. A new version is defined as something presentable to
end-users. This approach gives the team invaluable feedback about the features
covered by the release. And because we anticipate change coming from the review
of the version, we react quickly. Usually changes induced by this feedback are
included in the next release.
Internal builds are released much more frequently - as frequently as daily,
sometimes several times a day. Creating internal builds is a part of an
incessant testing process, which provides the stability for the product
despite ongoing changes.
Our methodology is based on our company's culture. We assume that every piece
of code, every decision is for everybody to challenge. In fact, this is a part
of the team leader's responsibilities which is to review regularly the code
produced by the team and push for change of the things that are poorly
designed or can become a problem in the future. Changes can be as small as
coding style, or as big as rewriting the entire piece. In any case the decision
making process that approves or rejects a change does not belong solely with
the team leader, the entire team investigates and reviews all issues before the
decision is made. The development manager oversees this process for all teams
reporting to him. He also occasionally reviews critical pieces of the code
produced by all teams and can initiate the same change process as a team
leader.
Our development atmosphere produces an environment with a number of
desirable characteristics:
Developers know that no matter what they write, there will be changes to come.
Because of this the code they write is much more modular, agile if you wish. It
is much easier and faster to change and the product stability after the change
is much higher.
Developers know that their code will be reviewed and all sloppiness will be
exposed. Our developers do not like their professional pride to be hurt and we
do not work with those who do not care about professional pride.
Every developer is a part of the decision making process. He has a chance to
see firsthand the effect his decisions have on the product delivered to a
customer. This keeps the motivation of the team very high.
Immersion into the process shortens tremendously the ramp-up time for new
members of the team; this also allows us to quickly scale up the teams as
necessary.
The third point about our methodology is that interaction between the customer
and the development team is crucially important to the success of each project.
We consider the customer to be an essential part of the development team. The
project manager is directly involved in the process of evaluation and
re-evaluation of the product as it goes through the releases. The generated
feedback becomes the focus of the next release.
Such a process alleviates major complexities and additional risks usually
associated with the fact that the core development team is located offsite. The
project manager, who works on site with the customer, shields the customer from
all these complexities and ensures transparent communications that work in the
same way as if all the team members were on site. The project manager can
accomplish this because of the lightweight nature of our process.
This shielding and transparency would not be possible with traditional
methodologies because turn-a-round times through formal communication channels
take too long and, as a result, communications slow down to the extent of
ceasing to exist. This considerably increases the risk of receiving a product
that does not meet the customer's expectations.
In our experience, the application of our lightweight agile methodology leads
to faster development of higher quality software on lower budgets.
To learn more about our methodology please visit the FAQ
section or contact us contact us if you have any
questions.
Back to the previous page
Please click here to subscribe to our mailing list.
