Scrum - iteracyjna metodyka prowadzenia projektów, zaliczana do metodyk zwinnych, zgodnych z manifestem Agile.
Prezentacja znaleziona w śmieciach na dysku :) Wykonana w 2004 roku
Wielu Scrum Masterów nie ma pomysłu lub ma trudności z prowadzeniem wartościowych Retrospekcji Sprintu. Młodzi, niedoświadczeni adepci tej sztuki często ograniczają się do jednej dobrze przećwiczonej metody. Najgorzej, kiedy jest to wariacja oparta na plusach i minusach lub ćwiczeniu rozgwiazda. Każdy zespól to widział i szybko się znudzi. Z tego powodu, retrospekcja staje się "koniecznym złem” dla zespołu, nudnym spotkaniem, które nie przynosi żadnej wartości. Zespół przestaje się angażować. Dlatego warto poszerzać warsztat i sprawdzać inne metody. Dzisiaj chciałabym Ci przedstawić Retrospekcję z wykorzystaniem niedawnej zmiany w Scrum Guide - dodanych Wartości Scrum.
Dlaczego developerzy nie lubią scrum Zwinna ŁódźKrystian Kaczor
Scrum jest z nami od 1995, ale tak naprawdę pod polskie strzechy zawitał stosunkowo niedawno. W ostatnich pięciu latach zainteresowanie Scrum w Polsce nieustannie rosło. W tej chwili albo już pracujesz w czymś przypominającym Scrum, albo za chwilę będziesz. Developerzy nawet pomimo początkowej ekscytacji szybko zniechęcają się do nowego sposobu pracy. Zaczyna się hejt i marudzenie. Pomimo całej samo-organizacji i zbliżenia do użytkownika pojawia się opór i postawa obronna. Dlaczego tak się dzieje? Czy to problem z developerami? Jak przeciwdziałać problemom i sprawić, żeby praca w Scrum była przyjemna i motywująca? Opowiem o tym podczas mojego wystąpienia.
Scrum - iteracyjna metodyka prowadzenia projektów, zaliczana do metodyk zwinnych, zgodnych z manifestem Agile.
Prezentacja znaleziona w śmieciach na dysku :) Wykonana w 2004 roku
Wielu Scrum Masterów nie ma pomysłu lub ma trudności z prowadzeniem wartościowych Retrospekcji Sprintu. Młodzi, niedoświadczeni adepci tej sztuki często ograniczają się do jednej dobrze przećwiczonej metody. Najgorzej, kiedy jest to wariacja oparta na plusach i minusach lub ćwiczeniu rozgwiazda. Każdy zespól to widział i szybko się znudzi. Z tego powodu, retrospekcja staje się "koniecznym złem” dla zespołu, nudnym spotkaniem, które nie przynosi żadnej wartości. Zespół przestaje się angażować. Dlatego warto poszerzać warsztat i sprawdzać inne metody. Dzisiaj chciałabym Ci przedstawić Retrospekcję z wykorzystaniem niedawnej zmiany w Scrum Guide - dodanych Wartości Scrum.
Dlaczego developerzy nie lubią scrum Zwinna ŁódźKrystian Kaczor
Scrum jest z nami od 1995, ale tak naprawdę pod polskie strzechy zawitał stosunkowo niedawno. W ostatnich pięciu latach zainteresowanie Scrum w Polsce nieustannie rosło. W tej chwili albo już pracujesz w czymś przypominającym Scrum, albo za chwilę będziesz. Developerzy nawet pomimo początkowej ekscytacji szybko zniechęcają się do nowego sposobu pracy. Zaczyna się hejt i marudzenie. Pomimo całej samo-organizacji i zbliżenia do użytkownika pojawia się opór i postawa obronna. Dlaczego tak się dzieje? Czy to problem z developerami? Jak przeciwdziałać problemom i sprawić, żeby praca w Scrum była przyjemna i motywująca? Opowiem o tym podczas mojego wystąpienia.
Scrum jest z nami od 1995, ale tak naprawdę pod polskie strzechy zawitał stosunkowo niedawno. W ostatnich pięciu latach zainteresowanie Scrum w Polsce nieustannie rosło. W tej chwili albo już pracujesz w czymś przypominającym Scrum, albo za chwilę będziesz. Developerzy nawet pomimo początkowej ekscytacji szybko zniechęcają się do nowego sposobu pracy. Zaczyna się hejt i marudzenie. Pomimo całej samo-organizacji i zbliżenia do użytkownika pojawia się opór i postawa obronna. Dlaczego tak się dzieje? Czy to problem z developerami? Jak przeciwdziałać problemom i sprawić, żeby praca w Scrum była przyjemna i motywująca? Opowiem o tym podczas mojego wystąpienia.
Jira jak każde narzędzie może posłużyć do czegoś dobrego albo czegoś złego. Możemy wspierać pracę w Agile, albo wręcz odwrotnie, zabić każdy aspekt Agile. A na początek wystarczyłoby skorzystać z ustawień schematu scrum w Jira Software.
O randce projektanta i użytkownika, czyli jak projektować produkty, które ...Project: People
“O randce projektanta i użytkownika - czyli jak projektować produkty, które pokochają
użytkownicy? Kilka słów o Lean UX.”
Jak wygląda typowy proces tworzenia nowych produktów? Co zrobić, aby uniknąć
niepowodzeń i marnotrastwa czasu i pracy projektantów? Jak projektować tak, by
użytkownicy pokochali nasz projekt? Oraz co Lean Startup robi poza ekosystemem
startupowym?
Na te i inne pytania odpowiemy sobie podczas nadchodzących warsztatów oraz dowiemy
się, czym właściwie jest Lean UX i dlaczego każdy projektant powinien go znać.
Scrum, choć jest wciąż popularny i lubiany, to zwykle nie jest już zwinny (Agile). Co robi różnicę? Jak bycie zwinnym zmienia myślenie o zadaniach ludzi w IT? Czym w praktyce różni się praca w zespole tradycyjnym i zwinnym? Wreszcie jak rozpoznać u potencjalnego pracodawcy prawdziwy Agile? Przy okazji odpowiedzi na te pytania sprostujemy wspólnie najczęściej pojawiające się przekłamania na temat Scruma i Agile.
Ponad 80% organizacji twierdzi, że korzysta z metod Agile, a 80% z nich ma Scrum. Pomimo 21 lat od powstania Scrum i 15 lat od spisania Agile Manifesto nadal pojawiają się nieprawdziwe opinie, a nawet powstają całe metody rozwiązujące nieistniejące problemy. Im wyżej w strukturze organizacji tym gorzej z wiedzą i tym więcej nieprawdziwych założeń. Od czasu do czasu nadal usłyszymy, że nie ma architektury, że Scrum nadaje się tylko do małych projektów, że Scrum to metoda zarządzania projektami, że nie trzeba pisać dokumentacji, testerów nie ma, bo nie ma takiej roli, a Sprint to taki mały waterfall i tym podobne głupoty. Skąd to się bierze? Najczęściej z braku zrozumienia podstaw lub ze słabej jakości źródeł pozyskanej wiedzy. W praktyce jeśli nie wie się co jest prawdą, a co jest zmyślone bardzo trudno zrozumieć co się na prawdę dzieje i jak powinny wyglądać procesy wytwórcze.
Można dać komuś rybę, ale dużo lepiej jest dać wędkę i nauczyć łowić ryby. Dlatego podczas mojego wystąpienia omówię podstawy zagadnień i zbuduję solidne fundamenty do podejmowania decyzji na co dzień.
Jest już 2016, a różni guru i instytucje certyfikujące nadal promują pomysł specjalizacji Agile Tester. Jak są rozumiane Agile Tester i Agile Testing? Czy to jest zgodne z ramami Scrum? Czy Agile Testing to tylko techniki XP?
Jak pracuje Product Owner? Spotkanie LubLean and AgileKrystian Kaczor
Product Owner jako osoba pisząca User Story (Historyjki Użytkownika) to jeden z najczęściej powtarzających się mitów na temat Scrum. Pojawiają się też głosy, że to niemożliwe, żeby jedna osoba potrafiła zarządzać Product Backlog. Czy aby na pewno? Czym zajmuje się Product Owner? Z jakich narzędzi korzysta Product Owner? Czy jest na 100% dostępny dla Zespołu Develoeprskiego? Co do tego ma Scrum Master?
Nearshoring and outsourcing will become more and more important, because the shortage of good developers is increasing, especially in Western Europe and US.
https://stxnext.com
This document discusses adapting Agile values and failures to do so. It presents three cases where Agile values were not fully adopted, including issues with regression testing, burndown charts, and cooperation between teams. It then discusses common reasons for failing to adapt Agile, such as a lack of management support or a culture at odds with Agile values. The document advocates starting quickly with Agile practices and adopting values of transparency, trust and empowerment to successfully change a culture over time.
Salary Formula - bumpy road to transparency.STX Next
1) The company implemented a salary formula to increase fairness, clarity, and transparency around salaries. The formula calculates salary as a base amount multiplied by weighted factors like experience, seniority, skills, and location.
2) After the first iteration, the formula covered 70% of employees but issues arose around measuring some factors objectively. The company refined the formula in a second iteration.
3) By the conclusion, the salary formula achieved its goals of reducing unfair salaries and unclear expectations through negotiations, while covering 85% of employees. The company continues refining the formula.
What scrum masters and product owners should know about software quality and ...STX Next
The document discusses technical debt in software projects. It defines technical debt as compromises in quality or maintainability that accumulate when developers take shortcuts or make quick fixes rather than implementing clean code. Technical debt comes from decisions to cut corners, such as not refactoring code or thoroughly testing features. Over time, technical debt can lead to slower development, more bugs, and heavier testing needs.
The document recommends calculating technical debt through software metrics like code complexity, duplication, and test coverage. It also suggests effective ways to manage technical debt in agile projects, such as creating a technical debt backlog, educating stakeholders, automating tests, and conducting retrospectives to improve practices and prevent accumulating further debt. Regularly paying down
Salaries should be fair for all employees, probably nobody doubts about it. In STX we felt that our salaries depend more on the personal negotiation skills, rather than on the exact knowledge. Inspired by Management 3.0 book by Jurgen Appelo, we’ve decided to implement the Salary Formula in our company. We gather the whole management team and started crafting magical formula hoping that it will solve all our problems. Quite fast we realized, that the theory is quite simple but the implementation is tricky, because a lot of pitfalls is not covered in available papers. In this talk I will share what we have learned last year and what we need to improve in future to make this formula as fair as possible.
Retrospekcja to najbardziej wartościowy, a zarazem najbardziej zaniedbywany element w agile'owego działania. Jeśli Twoje retrospekcje wieją nudą, straszą brakiem nadziei albo po prostu nie przynoszą efektów, to najwyższy czas zmienić podejście. Być może zawiodły Cię, tak jak kiedyś mnie, rady z mądrych książek i wielogodzinnych szkoleń, albo dopiero przymierzasz się do roli Scrum Mastera. Pokażę Ci bardzo skuteczną receptę, która odmieniła moje retrospekcje nie do poznania. Nauczysz się jak w 10 prostych krokach zrobić to w taki sposób, że nie tylko zmobilizujesz Twój zespół do aktywnego udziału, ale przede wszystkim wyciśniesz z tego czasu jego prawdziwą esencję. Na koniec dowiesz się także, jak dodawać do tego wszystkiego odrobinę finezji, żeby każde kolejne spotkanie było jeszcze lepsze od poprzedniego.
Scrum jest z nami od 1995, ale tak naprawdę pod polskie strzechy zawitał stosunkowo niedawno. W ostatnich pięciu latach zainteresowanie Scrum w Polsce nieustannie rosło. W tej chwili albo już pracujesz w czymś przypominającym Scrum, albo za chwilę będziesz. Developerzy nawet pomimo początkowej ekscytacji szybko zniechęcają się do nowego sposobu pracy. Zaczyna się hejt i marudzenie. Pomimo całej samo-organizacji i zbliżenia do użytkownika pojawia się opór i postawa obronna. Dlaczego tak się dzieje? Czy to problem z developerami? Jak przeciwdziałać problemom i sprawić, żeby praca w Scrum była przyjemna i motywująca? Opowiem o tym podczas mojego wystąpienia.
Jira jak każde narzędzie może posłużyć do czegoś dobrego albo czegoś złego. Możemy wspierać pracę w Agile, albo wręcz odwrotnie, zabić każdy aspekt Agile. A na początek wystarczyłoby skorzystać z ustawień schematu scrum w Jira Software.
O randce projektanta i użytkownika, czyli jak projektować produkty, które ...Project: People
“O randce projektanta i użytkownika - czyli jak projektować produkty, które pokochają
użytkownicy? Kilka słów o Lean UX.”
Jak wygląda typowy proces tworzenia nowych produktów? Co zrobić, aby uniknąć
niepowodzeń i marnotrastwa czasu i pracy projektantów? Jak projektować tak, by
użytkownicy pokochali nasz projekt? Oraz co Lean Startup robi poza ekosystemem
startupowym?
Na te i inne pytania odpowiemy sobie podczas nadchodzących warsztatów oraz dowiemy
się, czym właściwie jest Lean UX i dlaczego każdy projektant powinien go znać.
Scrum, choć jest wciąż popularny i lubiany, to zwykle nie jest już zwinny (Agile). Co robi różnicę? Jak bycie zwinnym zmienia myślenie o zadaniach ludzi w IT? Czym w praktyce różni się praca w zespole tradycyjnym i zwinnym? Wreszcie jak rozpoznać u potencjalnego pracodawcy prawdziwy Agile? Przy okazji odpowiedzi na te pytania sprostujemy wspólnie najczęściej pojawiające się przekłamania na temat Scruma i Agile.
Ponad 80% organizacji twierdzi, że korzysta z metod Agile, a 80% z nich ma Scrum. Pomimo 21 lat od powstania Scrum i 15 lat od spisania Agile Manifesto nadal pojawiają się nieprawdziwe opinie, a nawet powstają całe metody rozwiązujące nieistniejące problemy. Im wyżej w strukturze organizacji tym gorzej z wiedzą i tym więcej nieprawdziwych założeń. Od czasu do czasu nadal usłyszymy, że nie ma architektury, że Scrum nadaje się tylko do małych projektów, że Scrum to metoda zarządzania projektami, że nie trzeba pisać dokumentacji, testerów nie ma, bo nie ma takiej roli, a Sprint to taki mały waterfall i tym podobne głupoty. Skąd to się bierze? Najczęściej z braku zrozumienia podstaw lub ze słabej jakości źródeł pozyskanej wiedzy. W praktyce jeśli nie wie się co jest prawdą, a co jest zmyślone bardzo trudno zrozumieć co się na prawdę dzieje i jak powinny wyglądać procesy wytwórcze.
Można dać komuś rybę, ale dużo lepiej jest dać wędkę i nauczyć łowić ryby. Dlatego podczas mojego wystąpienia omówię podstawy zagadnień i zbuduję solidne fundamenty do podejmowania decyzji na co dzień.
Jest już 2016, a różni guru i instytucje certyfikujące nadal promują pomysł specjalizacji Agile Tester. Jak są rozumiane Agile Tester i Agile Testing? Czy to jest zgodne z ramami Scrum? Czy Agile Testing to tylko techniki XP?
Jak pracuje Product Owner? Spotkanie LubLean and AgileKrystian Kaczor
Product Owner jako osoba pisząca User Story (Historyjki Użytkownika) to jeden z najczęściej powtarzających się mitów na temat Scrum. Pojawiają się też głosy, że to niemożliwe, żeby jedna osoba potrafiła zarządzać Product Backlog. Czy aby na pewno? Czym zajmuje się Product Owner? Z jakich narzędzi korzysta Product Owner? Czy jest na 100% dostępny dla Zespołu Develoeprskiego? Co do tego ma Scrum Master?
Nearshoring and outsourcing will become more and more important, because the shortage of good developers is increasing, especially in Western Europe and US.
https://stxnext.com
This document discusses adapting Agile values and failures to do so. It presents three cases where Agile values were not fully adopted, including issues with regression testing, burndown charts, and cooperation between teams. It then discusses common reasons for failing to adapt Agile, such as a lack of management support or a culture at odds with Agile values. The document advocates starting quickly with Agile practices and adopting values of transparency, trust and empowerment to successfully change a culture over time.
Salary Formula - bumpy road to transparency.STX Next
1) The company implemented a salary formula to increase fairness, clarity, and transparency around salaries. The formula calculates salary as a base amount multiplied by weighted factors like experience, seniority, skills, and location.
2) After the first iteration, the formula covered 70% of employees but issues arose around measuring some factors objectively. The company refined the formula in a second iteration.
3) By the conclusion, the salary formula achieved its goals of reducing unfair salaries and unclear expectations through negotiations, while covering 85% of employees. The company continues refining the formula.
What scrum masters and product owners should know about software quality and ...STX Next
The document discusses technical debt in software projects. It defines technical debt as compromises in quality or maintainability that accumulate when developers take shortcuts or make quick fixes rather than implementing clean code. Technical debt comes from decisions to cut corners, such as not refactoring code or thoroughly testing features. Over time, technical debt can lead to slower development, more bugs, and heavier testing needs.
The document recommends calculating technical debt through software metrics like code complexity, duplication, and test coverage. It also suggests effective ways to manage technical debt in agile projects, such as creating a technical debt backlog, educating stakeholders, automating tests, and conducting retrospectives to improve practices and prevent accumulating further debt. Regularly paying down
Salaries should be fair for all employees, probably nobody doubts about it. In STX we felt that our salaries depend more on the personal negotiation skills, rather than on the exact knowledge. Inspired by Management 3.0 book by Jurgen Appelo, we’ve decided to implement the Salary Formula in our company. We gather the whole management team and started crafting magical formula hoping that it will solve all our problems. Quite fast we realized, that the theory is quite simple but the implementation is tricky, because a lot of pitfalls is not covered in available papers. In this talk I will share what we have learned last year and what we need to improve in future to make this formula as fair as possible.
Retrospekcja to najbardziej wartościowy, a zarazem najbardziej zaniedbywany element w agile'owego działania. Jeśli Twoje retrospekcje wieją nudą, straszą brakiem nadziei albo po prostu nie przynoszą efektów, to najwyższy czas zmienić podejście. Być może zawiodły Cię, tak jak kiedyś mnie, rady z mądrych książek i wielogodzinnych szkoleń, albo dopiero przymierzasz się do roli Scrum Mastera. Pokażę Ci bardzo skuteczną receptę, która odmieniła moje retrospekcje nie do poznania. Nauczysz się jak w 10 prostych krokach zrobić to w taki sposób, że nie tylko zmobilizujesz Twój zespół do aktywnego udziału, ale przede wszystkim wyciśniesz z tego czasu jego prawdziwą esencję. Na koniec dowiesz się także, jak dodawać do tego wszystkiego odrobinę finezji, żeby każde kolejne spotkanie było jeszcze lepsze od poprzedniego.
Pasja, cierpliwość i zaufanie. Agile@GetResponse – historia zmianySławek Łukjanow
Podobno na mieście krążą informacje o udanych zmianach w GetResponse IT. Nadszedł zatem najwyższy czas, aby o nich opowiedzieć!
W czerwcu 2015 roku w GetResponse pojawiło się dwoje zaprawionych w bojach Scrum Masterów. Misja: wsparcie wdrożenia Scruma na poziomie całego IT.
Po 1.5 roku jest już nas pięcioro i uważamy, że wspólnie udało nam się sporo osiągnąć. Opowiem o tym jak podeszliśmy do procesu zmiany, co zrealizowaliśmy, na jakie problemy natrafiliśmy i jak je rozwiązaliśmy, co nas zaskoczyło, jakie popełnialiśmy błędy i czego nas to nauczyło. I jak wersję „wzorowy Scrum” zmieniliśmy na podążanie za zasadami kultury agile.
To będzie też historia o tym jak istotna w pracy Scrum Mastera jest pasja i wewnętrzny ogień, połączony z anielską cierpliwością. I jak bardzo pomaga zaufanie. Zarówno to otrzymane, jak i dawane.
Prezentował: Maciej Wilmiński
Scrum Master w GetResponse, mający niemałe doświadczenie we wprowadzaniu kultury i pracy agile, zarówno na poziomie zespołów deweloperskich, działów IT jak i całych organizacji.
Jego dużym atutem jest praktyka zdobyta w sporej ilości projektów, w których pełnił różne role: programisty, architekta oprogramowania czy lidera zespołu. W efekcie niewiele w IT jest go w stanie zaskoczyć lub przestraszyć.
Wierzy w moc pracy zespołowej, a jako wielki fan sportu, dostrzega sporo podobieństw pomiędzy pracą zespołu programistycznego, a budowaniu dobrej drużyny sportowej. Rolę Scrum Mastera postrzega jako kombinację kapitana, trenera, a czasem i zawodnika.
O Scrumie i agile’u pisze na blogu mlynarze.com, jest też założycielem Encyklopedii Rocka rockers.com.pl.
Behave automatically: (Almost) Effortless feature testingSTX Next
Presentation from the 2nd STX Next Summit 2016 by Tomasz Muszczek & Piotr Błaszczyk on how to set up the optimal software testing environment.
https://stxnext.com
Presentation from the 2nd STX Next Summit 2016 by Radosław Jankiewicz presenting an overview of ReactJS - a great javascript library for building user interfaces.
https://stxnext.com
Software development process, in-house or outsourced, might be a challenge. It is important to choose a vendor or hire a team of professionals who understand that quality of source code directly impacts the overall cost of your project. You most probably want to find a vendor who knows how to reveal all the risk hidden behind low quality code. Tricky part in revealing risk and possible quality issues is that you have to know how to do this at the time of development, not when it’s already too late.
Author:
Łukasz Koczwara - Software Development Manager @ STX Next
Kotlin Advanced - language reference for Android developers STX Next
StxNext Lightning Talks - Mar 11, 2016
This presentation contains the second talk on Kotlin language we had at STXNext. We try go deeper into language specifics and look at the positive impact new syntax can have on boilerplate removal and readability improvement.
Kotlin really shines in Android development when one looks at “Enum translation”, “Extension functions”, “SAM conversions”, “Infix notation”, “Closures” and “Fluent interfaces” applied to lists. The talk, however, compares language-specifics of Java & Kotlin in terms of “Type Variance”, “Generics” and “IDE tools” as well.
We present real-world example based on Stx-Insider project written in Kotlin which incorporates Dagger 2, Kotterknife, Retrofit2 and is composed of 5+ Activities.
Discover, Define, Deliver - a workflow to create successful digital products. STX Next
Presentation from STX Next Summit 2016 by Dominik Oślizło describing the Discover, Define, Deliver process, a rock-solid approach that ensures smooth idea-to-product transitions and radically accelerates time-to-market.
Kotlin Developer Starter in Android - STX Next Lightning Talks - Feb 12, 2016STX Next
Kotlin - one of the popular programming languages built on top of Java that runs on JVM. Thanks to JetBrains support and excellent IDE integration, it’s an ideal choice for Android development. 100% Java compatibility, interoperability and no runtime overhead is just the beginning of a long list of strengths. Kotlin is supposed to be a subset of SCALA, on one hand covering major advantages for developers and keeping short compile times on the other.
This presentation is a Developer Starter - a set of hand-picked information allowing a person with no knowledge of Kotlin to start writing basic Android activities and set up a kotlin-based Android project. It starts with language background, reasons for its creation and advantages. Then presents basic use cases, syntax, structures and patterns. Later on Kotlin is presented in Android context. Simple project structure, imports and Kotlin usage with Android SDK is explained. In the end cost of Kotlin compilation is presented and the language is compared to SCALA and SWIFT.
STX Next - Scrum Development Process OverviewSTX Next
An overview of Software Development Process at STX Next presenting basic SCRUM ceremonies and workflows. To learn more about STX Next visit https://stxnext.com
At STX, we know that we are as strong as the people working for us, so we try to maintain a work environment based around honesty, trust, and hard work instead of management and bureaucracy. We are goal-oriented, agile, and fast-paced. We want you to be communicative, self-motivated, problem-solving, and cooperative. Contact us if you’re interested in being our next hero!
Group Process by Example - a PO’s and SM’s perspectiveSTX Next
This document summarizes a presentation given by two Scrum practitioners on their experiences with team development based on Tuckman's model of group formation. It describes the four stages - forming, storming, norming, and performing - and provides examples of how teams typically behave in each stage as well as recommendations for facilitating positive progression. Key takeaways are to build safety for open conflict in storming, give the team space to develop cohesion in norming, and empower high performance in performing. The document aims to help others understand typical group processes and how to accelerate team growth.
8. Komunikacja
● Skupienie na celu spotkań
○ Aktywna obserwacja
○ Powerful questions
○ Zapewnienie różnych
punktów widzenia
● Codzienna komunikacja i
feedback
15. Image credits
Icons made by http://www.flaticon.com/authors/epiccoders EpicCoders from http://www.flaticon.com is
licensed by Creative Commons BY 3.0
Icons made by http://www.freepik.com from http://www.flaticon.com is licensed by Creative Commons
BY 3.0
Images by Henrik Kniberg http://blog.crisp.se/author/henrikkniberg