Building robust software in an agile world

1. Agile and Architecture: An Oxymoron?
Building robust software in an agile world

3. ● 6+ years fullstack developer
● 3+ years technical architect @ one45 software
What I like to code in:
● iOS (objective-c, swift)
● PHP, Symfony 2,3,4(coming soon)
● AngularJS ??(1,2) ===> (React vs Vu)
Currently working on:
● Data Integration
● ML/AI
● Data visualization
Slido.com #6512
Hi my name is Scott Hsieh

4. Agile development
Lean Agile
Find the right
product
Building product
and getting the
product to client
MVP
Product
Management
Project
Management
Slido.com #6512

5. 3 Amigos approach
- Plan
- Develop
- Test/Verify
- Ship
Good for getting things out the
door but not so much for putting
out robust code. We will see why
later.
Slido.com #6512

6. Typical Lifespan of a project (what management expects)
Time
Project
health
Slido.com #6512

7. Typical Lifespan of a project (What actually happened)
Time
Project
Health
Slido.com #6512

8. Journey of a software project - the beginning
Time
beginning
coupling
Slido.com #6512

9. Journey of a software project - the middle
Time coupling
a mistake
occurred
Slido.com #6512

10. Journey of a software project - the beginning
coupling
compensation
for mistake
Time
Slido.com #6512

11. Journey of a software project - the end
Time
rewrite
Slido.com #6512

12. The finished product
● A product that ...
○ That is 100% functional (MVP)
○ Changes made overtime have
reduced the ability to make future
changes as fast original pace
○ Full of software mistakes that are
invisible to Clients and QA aka
“technical debt”
Slido.com #6512

13. ● Code does not moist, rot, degrade
● There are no crap elves that comes out at night and add
bad code
Code does not go bad on its own
Slido.com #6512

14. Code is bad only if we
put it there.
We are the crap elves.
Slido.com #6512

15. Most common causes for software mistakes
● Change in product requirements
● Software management
● Compounding existing technical debts
Slido.com #6512

16. Current Development Process
Lean Agile
Customer
Value
Speed/AgilityMVP
Fastest
way to
deliver
value
Product
Management
Project
Management
Slido.com #6512

17. The missing link
Lean Agile
Speed/Agility
Product
Management
Structure of
Development
Customer
Value
Architecture
Quality
MVP
Slido.com #6512

18. Software Architecture in Agile world
Slido.com #6512

19. Agility in Software Architecture
Adaptation Anticipation
Slido.com #6512

20. How does Software Architecture help?
Slido.com #6512

21. Most common causes for software mistakes
● Change in product requirements
● Software management
● Compounding existing technical debts
Slido.com #6512

22. Change in requirement
● Change in scope of the project
● Adding new functionality to systems that
was not originally designed to support
Slido.com #6512

23. Most common causes for software mistakes
● Change in product requirements
● Software management
● Compounding existing technical debts
Slido.com #6512

24. 3 Amigos approach
- Plan
- Develop
- Test/Verify
- Ship
Slido.com #6512

25. Software management
Input Output
100% 85% 60% 45%
Slido.com #6512

26. Software development is a Relay race
Development as a team is all
about “Momentum transfer”
- Get to the end with minimum
loss in quality
- We spent a lot of time thinking
about how to get started on a
task. If receiver can build
momentum before he/she
receive the task we minimize
“outages”
Slido.com #6512

27. Software development
I’m done my
lap. Your turn.
K.
Wall of Confusion

28. Most common causes for software mistakes
● Change in product requirements
● Software management
● Compounding existing technical debts
Slido.com #6512

29. Dual track Agile
Slido.com #6512

30. The Zipper model
From product requirements derive:
● Functional requirements
● Architectural requirements
Establish
● Dependencies
● Cost
Plan interleaving:
● Functional increments
● Architectural increments
● Functional Requirement
● Technical Requirement
Slido.com #6512

