Akarisoft's transition to an agile development model began in 2010 to create a structured product range, focusing on localization and enhancing production efficiency. Key agile principles emphasize customer satisfaction, collaboration, and continuous improvement, while ensuring sustainable development and technical excellence. The successful adoption of product-line development has been a significant factor in Akarisoft's progress, with ongoing funding for advancements in this field.

1. Paraic Hegarty, CTO
phegarty@akarisoftware.com

2.  A product family had been created without the
underlying structure and processes needed to ensure
the efficient creation and maintenance of variants
 In 2010, the Company began making internal changes
to develop a product range infrastructure
- Localisation was a particular concern
 The Company also took the opportunity to switch to
an agile model of software development
 Benefits included enhancing the production cycle and
facilitation of a general programme of ongoing
improvement

3. 1. Our highest priority is to satisfy the customer through early and continuous delivery of
valuable software.
2. Welcome changing requirements, even late in development. Agile processes harness change
for the customer’s competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a
preference to the shorter timescale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support they
need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a
development team is face-to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers, and users
should be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity--the art of maximizing the amount of work not done--is essential.
11. The best architectures, requirements, and designs emerge from self-organizing teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and
adjusts its behavior accordingly.

4.  Simplicity – the art of maximising the amount
of work not done – is essential

5. DoToo Much
Work
Do Not
EnoughWork
Over-Engin
eer
Accumulate
Debt

6.  “a set of software-intensive systems sharing a
common, managed set of features that satisfy
the specific needs of a particular market
segment, or mission and that are developed
from a common set of core assets in a
prescribed way.”
Clements and Northrup

8. Number of products
Cost
Break even point
Product line development
Traditional development

9. Number of products
Cost
Break even point
Product line development
Traditional development

11.  TeamworkPM,TeamworkCMS
 Confluence, JiraAgile,Agile Cards
 Stash, Bitbucket, Crucible
 Bamboo, MXUnit, Junit

15.  Refactoring
 Databases
 PDF output
 Localisation
 Translate functions
 Text embedded in images
 Replacement of system alerts
 ConfigurationTool
 Country/Education Systems
 Developer/distributor/administrator settings
 Groups of settings based on business decisions

16.  Unit tested
 Localised
 Code reviewed
 Refactored
 Documented
 Release Notes
 Checked in
 Jira updated
 Product Owner
Acceptance
 Migrated toTest
Environment
 ManuallyTested
 W3C Compliant

17.  Existing story cards stated:
 WHO wants it? (as a…)
 WHAT is required? (I want to be able to…) and
 WHY? (So that…)
 For Acceptance, we also need to know:
 WHERE in the application should the functionality be
accessible?
 WHEN (in what circumstances) should the
functionality be available?
 HOW should it behave or look? and
 WHETHER the functionality should be switched on or
off (switches and defaults)

18.  From
 Half Ready
 In Progress
 Done, but…
 To
 Ready
 Joint Design
 In Progress
 Code Review
 QA
 Done

19. SCRUM FOR PRODUCT
BACKLOG ITEMS
KANBAN FOR BUGS &
OPERATIONS

20.  Full test automation / continuous integration
 Test First Development

21.  Early adoption

22.  Early adoption
 Think ahead

23.  Early adoption
 Think ahead
 Flexibility

24.  Early adoption
 Think ahead
 Flexibility
 Single code base

25.  Work was significantly underestimated, and is
still in progress
 The transition has been very successful for Akari
Software
 Agile adoption a major success factor
 Product-line development not just for Large
enterprises
 The product-line concept is now well established
as evidenced by development of ISO/IEC 26550
 Work on further advances in the field continues
to be funded