Paraic Hegarty, CTO
phegarty@akarisoftware.com
 A product family had been created without the
underlying structure and processes needed to ensure
the efficient creation...
1. Our highest priority is to satisfy the customer through early and continuous delivery of
valuable software.
2. Welcome ...
 Simplicity – the art of maximising the amount
of work not done – is essential
DoToo Much
Work
Do Not
EnoughWork
Over-Engin
eer
Accumulate
Debt
 “a set of software-intensive systems sharing a
common, managed set of features that satisfy
the specific needs of a part...
Number of products
Cost
Break even point
Product line development
Traditional development
Number of products
Cost
Break even point
Product line development
Traditional development
 TeamworkPM,TeamworkCMS
 Confluence, JiraAgile,Agile Cards
 Stash, Bitbucket, Crucible
 Bamboo, MXUnit, Junit
 Refactoring
 Databases
 PDF output
 Localisation
 Translate functions
 Text embedded in images
 Replacement of sys...
 Unit tested
 Localised
 Code reviewed
 Refactored
 Documented
 Release Notes
 Checked in
 Jira updated
 Product ...
 Existing story cards stated:
 WHO wants it? (as a…)
 WHAT is required? (I want to be able to…) and
 WHY? (So that…)
...
 From
 Half Ready
 In Progress
 Done, but…
 To
 Ready
 Joint Design
 In Progress
 Code Review
 QA
 Done
SCRUM FOR PRODUCT
BACKLOG ITEMS
KANBAN FOR BUGS &
OPERATIONS
 Full test automation / continuous integration
 Test First Development
 Early adoption
 Early adoption
 Think ahead
 Early adoption
 Think ahead
 Flexibility
 Early adoption
 Think ahead
 Flexibility
 Single code base
 Work was significantly underestimated, and is
still in progress
 The transition has been very successful for Akari
Soft...
Agile Tour Dublin 2013 - Product Lines and Agile
Agile Tour Dublin 2013 - Product Lines and Agile
Agile Tour Dublin 2013 - Product Lines and Agile
Agile Tour Dublin 2013 - Product Lines and Agile
Agile Tour Dublin 2013 - Product Lines and Agile
Upcoming SlideShare
Loading in …5
×

Agile Tour Dublin 2013 - Product Lines and Agile

206
-1

Published on

Presentation to Agile Tour Dublin 2013 on implementing a Product Line infrastructure in an Agile environment

Published in: Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
206
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • SMEBespoke project8 additional customersLooking at EHEA
  • You can do too much or too little but almost impossible to do just enough
  • Technical variantsFunctional variants – deliberate & accidentalHad to quantify effect due to refactoring & mix of technologies
  • Schmid & Verlage ‘Software’ IEEEInitally more expensiveThen breaks even & generates additional ROI
  • In practice, it’s about the area under the line
  • Needed an approach for the teamDecided on AgileTotal immersionBackground hi-techLow-tech info radsScrum & KanbanSprint efficiencyHalo effect
  • Had to bite the bulletNeeded new capabilityPartnered with UlsterSeparate but integrated
  • Localisation led to refactoringNor in EHEA but for NUIG1,000 language strings, 50 images & system dialoguesLess code instances but more callsneeded test automationNeeded easy way to configure & deploy
  • We adopted early but should have done even earlier
  • Huge debt had built up
  • Without over-engineeringe.g. language
  • Further debt
  • Agile Tour Dublin 2013 - Product Lines and Agile

    1. 1. Paraic Hegarty, CTO phegarty@akarisoftware.com
    2. 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. 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. 4.  Simplicity – the art of maximising the amount of work not done – is essential
    5. 5. DoToo Much Work Do Not EnoughWork Over-Engin eer Accumulate Debt
    6. 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
    7. 7. Number of products Cost Break even point Product line development Traditional development
    8. 8. Number of products Cost Break even point Product line development Traditional development
    9. 9.  TeamworkPM,TeamworkCMS  Confluence, JiraAgile,Agile Cards  Stash, Bitbucket, Crucible  Bamboo, MXUnit, Junit
    10. 10.  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
    11. 11.  Unit tested  Localised  Code reviewed  Refactored  Documented  Release Notes  Checked in  Jira updated  Product Owner Acceptance  Migrated toTest Environment  ManuallyTested  W3C Compliant
    12. 12.  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)
    13. 13.  From  Half Ready  In Progress  Done, but…  To  Ready  Joint Design  In Progress  Code Review  QA  Done
    14. 14. SCRUM FOR PRODUCT BACKLOG ITEMS KANBAN FOR BUGS & OPERATIONS
    15. 15.  Full test automation / continuous integration  Test First Development
    16. 16.  Early adoption
    17. 17.  Early adoption  Think ahead
    18. 18.  Early adoption  Think ahead  Flexibility
    19. 19.  Early adoption  Think ahead  Flexibility  Single code base
    20. 20.  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

    ×