31. The Zipper model benefits
● Gradual emergence of architecture
– Deliberate, not accidental
● Validate on architecture with actual
functionality (not mere hypotheses)
● Just enough to support development
● Functional Requirement
● Technical Requirement

32. Dual Track Agile
Product Manager, Technical Lead, UX
Scrum master, Technical Lead, Developers

33. Dual Track Agie
Product Manager, Technical Lead, UX
Scrum master, Technical Lead, Developers

34. Dual Track Agile
Product Manager, Technical Lead, UX
Scrum master, Technical Lead, Developers

35. Dual Track Agile
Product Manager, Technical Lead, UX
Scrum master, Technical Lead, Developers

36. Dual Track Agile
Product Manager, Technical Lead, UX
Scrum master, Technical Lead, Developers

37. Dual Track Agile
Product Manager, Technical Lead, UX
Scrum master, Technical Lead, Developers

38. Dual Track Agile

39. Dual Track Agile
Product Manager, Technical Lead, UX
Scrum master, Technical Lead, Developers

40. Dual Track Agile
Product Manager, Technical Lead, UX
Scrum master, Technical Lead, Developers

41. Dual Track Agile
Product Manager, Technical Lead, UX
Scrum master, Technical Lead, Developers

42. Dual Track Agile
Product Manager, Technical Lead, UX
Scrum master, Technical Lead, Developers

43. Dual Track Agile
Product Manager, Technical Lead, UX
Scrum master, Technical Lead, Developers

44. Dual Track Agile
Product Manager, Technical Lead, UX
Scrum master, Technical Lead, Developers

45. Dual Track Agile
Product Manager, Technical Lead, UX
Scrum master, Technical Lead, Developers

46. Dual Track Agile
Product Manager, Technical Lead, UX
Scrum master, Technical Lead, Developers

47. Dual Track Agile
Balances between the big picture and
now – an agile software architect has
to think about what is happening
during the development together with
aligning it with the big picture of the
entire system.
Hands-on experience – an agile software
architect is also a developer and
works on the implementation of the
system. This gives first-hand
feedback on the taken architectural
decisions.
Produces prototypes to make Focus on
sustainability
Slido.com #6512
Product Manager, Technical Lead, UX
Project Manager, Technical Lead, Developers

48. Most common causes for software mistakes
● Change in product requirements
● Software management
● Compounding existing technical debts
Slido.com #6512

49. Technical Debt are software mistakes
- When a mistake
happened, this is pretty
much the only chance
you had to fix it
coupling
a mistake
occurred
Slido.com #6512

50. Technical Debts are software mistakes
- You cannot build on top of
things you don’t understand
- most of it are compensating flaws
of other mistakes
- most software mistakes can’t be
fixed
- cost/time
- invisible coupling
compensation
for mistake
Slido.com #6512

51. ● when a mistake happens in a N-tier
architecture if a mistake happened. It will
smooth itself out further away the layer is
from the source
● Components with compensation logic is
no longer re-usable or else technical debt
will multiply
● More expensive to fix down the road
more layer the technical debt is seen
regardless how small it is
N-tier architecture compounding debt
Database/
Repository
Service
View
First mistake, had
the chance to fix it
but ignored
compensation
Slido.com #6512

52. - what we can do is correct the
mistakes at the level where the
mistakes happens
- dev team don’t allow direct access
to the resources with mistakes,
only interfacing through the
correction layer
- dev team has to agree on where
the correction layer lives
N-tier architecture debt correction
Database/R
epository
Service
View
mistake
correction
Slido.com #6512

53. Conclusion
● Architecture is only as effective if the end goal is clear
● Architecture and Product requirement has to align
● If requirement or the scope of the project change dramatically we don’t
repair/refactor we re-design
● Never access the the resource/logic directly if it has correction to fix the
original mistake
● Dev team should agree upon a standard way on how we should access
those problematic resources in systems going forward
Slido.com #6512