Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Dimpact wim bumpy road of building reusable platform for municipalities from pm perspective


Published on

From Olena Moskalyk for DrupalCamp Kyiv 2017

Published in: Internet
  • Be the first to comment

  • Be the first to like this

Dimpact wim bumpy road of building reusable platform for municipalities from pm perspective

  1. 1. Dimpact WIM: bumpy road of building reusable platform for municipalities from PM perspective
  2. 2. Olena Moskalyk Project Manager Lemberg Solutions Ltd.
  3. 3. About WIM WIM is a free reusable website model designed by and for local government and municipalities. With WIM each municipality can have a great online presence; quickly and at minimal cost. The WIM sites are a cooperative initiatives of the Cooperative Association Dimpact from The Netherlands. Supporting organizations: GoalGorilla - Founder and developer Lemberg Solutions Limited - Co-developer Dimpact - Supporting organization
  4. 4. From troubleshooting to solution “We adore chaos because we love to produce order” © M. C. Escher
  5. 5. Key problems to be resolved Interaction with admin panel: too many features, messy CSS files. Support: due to complex structure implementation of new features and keeping in order existing functionality became tricky. Users No adaptation for mobile devices. Accessibility issues. Dimpact The product should be competitive to be able for future growth. Our goal is to achieve a modern integrated public service. Municipalities
  6. 6. Challenges Challenge 1 Focus on the distribution All the cities can make their own changes, but they should overwrite the distribution. Challenge 2 Challenge 3Challenge 2 Optimisation of functionality Removing of features that are not in usage Challenge 3 Balance in quantity of features Enough to remain flexible but not too complex Challenge 4 Custom CSS New front-end theme that cities can customize (being sticked to provided CSS and HTML) Challenge 1
  7. 7. Phases of the project May Jun Jul Aug Sept Oct Nov Dec Jan Feb Mar Apr May Jun Development MigrationInvestigation
  8. 8. Investigation Analysis of architecture Analysis of UI Global planning
  9. 9. Analysis of the structure
  10. 10. Analysis of UI
  11. 11. Global planning
  12. 12. Development ● Methodology - SCRUM ● 6 sprints 3-week length ● Over 400hrs each sprint ● Sprint cycle key moments: ■ Sprint planning ■ Development ■ UAT ■ Refinement session ■ Sprint review ■ Retrospective
  13. 13. How we do it Ready team Feature design Challenge 2 Challenge 3Done team Detailed implementation approach Code review Automated tests QA team Manual testing Cross- browser/cross- platform testing Accessibility testing UAT team User acceptance testing
  14. 14. Useful tips ● Slice&Dice sessions: splitting epics into user stories, writing description and the way of implementation ● Refinement sessions: review of description, adding technical details and estimation ● Sprint planning: defining sprint goal, review of user stories, estimates and definition of done ● Behat tests: during development process we also create corresponding to features automated tests ● Internal QA: UI, functional and running behat tests ● UAT at Dimpact side: UI, functional and running behat tests ● Sprint review: during the demo representatives of municipalities can give their feedback so their requirements can be included in scope of next sprints
  15. 15. Migration Methodology - Kanban We kept the same dev team that was working on platform development Cooperative work on preparing migration details and migration plan 2 UAT periods for each municipality to make sure results meet expectations Jira manuals and UAT checklists for municipalities Information about improvements in comparison to WIM 1.0
  16. 16. Migration details
  17. 17. Lessons learned “If you’re not failing every now and again, it’s a sign you aren’t doing anything very innovative” © Woody Allen
  18. 18. Get everything documented but keep it simple: at some point we started to get lost in multiple related documents. So we trying now to get all related details stored in 1 document that is shared with everyone involved. Knowledge sharing and double management: we had clearly distributed obligations in terms of project management with my colleague but at certain moment there appeared a need to hand over responsibilities. And that was a moment when we realised the use of transparency and knowledge sharing that everyone is talking about. Still it was piece of work for us but went more or less smoothly.
  19. 19. Stable team - it is necessary to have it. We kept same developers for migration stage, still we had staff changes on the road. At some point I was taking over tasks of my colleague and started to communicate directly with representatives of cities. And technical specialists from GoalGorilla side were in need to switch to another project so were replaced new person. Anyway, the fact that part of the core team all the time was in charge of the project, kept the knowledge and shared it, made these changes not critical. Hard to make people accept that some functionality will be cut off: in workgroup during development and migration every now and then there were fights for scope. Language barrier: some people were just refusing to use English because they were shy it is not good enough
  20. 20. Estimations - we were fucked up with estimates for migration phase. If you don’t have time to look at exact structure of each site and proceed with analysis, you will be amazed after how weirdly people can use certain functionality. Team burnout. When you work on big projects people are getting tired. And we faced this problem at some point. New projects on Drupal 8 were developed by our colleagues and guys from my team were curious to try it. Also during migration every now and then old functionality gets into conflict with new structure, that was carefully built by you, but it is strongly required by municipalities so you have to accept and implement it in requested way. You have to get things done even you don’t like it. Hosting: always check even smallest details when you work with these guys otherwise at some point you can realise that you’re using for production sites unstable beta-version environment, that just stops working time to time.
  21. 21. Thank you for attention!