T Iteration Demo Neula I1 Iteration

Agenda 2 Introduction - Our key issues Status of the iterations goals and deliverables Technical Overview and Demo Resources and progress Quality status Changes to the project Risks Other results of the project

Introduction to the project 3 Increased usability Value for customers Brand recognition Enabling external development … For which Suunto’s goals are… … Which means that our key issues are… Understanding the customers – Suunto and its users Understanding possiblities for sports web 2.0 High level of collaboration – as external developers We are creating gadgets…

4 Introduction - Our key issues Status of the iterations goals and deliverables Technical Overview and Demo Resources and progress Quality status Changes to the project Risks Other results of the project

Status of the iteration’s goals and deliverables 5 3 gadgets with working functionality 5 Gadget prototypes 10 more prototype descriptions Course documents Implement the quality assurance measures Implement the project management measures Learning the platforms Platform documents Decisions with Suunto 2 new gadgets Goals Difficulties and decisions Status 2 Gadgets that will be developed to commercial Being reviewed by Suunto 2 Gadgets that will be developed to commercial Being reviewed by Suunto Platform documents 2 new gadgets: 1 new platform, 1 new gadget 2 new gadgets: 1 new platform, 1 new gadget 3 new prototype descriptions Difficulty of gadgets Done Progress report

6 Introduction - Our key issues Status of the iterations goals and deliverables Technical Overview and Demo Resources and progress Quality status Changes to the project Risks Other results of the project

Technical Overview and Demo A1 Architecture Demo A2 RelayChallenge Facebook SimpleMeter iGoogle 1.Functional view 1.Parts and interconnections 2.Development view 1.Class diagram Architecture Demo 1.Functional view 1.Parts and interconnections 2.Development view 1.Class diagram

JavaScript source code External data interface My Suunto DB API iGoogle Canvas Application A1: SimpleMeter Application server Google DB User Browser Images Style Sheets Hosting of Functional view

LoggingViewViewCommons Simple Meter View SimpleMeter Engine LanguageUtils Database Accessors Google DB Use Google Simplemeter Preferences API Google DB My Suunto DB API My Suunto Development view

Simple Meter iGoogle Demo A1

Technical Overview and Demo A1 Architecture Demo A2 RelayChallenge Facebook SimpleMeter iGoogle 1.Functional view 1.Parts and interconnections 2.Development view 1.Class diagram Architecture Demo 1.Functional view 1.Parts and interconnections 2.Development view 1.Class diagram

User interface External data interface Facebook user data My Suunto DB API Application server Application A2: Relay challenge API Facebook Browser DB Shown in User Browser Functional view

HTTP GET/POST Mapper ActionsPages Permission/ logic ManagersConnectors Databases Connectors Managers Controllers

The Relay Challenge Facebook Demo A2

15 Introduction - Our key issues Status of the iterations goals and deliverables Technical Overview and Demo Resources and progress Quality status Changes to the project Risks Other results of the project

Earned value of development work compared to the initial goals of the project 16 Total hours realized for the whole team (week 49): 825 out of 1494 Total development hours: 322,5 out of 624

Used hours Team totals Developers

Tasks 18 The planned total development hours was 567 We have a total of 624 development hours We have been able to minimize non-productive work.

Development work PlannedRealized 322,5 / 624 development hours used 2 gadgets of working functionality. 10% decrease in work load 4 working quality gadgets. 3 commercial quality and 1 working functionality?

20 Introduction - Our key issues Status of the iterations goals and deliverables Technical Overview and Demo Resources and progress Quality status Changes to the project Risks Other results of the project

Development Process and Quality Simultaneous development of autonomous tiny applications Three predefined qualitative levels of quality as a custom framework

Current Quality Palette Quality Goal vs. Quality Practice (effect 1 - 3) QG 1 Compatibility QG 2 Layout QG 3 Usability QG 4 Localization QG5 Innovativeness QG 6 Exploration QG 7 Variety Unit testing X  1X  1 Test cases X  1X  1X  1X  1X  1 Explorative testing X  2X  2X  2X  2X  2X  2X  1X  1 Coding standards X  1X  1 Side-by-side programming X  3O  2O 3O 3X  3 Code reviews X  2O  2 Heuristics X  2X  2X  1X  1 Documentation X  1X  1X  1X  1X  2X  2 General project management X  3X  2X  2X  2X  2 Dialogue with the customer X  3 X  2X  2 Green = Used frequentlyYellow = Used time to timeRed = Rarely used

Defect Statistics Defect reporting not considered very important at this phase  Side-by-side programming and communication helps fixing minor errors in practice

Code Statistics RelayChallenge 2795 lines SimpleMeter908 lines  Selected coding standards too narrow and time consuming vs. opportunity cost (in lost development time)  Value-added?

