Global Balance Methods

Agile Development

While much of the software world recognizes the need to transition to agile methods, it is more difficult in some places than others.  Global Balance has deep roots in traditional Waterfall development methodologies and has been implementing agile methods for our clients since 2001. Our method agnostic approach allows us to look at every new client implementation of agile and recommend a solution that is the best fit for an individual team.

Our teams have the most experience developing in hybrid versions of Feature Driven Development, Kanban and Scrum. FDD and Kanban provide the most flexibility in resourcing agile teams because they are easier to implement with teams that reside in difference time zones. When a team is committed to a pure Scrum approach, we recommend using Global Balance’s U.S. and South American resources because their time zones overlap most of the U.S. time zones.

Feature Driven Development

When organizations need to apply agile to larger projects and teams or are highly leveraged in Waterfall processes and artifacts, we’ve found Feature Driven Development (FDD) is an effective way to transition to agile and gain quick value. FDD includes an upfront “iteration zero” where the object model and planned features are defined. Then, variable length feature sets are agreed to which become the backlog for iterations of designing and building features.

A major difference between Waterfall and FDD is that requirements, design and building take place in small iterations after iteration zero. A major difference between FDD and Scrum is that iterations are not fixed length.


When FDD is the most appropriate agile implementation to use, we use the following processes or phases to deliver a solution:

  • Develop Object Model
    • Develop a model that helps the team as a whole learn to communicate with each other and start to establish a shared vocabulary. This model becomes the primary vehicle around which the team discusses, challenges, and clarifies requirements.
    • Conduct short facilitated team activities where domain experts and development team members develop a shared understanding of the problem domain.
    • Document key problem domain concepts, relationships, and interactions.
    • Build an object model that concentrates on breadth rather than depth. Over the course of the project, depth is iteratively added to the object model started in this process.

  • Build a Feature List
    • Identify small, client-valued requirements referred to as features that will drive the project. A feature is as a small, client-valued function expressed in the form of <action> <result> <object>. An example of a feature is “convert item 1 to item 2.”

  • Plan by Feature
    • Plan the project by organizing the feature list into sets of deliverables that provide prioritized business value.
    • Assign feature sets to the requirements and development teams who will estimate the feature sets and create a variable length iterative schedule.
    • At the end of this process, the feature sets become the backlog of features to implement.

  • Design by Feature
    • Select a small group of features that make the most sense to develop over a few days.
    • Identify the domain classes likely to be involved in the iteration and the class owners who will perform the development work.
    • Assemble a feature team including domain experts, testers, technical authors and user experience designers.
    • Analyze the details of each selected feature and design the feature solution.

  • Build by Feature
    • Work individually on coding and testing tasks.
    • Conduct code inspections on the feature set code.
    • After quality inspection, promote the code to the main branch or production environment and reassign the feature team to perform the same process steps in another feature set.


When organizations wish to leave most of their development practices in place and gradually move to an agile approach, Kanban is a good solution. This is especially true when critical resources are constrained or true teams do not exist because people are on multiple projects at the same time. As the organization matures, Kanban can be used in any hybrid agile approach. Global Balance can help organizations benefit from the value of Kanban by guiding the implementation of Kanban or augmenting their existing Kanban team with onshore and offshore resources.


At its core, Kanban implements:

  • A high degree of visibility into the state of all work queued and in progress
  • Absolute respect for WIP limits
  • A commitment to execution in a ‘pull-based’ manner from the prioritized work queue
  • A focus on quality

Some of the differences between Kanban and other agile approaches that make it easier to implement are:

  • There are no prescribed roles
  • Work is pulled through the system in pieces instead of in batches
  • Changes to delivery schedules can be made at anytime
  • It is more appropriate in operational environments with a high degree of variability in priority


Scrum emphasizes the idea of “empirical process control.” Scrum uses the real-world progress of a project, not best guesses or uninformed forecasts, to plan and schedule releases. In Scrum, projects are divided into succinct work cadences, known as sprints, which are typically one week, two weeks, or three weeks in duration. At the end of each sprint, stakeholders and team members meet to assess the progress of a project and plan its next steps. This allows a project’s direction to be adjusted or reoriented based on completed work, not speculation or predictions.

This emphasis on an ongoing assessment of completed work is largely responsible for its popularity with managers and developers. But what allows Scrum to work is a simple set of roles, responsibilities, and meetings that never change. If Scrum’s capacity for adaption and flexibility makes it an appealing option, the stability of its practices give teams something to lean on when development gets chaotic.

Our South American resources in Uruguay and Chile are particularly suited for augmenting North American Scrum teams because of their time zone proximity, similar cultural norms and ability to communicate in English. We have modified the process and added collaboration tools to fully support remote and distributed development. Our South American resources are as effective as if they were working onsite.