Agile approach

In most cases we prefer to use Agile approaches, on projects where the dedicated team business model is chosen you can choose any reasonable management methodology you have experience with


Agile approaches are based on iterative and incremental development that focus on client collaboration, interaction, working software and responding to change rather than processes and tools that follow a rigid plan and detailed documentation. Such approaches fit really well with projects that have incomplete requirements and require evolutionary development and deployment.


The main Agile approaches we use are Scrum and Kanban backed up with technical practices from XP methodology.


Basically, in Scrum the development is split into the iterations (Sprints). Usually they are one-to-three weeks long. The Client (Product Owner) prepares and maintains a list of features (Product Backlog) prioritized according to their business values. The Team then uses the Product Backlog to plan Sprints which contain a subset of Product Backlog items.

Each sprint plan is defined in the Sprint Backlog document that contains all the features that are going to be implemented during that particular sprint. The Sprint Backlog is managed by the Team.


Subsequent to each iteration the project team rolls out a product build with the functionality defined in the Sprint Backlog for testing and Product Owner’s review.


All the defects found in the build are documented in a bug-tracking system like Redmine, Mantis or Jira. In order to fix the detected issues the development team reserves some time during each sprint for debugging and bug fixing activities. This continuous testing and bug fixing process ensures that the quality of the released product is always high.


Feedback, defects and small enhancements found by the Product Owner will be added to the Product Backlog and implemented during the next iteration.


After all the functionality of the project is implemented, the project team provides the Product Owner with the latest build of the product and the Product Owner conducts so called Acceptance testing. All the defects found at this stage are fixed on demand and Product Owner accepts the project as completed.



Kanban is another Agile-based methodology. It is a flow-oriented methodology, but at the same time it is much less declarative than Scrum. Kanban has the following differences compared to the Scrum methodology:

  • No iterations/sprints. Kanban development is based on task flow which moves through the development team.
  • Workflow visualization. Kanban uses a special board which shows the current state of the project with ‘Backlog, ‘In progress’ and ‘Done’ tasks. An example of the Kanban board can be found below.
  • Work in progress (to do tasks) is limited at each stage. This approach allows us to find bottlenecks and fix them as immediately.
  • Time saving. Estimations are not created as they are unnecessary. Workflow does not stop at the end of the iteration which keeps team working full-time.
  • No roles defined. The Project team and Client can specify any roles they need for the project.
  • Ability to add any other rules and practices from Scrum, XP and other methods.

The Kanban methodology fits better in development projects where tasks are constantly changing and there is no way to specify the iterations. It’s also good for projects that are at support stages. At the same time Kanban requires more software development process understanding and greater involvement on the Client side.

XP practices

Every designated process is backed up with a subset of technical XP practices. For each project we select only those practices which are required for this particular project.


The main practices are:

  • Coding standards
  • Refactoring (evolutionary software design improvement)
  • Unit testing
  • Continuous Integration


The first two practices are used in most of the projects. Unit testing and Continuous Integration are used for mid-size and large projects.

Benefits of Agile approach

  • highest business features delivered first
  • simple rules and transparent process for all stakeholders
  • project could be started even with incomplete requirements
  • requirements could be changed during the project as many times as needed
  • high level of self-organization, continuous adaptation and innovation

Leave a Reply