Est. 2004

Unified Digital Group, LLC

Our Development Process

Disciplined Agile Delivery (DA) is the distillation of several software development methods and practices, derived primarily from mainstream Agile methods, as well as other more rigorous methodologies such as Rational Unified Process (RUP).

The DA process addresses the full delivery lifecycle while adopting strategies from other Agile and Lean methods. Many of our DA-based practices are standard within the Agile community and include:

  • Scope and project vision
  • Architectural vision
  • Gathering and elaborating requirements
  • Proven code architecture and data modeling
  • Iterative feedback and change re-integration
  • Joint daily or weekly team coordination meetings

The Disciplined Agile process framework is a hybrid model that Unified Digital has adopted and tailored strategies from a variety of sources. As a hybrid framework certain activities are optional, or modified as need. The amount of upfront planning needed is dictated by the type of the engagement, how much is known about the need, the customer/end-user and whether an existing or new product.

Some common rules of our practice include flexibility to modify and adapt to different types of engagements as well as changing conditions during the course of a given project. We also do not adopt any process merely for its own sake, rather, we will incorporate aspects of the methodology that make sense for this specific engagement.

Another hallmark of the way Unified Digital manages a project is described in the next section. Project vision evolves and is refined over time as greater knowledge and understanding is gained.

Derived from agile modeling, we place significant importance on upfront analysis, planning, and documentation. While this activity will be thorough, it is not excessive, we coordinate our efforts in this Phase up until that point of capturing information that is known and fully comprehended, but no further.

We rely on requirements envisioning, architectural envisioning, and iteration modeling during inception and continuous documentation and just in time model storming during the life of the project.

As part of a just-in-time approach, we recommend deferring planning decisions, detailed design decisions, and explicit requirements – until the most appropriate time. We know requirements and business conditions evolve, consequently we want to capture information when it’s most relevant and timely. Through use of these practices, we have the flexibility to accommodate evolving user needs and changing functional requirements.

As part of methods, borrowed from RUP, we seek to incorporate Governance strategies that allow us to focus on the importance of proving the Recommended Architecture works early in the process, reducing business risk early in the project lifecycle.

For complex project we have adopted and tailored the Scrum practice of working from a stack of issues or work products in priority order. We manage the project by employing a release management process that relies on a series of iterations rolled up into *Releases *which results in periodic batches of working and testable software.

Our combined project teams will select prioritized iterations and define lengths, typically one to two weeks. By the end of each release, the developers will be responsible for delivering fully usable code for a particular subset of the application.

As part of each iteration the team will specify regular testing and schedule and automate these tasks. Once the development, continuous code integration and Unit, Functional and User Acceptance Testing (UAT) activities are completed, the release takes place and the process begins again. This cycle repeats until development is complete, at which point transition and delivery begin.

The Disciplined Agile lifecycle management methodology explicitly calls out three phases:

  • Inception. During this phase of the project initiation activities occur. In our Inception Phase we do fairly lightweight visioning activities to properly frame the project. The goals of this phase includes:

    • Clarifying the business problem that needs to be solved
    • Identifying a viable technical solution
    • Planning our collaborative approach
    • Setting up the work environment and team
    • Gaining stakeholder agreement that it makes sense to proceed with investing in the implementation of the chosen strategy

DA does not include an explicit Elaboration phase. However the milestones for elaboration are still in DA and are performed during the Inception phase. All agile methods seek to deliver value into the hands of the stakeholders as quickly as possible. In many if not most large enterprises it is difficult to actually deliver new increments of the solution at the end of each iteration. DA therefore recognizes this reality and assumes that in most cases there will be a number of iterations of Construction before the solution is actually deployed to the customer.

  • Construction. During this phase our Team will produce working versions that are usable, with each subsequent iteration improving on functionality on an incremental basis. Construction activity proceeds as a set of iterations which correspond to a specified Release. Within the iterations, are discrete set of tasks and work is accomplished in a lean, continuous flow. The team applies the designated practices selected for this engagement to deliver the proposed solution.

  • Transition. We recognize that deploying the solution to the enterprise stakeholders will not be a trivial exercise. We will seek to coordinate with the IT, marketing and end-user teams to streamline the deployment processes so that over time this activity becomes routine and subsumed into continuous deployment activities.