SÄHKÖISTEN PALVELUIDEN ARKKITEHTUURI- JA RAKENNUSTOIMISTO

SÄHKÖISTEN PALVELUIDEN ARKKITEHTUURI- JA RAKENNUSTOIMISTO

Customer Communication in Agile Software Development Projects 23.9.2014

Structure Salum Abdul-Rahman (me) & Gofore (Some slides in Finnish, deal with it) Theory of Communication Agile vs Waterfall Communication Toolbox Relationship Development

Salum Abdul-Rahman BSc Automation and System Technology from Aalto University 2003-2010 MSc Information Technology Tampere University of Technology 2010-2014 Part-time in IT service / software development since 2007, Full time since 2013 Areas of interest: Open Source Project Management Agile SWD Knowledge Management

Software and Services WHAT IS GOFORE

Our Mission To save finnish society by improving productivity by implementing better information systems.

Gofore lyhyesti IT-johdon konsultoinnin ja tietojärjestelmien kehittämisen asiantuntijayritys Vahvassa kasvussa liikevaihto 6 MEUR (2013) Yhteensä 80 asiantuntijaa Helsingissä ja Tampereella perustettu v. 2001 Taloudellisesti vakavarainen liikevoitto yli 10 % viimeiset yhdeksän vuotta ASIAKASTYYTYVÄISYYS Yli 98 % asiakkaista pitää ratkaisujamme ja palvelujamme parempina tai saman tasoisina kuin kilpailijoilla. Asiakastyytyväisyystutkimus 12/2013, Innolink Research HENKILÖSTÖTYYTYVÄISYYS Työilmapiirin kouluarvosana 9,47 Yhteishenki 9,45 Suvaitsevaisuus 9,30 Tasavertainen kohtelu asemastani riippumatta 9,39 Tasa-arvoinen kohtelu sukupuolestani riippumatta 9,67 Henkilöstötyytyväisyystutkimus 11/2013, Barona IT

Kehitys ja historia

Palvelutarjonta ARKKITEHTUURITOIMISTO IT-johdon asiantuntijapalvelut Arkkitehtuurikonsultointi Kehityshankkeiden valmistelu ja johtaminen Avoimen tiedon palvelut RAKENNUSTOIMISTO Tietojärjestelmien kehityspalvelut UX-palvelut Ohjelmistokehityspalvelut Jatkuvat palvelut Kokonaisarkkitehtuurin hallinnan palvelu Kartturi

Fokuksessa julkishallinto VAHVA TOIMIALAOSAAMINEN Liikenne Älyliikenne Liikenteen ohjaus ja hallinta Joukkoliikenne OPETUSALAN EKOSYSTEEMIN INTEGRAATTORI Opetus Koulutusjärjestelmien digitalisoinnin murros TOIMITTAJARIIPPUMATON ARKKITEHTUURIKUMPPANI Hyvinvointi Hyvinvointi uudistuksen kourissa o o o Sote-uudistus Potilaan voimaannuttaminen, omahoito Potilasjärjestelmien elinkaari

Some Past Projects Consulting Finnish Transport Agency Finnish National Board of Education Software Development Occucapational Safety and Health Administration Avoindata.fi Kela.fi

Consulting Projects Finnish Transport Agency Traffic Infromation Architecture specification Service Oriented Traffic Infromation System Architecture Design Finnish National Board of Education Combining different service providers with end user driven service design System architecture specification Process modelling SOA -design

Tehokkuutta työsuojeluhallinnolle Tehokkuutta uudella tietojärjestelmällä Työsuojeluhallinnossa vuosittain 25 000 työsuojelutarkastusta Gofore toimittajaksi julkisen kilpailutuksen kautta Toteutus osaprojekteissa v. 2010 2013 palvelukeskeinen arkkitehtuurimalli KuntaIT:n SOA-teknologialinjausten mukainen toteutus ketterä iteratiivinen prosessimalli Julkisen sektorin tuottavin tietojärjestelmähanke 2006 2012

Valtori tiedon avaamisen työkalut avoimesti ja ketterästi Julkinen data avoimeksi ja käyttöön hallitusohjelman kestävän talouskasvun sekä työllisyyden ja kilpailukyvyn vahvistaminen Työkalut julkishallinnolle avoimesti ja ketterästi avoimen lähdekoodin tuotteilla (mm. CKAN, Drupal) ympäristöt pilvestä Täysin uusien palveluiden kehittäminen kansallisen avoimen datan portaalin kehittäminen kansallisen palvelutietovarannon kehittäminen kansallisen yhteentoimivuusportaalin kehittäminen prototyyppien ja demojen tekeminen osana uusia palveluita

Ketterästi Kelalle Kela.fi-palvelu suosittu julkishallinnon verkkopalvelu Gofore julkisen kilpailutuksen voittajaksi parhailla laatu- ja hintapisteillä Ketterä toteutus Domino-ympäristöstä Liferay-portaalipalvelimen päälle mm. Scrum-menetelmän käyttö Täydellinen ilme- ja käyttöliittymäuudistus kela.fi-palvelu suunnannäyttäjänä julkishallinnon verkkopalveluissa