Quality Summary Practices have to be value-adding Preliminary quality plans altered – Unit testing in minor role (web development limitations) – Test cases will be executed mostly as acceptance testing  leaving integration and system levels debatable – Defect reporting mostly academic exercise in I1 Coding standards need reviewing

26 Introduction - Our key issues Status of the iterations goals and deliverables Technical Overview and Demo Resources and progress Quality status Changes to the project Risks Other results of the project

Changes to the project Project planning iteration: Iteration 1: 27 Sprint cycle Iteration cycle Requirements cycle Goal discussion Learning Insufficient documentation Insufficient documentation Platforms New platforms is a priority Documenting platforms Commercial quality is the priority The priority is to complete the A1 and A2 gadgets to commercial quality and develop A3 and A4 to working functionality. A3: new gadget for Vista A4: Same gadget for OpenSocial

28 Introduction - Our key issues Status of the iterations goals and deliverables Technical Overview and Demo Resources and progress Quality status Changes to the project Risks Other results of the project

Risks 29 Customer satisfaction of designs and working practices risks minimized Sharing of tacit knowledge started and will be continued More time has gone to learning the technology platforms The interfaces from Suunto have not been opened yet. The technology platforms are not documented as well as expected According to the contingency plan: 1.Goals have been adjusted 2.Schedule has been adjusted to be more flexible IDRiskEffectHow to avoidContingency planResponsibleSeverityProbability at start of project Probability R1The customer is not satisfied with the prototype descriptions We run out of time because it is too difficult to innovate good enough gadgets Concentrate on a pre-defined process and rules for the prototype descriptions and the creation of backlog Set a deadline for new gadget descriptions, demand input from Suunto, begin to implement after the deadline Paavo Häppölä540 R2Team cannot find common ground for communications and meeting practices Time is wasted and we never get to the implementation phase Start meetings early in the project and discuss the issues Split team up into smaller parts that have their own meetings. Share responsibility Riku Seppälä540 R3The documentation is not done properly, the customer is only given source code but no exchange of tacit knowledge is made The project doesn't benefit Suunto as much as planned Concentrate on the documentation and ask for feedback from Suunto Create the documentation after the project is finished. Riku Seppälä352 R4Communication doesn't work, Suunto doesn't understand what we're doing and we don't know about their requirements The targets are not met, we deliver an unusable product Plan enough meetings and send clear descriptions of gadgets to be implemented, not just a description of functions. Engage Suunto in the innovation process Add meetings to discuss communication issues Paavo Häppölä552 R5The workload is distributed unevenly Some members get frustrated and others not engaged. Quality suffers and no one enjoys the project Have set times for working together and a weekly meeting where everyone has to be present or have a legitimate reason for not being present. Follow up on tasks accomplished and concentrate on scheduling Remake the teams and delegate more responsibilites Riku Seppälä341 R6Most of the time is spent for optimizing for the course requirements and not for the actual project outcomes Customer and project members are dissatisfied Keep documentation light and let project manager handle the documentation for the course. Everyone doesn't have to be involved, keep everyone up-to- date at meetings instead Concentrate more on the customer needs. Riku Seppälä454 R7The needed technologies can not be mastered in time. We are not able to make the prototype descriptons reality The goals cannot be metConcentrate on what is most important, the important functionalities and leave the most difficult implementations to the end. Don't promise too big. Go back to the designs and design simpler gadgets. Use more familiar technologies Eero Palomäki545 R8Important persons from the customer side cannot be reached Time runs out. The requirements elicitation takes up too much time. Know when people are present. Use the telephone for communications. Have set practices and deadlines for gathering requirements Take more control of requirementsRiku Seppälä341 R9The technologies and support needed from the client cannot be delivered on time Time runs out. The development becomes unneccesarily difficult, development effort goes to creating dummy interfaces etc. Understand the requirements, keep in contact with the IT of Suunto Lower the goalsEero Palomäki345 R10Used tools and technologies are poorly supported and development becomes difficult Time runs out.Use well documented and/or familiar tools and technologies Switch to other tools, lower the goals Eero Palomäki525 R10Because of implementing the interfaces, we're not able to finish the gadgets Time runs out.When we get the interfaces, start implementing them right away for the gadgets that have been developed already. Chnage the goalsEero Palomäki523 1 New risk has been identified: Time pressure from implementing the interfaces.

30 Introduction - Our key issues Status of the iterations goals and deliverables Technical Overview and Demo Resources and progress Quality status Changes to the project Risks Other results of the project

Reflection workshop Is there anything that could be done better to help the development work? Are the communications working properly? Key Issues A lot of time is spent figuring out how to fit the development to the quality practices A lot of time is spent mending the code to the coding standards – but it doesn’t improve readability Complaints To save time for coding, we will not follow the coding standards too rigorously. It doesn’t improve readability of the code. Communications are working very well, the Friday meetings are very good, information flows and everyone knows what’s going on. Improvements