Stefanini ADC Distributed Agile

Agile Software Outsourcing - Distributed SCRUM cycle

As many companies find out, agile development and software outsourcing are two concepts which do not automatically go hand in hand, and require careful adaptations of both the agile development processes and communication channels between the outsourcing supplier and the customer in order to work successfully together.

Distributed agile development with an outsourcing supplier can be successful, and Stefanini Romania has a proven track record of delivering projects run jointly by an onsite and a nearshore team of developers following Agile principles and practices. We are able to achieve these results following our own adaptation of the SCRUM cycle for agile project management, which is described below.

This variation of the Scrum process is used as a baseline in Stefanini Romania for handling Scrum teams in distributed development (onsite and nearshore / offshore) where the Product Owner is located remotely.
There is also the assumption that agile outsourcing project is performed on behalf of a client who has some software development knowledge, rather than being an end-user.


The Scrum Cycle



Roles and responsibilities


In classic Scrum only three roles are clearly defined:

  • The ScrumMaster
  • The Product Owner
  • The Team (Members)
  • The ScrumMaster is responsible for ensuring that everyone related to a project follows the rules of Scrum. These rules hold the Scrum process together so that everyone knows how to play. If the rules are not enforced, people waste time figuring out what to do. If the rules are disputed, time is lost while everyone waits for a resolution. Rule changes originate from the Team, not management. Rule changes should be entertained if and only if the ScrumMaster is convinced that the Team and everyone involved understands how Scrum works in enough depth that they will be skillful and mindful in changing the rules. No rules can be changed until the ScrumMaster has determined that this state has been reached.

  • The Product Owner (typically someone from a Marketing or Product Management role within the client organization) prioritizes and maintains the Product Backlog.


In our distributed agile approach, we introduce two new roles:

  • The deputy product owner
  • The client project manager
  • The Deputy Product Owner is the representative of the client product owner with the nearshore / offshore team. He/she keeps a continuous communication channel with the product owner, thus establishing shared vision beyond the information available in the time-boxed sprint planning meeting. Also this role doubles as an analyst. This role ensures that the many small decisions the outsourced team makes everyday are being checked for consistency, product-wise. Also it is the responsibility of the deputy PO to escalate any substantial product decisions to the client product owner.


The ScrumMaster and the client project manager are facilitators for the team and project needs (on their respective sides – onsite or nearshore) providing resources and routing information to the appropriate persons. Also they are responsible for managing the team in the organizational sense and provide accurate progress reporting, time tracking etc. to the respective organizations.

In typical projects, these roles can be aggregated. The typical aggregation is for the ScrumMaster, and Deputy Product Owner to be the same person however variations might apply. For instance, if business domain knowledge is only through another member of the team and the required analysis is substantial, the deputy product owner could be a separate job. Also if administrative tasks require the presence of a project manager separated from the Scrum Master, that separation can be also achieved, although there is quite a substantial overlap between the two's typical responsibilities.

 

Lean software development

Kanban, Scrumban and lean development in general are the second leading approach to agile software development.

There are certain circumstances in which the requirements or priorities change at such a pace or the solutions are needed so quickly that ensuring even a minimal sprint duration would be impractical and in these cases Scrum is not the most efficient development approach to be put in place, in order to respond to these needs.

Therefore, in order to enable our clients to better adapt to the market demands, at Stefanini we also embraced the Kanban method for agile software development. Kanban is a technique for managing a software development process in a highly efficient way. Kanban is a lean agile system that can be used to enhance any software development lifecycle including Scrum, XP, Waterfall, PSP/TSP and other methods. Especially maintenance projects or projects with a short development cycle perform better when developed using Kanban method.

Rather than working in time-boxed sprints, Kanban puts limits on how many features a team can work on at a given time. Therefore the main difference between between Kanban and Scrum is that Kanban methodology sets a limit for the work in progress for a specific flow, allowing to better focus on the quality of the software development, in a fast changing market.

The two most important advantages of using Kanban in software development are:

  • The newly defined feature is available for immediate release into production
  • The team can already start working on the next highest priority, despite the fact that the priority has just been defined
Methodology (long story short)
Methodology steps

Make Contact

Discover

Develop

Deploy

Start with step 1 Make contact