Asiakkaitamme A-Insinöörit Alma Media Barona Group Cargotec CSC Tieteen tietotekniikan keskus Elisa Eläketurvakeskus Enfo Eniro Finland FCG Fimlab Laboratoriot Oy Fonecta Helsingin yliopisto Ideapark Kansalliskirjasto Kansaneläkelaitos Kauppalehti Kuntaliitto Labkotec Liikennevirasto Liikenteen turvallisuusvirasto Medbit Oikeusministeriö Oikeusrekisterikeskus Opetushallitus Opetus- ja kulttuuriministeriö Patentti- ja rekisterihallitus Pirkanmaan ELY-keskus Pirkanmaan sairaanhoitopiiri Puolustusvoimat Rikosseuraamuslaitos Satakunnan sairaanhoitopiiri Sosiaali- ja terveysministeriö Sponda Suomi24 Tampereen ammattikorkeakoulu Tampereen ev.lut. seurakuntayhtymä Tampereen kaupunki Tampereen sähkölaitos Terveyden ja hyvinvoinnin laitos Turvallisuus- ja kemikaalivirasto Työ- ja elinkeinoministeriö Valtori Valtiovarainministeriö Vantaan kaupunki Varsinais-Suomen sairaanhoitopiiri

Theory of Communication

Communication Sender Channel Receiver Medium Message - Symbols Other Models http://en.wikipedia.org/wiki/models_of_communication

Wiio's laws Communication usually fails, except by accident. If communication can fail, it will. If communication cannot fail, it still most usually fails. If communication seems to succeed in the intended way, there's a misunderstanding. If you are content with your message, communication certainly fails. If a message can be interpreted in several ways, it will be interpreted in a manner that maximizes the damage. There is always someone who knows better than you what you meant with your message. The more we communicate, the worse communication succeeds. The more we communicate, the faster misunderstandings propagate. In mass communication, the important thing is not how things are but how they seem to be. The importance of a news item is inversely proportional to the square of the distance. The more important the situation is, the more probably you forget an essential thing that you remembered a moment ago.

Agile Software Developement

Waterfall customer communication Marketing, Sales Negotiations Requirements specification Progress reports QA reports Documentation Handoff, Thank you s, and Assigning Blame.

Manifesto for Agile Software Development We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more.

Waterfall vs. Agile More communication More informal communication More unstructured communication Better communication

Waterfall vs. Agile Documentation is Communication Less documentation? More relevant documentation Updated documentation Condensed expression Availailability of documentation Predefined communication

Waterfall vs. Agile Agile is for people Individuals and interactions not roles Customer collaboration Contract negotiation Trust is established through communication and delivered software

Agile is freedom! Be systematic in choices of communication Agile is iterative, improve your communication Find the communication methods and tools that work for your project Every project is different Don t be blinded by the Dream Team When the project is over the Documentation is the only way you are still communicating with the customer?

Freedom is Responibility Agile teams have have more personal freedom Agile teams have more personal responsibility Responsibility Tools Features Methods Communication

A Word on contracts Waterfall contracts should allow for changemanagement during the project Agile contracts need to reflect agile values Change in personel is a big issue

Communication toolbox

What is valuable in communication Timing (Speed, Predictability) Exacteness Persistence Trust

What are you talking about (Message) Business Cases Requirements Management Configuration Management Project Management Feedback

Customer Needs Every choice a developer makes is a business decision. The customer can not be informed about every decision made Communication requires effort

Balance Between Communication Costs Quality Low communicationn threshold Time needed Developer Customer

Expressions (Symbols) Unstructured Natural languages Pictures Diagrams Charts Video Animation Protoypes Non-functional Functional Structured Ontologies Domain Models System Models Domain Specific Languages Descriptive Computable

Unstructured Natural languages Informal communication necessary for relationship development Inexact Expressive Tools provide structure Use cases User stories Bug reports

Pictures Information Visualization Charts Diagrams Video Effort cost Animation tools Easy to use Easy to misuse

Prototypes Picture Paper prototypes Mock devices/environments Tool for facilitating communication

Structured Ontologies Domain Models System Models Domain Specific Languages Descriptive Computable

Methods (Medium) Personal Meetings Instant messaging Email Issue trackers Wikis Documents

Shared Space Personal Relationship Meetings Efficiency of information transfer decreases with size Being a good President or Secretary requires skill Working together

Through the Screen Instant messaging Email

Virtual Shared Space Issue trackers Usability vs functionality Project workflow fit Wikis Searchability Learning curve Accessibility Update

Documents As static as you want to be Mix and match content Persistent? Usability?

Publicity of Communication Organizational client Department boundary Company boundary Open Source development

Relationships

Realtionship Management Business Value Personal Relationships Professionalism Roles Customer Aptitude

Professionalism Be trustworthy Be confident Know when/where to vent Don t over do it. Don t Be A Dick

Roles Developer QA UX Project Manager Customer Project Manager Specialists

Roles (Scrum) Developer Product Owner Scrum Master Customer

Customer Domain Expertise Technical Expertise Communication Skills Lanuage profiency Tool profiency Relationship Respect Trust

After the Project Do not unjustly criticize previous clients by name. Constructive criticism? Maintaining the relationship?

Conclusion Everything that the customer can observe is communication Choose the best tools Improve Build trust Don t be a dick. (Wheaton s Law) "Communication usually fails, except by accident (Wiio's 1st law)

Questions & Discussion

Email: salum.abdul-rahman@gofore.com Twitter: @salum_ar FEEDBACK