Working Methodology

For any project or product development Activation will form one or more agile teams and assign resources to different agile roles.

Agile development methodology provides opportunities to assess the direction of a project throughout the development lifecycle. This is achieved through regular cadences of work, known as sprints or iterations, at the end of which teams must present a potentially shippable product increment. By focusing on the repetition of abbreviated work cycles as well as the functional product they yield, agile methodology is described as “iterative” and “incremental.” In waterfall, development teams only have one chance to get each aspect of a project right. In an agile paradigm, every aspect of development — requirements, design, etc. — is continually revisited throughout the lifecycle. When a team stops and re-evaluates the direction of a project every two weeks, there’s always time to steer it in another direction.

The results of this “inspect-and-adapt” approach to development greatly reduce both development costs and time to market. Because teams can develop software at the same time they’re gathering requirements, the phenomenon known as “analysis paralysis” is less likely to impede a team from making progress. And because a team’s work cycle is limited to two weeks, it gives stakeholders recurring opportunities to calibrate releases for success in the real world. Agile development methodology helps companies build the right product. Instead of committing to market a piece of software that hasn’t even been written yet, agile empowers teams to continuously replan their release to optimize its value throughout development, allowing them to be as competitive as possible in the marketplace. Development using an agile methodology preserves a product’s critical market relevance and ensures a team’s work doesn’t wind up on a shelf, never released.

Quality Control and Testing process

Agile process itself provides the quality assurance and control. Agile builds quality into the product through a combination of practices from Agile Project Monitoring and Control and Agile Project Execution.

Activation’s development process is solely aligned with the core Agile principles that inherently ensures quality of the product. Following are some key criteria that ensures the the a flawless product is developed in every iteration.


Each Timebox is meant to result in releasable code. Although meeting the Product Owner’s expectations is a priority it is not the only criteria. Releasable software: Meets the Product Owner’s expectations given features asked for and the Timeboxes completed so far Meets agreed coding standards Has to best design for the currently implemented features (via refactoring) Is easily maintainable (via refactoring) Has been tested to the satisfaction of the team and relevant stakeholders


The product is formally reviewed in the Timebox Review Meeting at the end of each Timebox. You can schedule more formal reviews during the Timebox, and for longer Timeboxes (say 3 or 4 weeks) this is a good idea. DSDM mandates the results of these reviews are documented. I think this is a good idea but I’m not too tied to review documents. I recommend documenting the reviews in the same was as I described in the Unscheduled Product Reviews, i.e. an email to the relevant



The team monitors project progress in the Daily Team Meeting. It is also an opportunity to review whether the team is following the agree approach.


Each User Story has at least one acceptance criteria. The acceptance tests elaborate the brief description provided by the User Story. They define the scope of the story and clarify the Product Owner’s intent with concrete examples. This clarifies the Product Owner’s intent, points the team in the right direction, and confirm when the intent has been met.

Where possible Acceptance Tests should be automated. As with the automated unit tests, the suite of automated acceptance tests become regression tests, validating that the customer’s intent continues to be met by the software after each change to the code. You won’t automate all Acceptance Tests – it won’t be possible to automate some and others won’t be cost-effective to automate. But if you want the test repeated as part of a Regression Test then it is better to automate. If you can write a test so that a person can repeat the steps consistently then you can probably write a automated test and let the computer repeat the steps even more consistently.


A regression test is the repeat of an earlier test. Usually that means Unit Tests and Acceptance tests. Regression tests ensure that changes to the software have not broken good code. My experience is that if regression tests are manual they don’t happen. It is with regression testing that the real value of test automation is shown.


Exploratory Testing uses un-scripted tests to quickly identifying new types of problems with the software. Show stoppers (such as system crashes or unhandled errors) are usually fixed immediately. Less serious problems might be deferred. This testing might also reveal new User Stories to be scheduled into later Timeboxes.


The Two Pairs of Eyes approach provides a peer review of code to check it follows agreed coding standards, conforms to design guidelines and is easily understood by developers other than the author. This can be either through pair programming or more traditional code reviews/walkthroughs.


Retrospectives are the mechanism most Agile teams use for reflection. During a Retrospective the team looks at how well the Timebox went and what they can do different. The high priority changes become User Stories to go into the Release Plan for implementation. Often this is the process to implement new Agile processes.