Evozon’s Agile Approach

You might have already used the Scrum methodology and failed a few projects with it. The most notable drawback of this methodology is that it only allows you to detect failures at the end of the unique development cycle, which means that all the money allocated for development is lost. This disadvantage, among others, makes Agile development the preferred approach at Evozon.



We have tried to refine and even improve the Agile approach as described by Scott W. Ambler by borrowing a little from XP methodology. This enabled us to maximize our results when training newcomers and also improved communication. The result matured into our ‘best practice’ Agile approach and is further refined for each project when we consider influences from team member’s character and personalities, possible outcomes, the client's needs and level of interaction. Our ‘best practice’ is outlined in the steps below.

1. Inception

a) After the birth of the idea the customer interacts with our sales and management team. The idea is then passed to the development team’s architects and seniors who have a short brainstorming session to discuss direction etc.

b) Then a representative person or group is chosen to interact with the customer who is then bombarded with ideas and wish lists but not to-do’s.

c) Following this the discussion turns to; the general requirements, definition of a short possible life cycle, the projects lifetime, scalability, possible deployment scenarios (cluster, web farm), required and or imposed technologies, expectancies etc.

d) The front line team with management can then approximate human resources. In the initial stages the team is allocated about one or two hours per day to contribute ideas and research technologies.

e) The big picture is drawn as a high-level architectural plan and the level of details presented to the customer will be carefully chosen so that no deviation can occur.

f) The customer gives feedback and suggestions.

Steps ‘e’ to ‘f’ are repeated until the whole picture is understood. From this planning steps like; technical requirements, ui prototyping, test planing, deployment issues, risks assumption, checking resources availability will evolve but all at a high level. At this level each iteration will; identify technical risks (those hours from point ‘d’ might help), give birth to ideas, create suggestions, identify best approaches and new needs. Depending on the number of iterations and the progress obtained from the discussion a schedule can be drawn.

2. Elaboration

a) Architectural modelling with ui prototyping both correlated with technical risks identification (bottlenecks, ui tweaks, effort need it for building something special, etc)

b) At this phase we already have allocated more resources depending on the needs of the project. The most experienced developers will try to prove the architecture by small sampling applications which will try to meet the performance issues and identify ui tweaks.

c) Clients are asked about other possible directions this product can evolve to and perhaps handle volumes of data several orders of magnitude greater or can it be put into another deployment environment.

d) The test planning is refined (unit testing, integration, tdd style) and the deployment plan assumed.

e) The last step is defining the team working environment (the war room) by finding the people best suited for the project and managing the required human resource migrations from project to project.

‘a’, ‘b’ and ‘c’ can progress in parallel but ‘a’ will take the highest priority and will influence both ‘b’ and ‘c’. ‘d’ is usually discussed next. The last point ‘e’ is where all human resources (available, best suited, newbies) will be allocated to the project and the environment will be setup. We prefer a single room to house all of our developers and newbies paired with advanced developers. All will be in close range to seniors with influence from upper management minimized.

3. Construction

a) Further evolution of the analysis and design models.

b) Short iterations of preferably two to four weeks.

c) Iterations will be considered lock downs which means that during their development phases they can’t be modified until it’s complete. After that if something needs changing or redesigning the architects and senior developers will analyse the risk, communicate the results and modify the estimates accordingly. We then proceed after the client’s approval.

d) The testing model is detailed, plans are put to work and after successful iterations the test units are written for those modules. After a few co-existing iterations are done, integration tests are conceived and implemented. Every future iteration’s success or failure will depend on the success of the tests. Bug fixing time is allocated in the iterations so that no extra time needed.

e) Important notes for user manuals and deployment documents are written but these are only summaries.

f) Milestones are created after subsequent iterations or after a few related preliminary deployments are made. Customers can see the results, interact with the developers and suggest improvement etc.

4. Transition

a) Short testing run.

b) QA department steps in and the project is locked down.

c) Project validation (requirement meet), metric tests.

d) Documentation.

e) Deployment procedures (usually step three is done but they’ll need a few small adjustments as always).

f) Client acceptance.

g) Live deployment.

h) Champagne.

Trust us with a small test project