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.

T3CON 19 Scrum for web agencies, does it really work?


Published on

When the only tool you know is a hammer, everything is a nail

Published in: Software
  • Be the first to comment

T3CON 19 Scrum for web agencies, does it really work?

  1. 1. SCRUM FOR WEB AGENCIES does it really work?
  2. 2. David Denicolò 
 Web Dev
 Scrum Master About me
  3. 3. AGENDA 
 Scrum in web agencies, does it really works? Ideas, suggestions from my experience Share your ideas and questions
  4. 4. SCRUM FOR WEB AGENCIES does it really work?
  5. 5. A STEP BACK Waterfall Waterfall shows we can plan in advance and have all under control for the whole development Scrum Learn from feedbacks and errors, or commonly said “adapt and evolve”. Sprint after sprint the product and team evolve and became faster, everything goes smooth.
  6. 6. SOME KEY POINTS Scrum is a framework to develop complex products
  7. 7. WHAT DOES “COMPLEX PRODUCTS” MEAN? ➤ Something difficult to develop? ➤ Something new/innovative? ➤ That requires some research? ➤ Outside the team or agency knowledge or DNA? ➤ Something that requires many weeks of work? And, how much is many? ➤ Something that interacts with other software and teams (maybe outside our team/ agency) ➤ Some requirements and customizations that shift the complexity
  8. 8. COMPLEX PRODUCT There is not a clear definition of “complex product”
  9. 9. WE CAN FIND OUT WHAT DOES IT MEAN FOR US ➤ Is building a TYPO3 website complex for you? 
 (substitute TYPO3 with your common technology)
 ➤ Would you say that a product built in 4 sprint is complex?
 And 10 sprints? What about 50 sprints?
 ➤ For a team of 7 persons?
 Two or more teams?

  10. 10. AN EXAMPLE ABOUT BUDGET For a 7 person team (5devs, 1PO, 1SM) 7 * 40h = 280h per week A 2 week sprint is around 560h A 10 sprint development is around 5600h Multiply for your average hourly cost, you do the math
  11. 11. TYPICAL WEB AGENCY - small projects - low budgets - small teams - many projects at time - PO/PM busy - support old projects - budget out of control - pre-estimations for contract negotiation - waterfall-ish - stakeholders not in Scrum - Scrum not well implemented - meetings, meetings everywhere - external teams - external designers
  12. 12. A ROOT OF MANY PROBLEMS: THE PO IS ALWAYS BUSY PO in web agencies take care of multiple project at time. PO cannot really care of a product, he or she has to deal with several stakeholders, requests, phone calls. Pretty often he or she cannot attend Scrum events. Stories are bad written, often in a form of task more than a story. The PO decide not only what to do but how to do it.
  13. 13. SCRUM IN WEB AGENCIES VS SCRUM COMPLEX PRODUCT Multiple parallel projects Non consecutive sprints timeline Team detached from designers and stakeholders Team constantly interrupted for new leads or support Short-term / low budget projects Give-up on scrum events One team is fully dedicated to one product Long term development Team commitment A feedback culture and retrospectives to improve the team and the product Enough “heads” to ensure new ideas and point of views or brainstorming
  15. 15. WHERE SCRUM OFFER ITS BEST Scrum give its best on: Long term products development > 10sprints Middle size teams: 5-7 developers A fully dedicated PO CI/CD Agile environment (including stakeholders) On complex products development
  16. 16. SOME IDEAS And suggestions from my personal experience
  17. 17. SOME GENERAL SUGGESTIONS Promote ownership into the team Let the team collaborate with the client, but at the same time protect him Devs: ask why, what's the benefit, the reason, the goal Focus on one project per team at time, avoid unnecessary meetings Give the team a constant pace
  18. 18. FIRST IDEA: KEEP SCRUM AND ADAPT IT TO SCALE DOWN Scrum in small teams of 2-4 Devs Enable and promote the figure of developer/SM Promote a PO-substitute or representative inside the team Enhance the client collaboration and a culture of feedbacks Review per each story on deployment Create a retrospective event with several teams in order to promote innovation for the agency
  19. 19. WHERE IT WORKS BEST Small teams with senior developers Complementary skills Able to consult the client With a “lean mindset” Using no estimates
  20. 20. WHAT COULD GO WRONG Teams are not large enough to ensure adequate skill sets Scrum could be wrongly adapted, the lack of dedicated scrum masters could degenerate into faulty scrum Altering the roles, the principles, artefacts and scrum events could make the “adapted-scrum” framework collapsing
  21. 21. ALTERNATIVE IDEA: SCRUMBAN A hybrid solution based on Kanban with some of Scrum concepts. A pre-planning with few devs and POs with estimations A daily in front of the Kanban board Pairing or dev solo A weekly pace, for example monday-friday “sprint” A “recap” in the end of the week, clean the board An agency retrospective once or twice a month
  22. 22. WHERE IT WORKS BEST Support tasks Small feature (1-2 weeks max) Where there is no need of brainstorming For example after a go-live
  23. 23. WHAT COULD GO WRONG It’s not scrum There is not much collaboration between developers Knowledge fragmentation If a scrum-able project comes, it could be very difficult go back to real scrum Not control on tasks over stories, or bad written stories Developers don’t have a real opportunity to offer their experience on consulting
  24. 24. OTHER SUGGESTIONS Implement the culture of deploy and learn from the market, and not just accomplish client requests Implement the concept of Lean development Minimal Viable Product (MVP) MoSCoW method of prioritisation (Must, Should, Could, Would) Explicit goals and benefits for each story and tasks Never compromise on quality
  25. 25. OTHER SUGGESTIONS No estimate Scrum Approach the “known unknown” with time-limit “spike” tasks Small frequent releases Integrate designers into dev teams
  26. 26. NO ESTIMATES It’s an approach in Scrum to avoid wasting time in estimations and focus on development. It works pretty good in conjunction with spikes and expert small teams It’s a break change approach especially in those environments where estimations are “important”
  27. 27. SPIKE A spike is a product-testing method that uses the simplest possible program to explore potential solutions. It is used to determine how much work will be required to solve or work around a software issue A spike is an “exploration task” to make an unknown topic less unknown Instead of story points it has a fixed time, in that time the team tries to identify the boundary of the problem, do research, maybe solve the issue if possible in the time. Result of the spike is a more well defined task/story in the backlog
 The whole team works on the same thing, at the same time, in the same space on a single computer It’s an intense brainstorming-developing session Similar to pair programming but extended to the whole team
  29. 29. INTEGRATE DESIGNERS If you are using scrum try to add a designer into the dev team, participate in scrum events, be part of the dev team
 Try also pair programming or mob programming with designer
 Transfer to designers the concepts of application workflow
  30. 30. DO YOU WANT SHARE SOME IDEA? Feel free to share :)