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

1. SCRUM FOR WEB AGENCIES
does it really work?

2. David Denicolò
Web Dev
Scrum Master
sozialinfo.ch
About me

3. AGENDA
Scrum in web agencies, does it
really works?
Ideas, suggestions from my
experience
Share your ideas and questions

4. SCRUM FOR WEB AGENCIES
does it really work?

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. SOME KEY POINTS
Scrum is a framework to develop
complex products

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. COMPLEX PRODUCT
There is not a clear definition of “complex product”

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. 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. 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. 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. 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

14. IF THE ONLY TOOL YOU HAVE IS A HAMMER,
EVERYTHING IS A NAIL

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. SOME IDEAS
And suggestions from my personal experience

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. 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. WHERE IT WORKS BEST
Small teams with senior developers
Complementary skills
Able to consult the client
With a “lean mindset”
Using no estimates

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. 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. 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. 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. 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. OTHER SUGGESTIONS
No estimate Scrum
Approach the “known unknown” with time-limit “spike” tasks
Small frequent releases
Integrate designers into dev teams

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. 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

28. MOB PROGRAMMING
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. 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. DO YOU WANT SHARE SOME IDEA?
Feel free to share :)