Moderen Software projects are challenging to develop. Eran Stiller, Ronen Rubinfeld, and Erez Pedro from CodeValue show a method for conducting multidisciplinary product discovery.

2. Dilemmas and Solutions in
Modern Software Development
Alon Fliess
Chief Software Architect
Azure MVP, MRD
alonf@codevalue.net
http://alonfliess.me
2

3. Agenda
To Microservice or Not to Microservice?
UX Tools for Product Discovery
Planning the Unexpected: Dealing with a Rapidly Changing Reality
4

4. 5
Eran Stiller, Chief Technology Officer (CodeValue)
To Microservice
or Not to Microservice?

5. Decomposition
Is this a good design?

6. Decomposition
Is this a good design?

7. Decomposition
Is this a good design?

8. Decomposition
Is this a good design?

9. The Cost of the Software Development Process
number of modules
Module
Integration
cost (complexity)
module
development
Cost (complexity)Cost

10. Microservices Platforms Benefits
Modern microservices platforms significantly reduce the cost of
module integration
Shifting the cost equilibrium towards more modules
Especially true when using proven PaaS platforms
Both public and private cloud based
The integration cost decreases with two factors:
Mature PaaS platform
Proven DevOps process
11

11. Monoliths
Why are monoliths considered a bad thing?
They’re not
They all started with good intentions
They usually become convoluted over time
Features are added
People change
Deadlines happen
Technical debt accumulated
It’s very easy to fall
12

12. Microservices
Are Microservices the solution?
They also start with good intentions
Will become convoluted with time as well
Without proper architecture and guidance
13

13. Monoliths
Natural starting point
Easier to get started and deliver value
Simpler build and deployment
Simpler scalability
Simpler security
Low latency
Intra-process communication
Simpler testing
Simpler logging and monitoring
Simpler data and database
management
Simpler transaction management
Large code base
Simple change requires whole app
to be redeployed
Increased complexity as
functionality is coupled together
Single type of database doesn’t
meet all requirements
Tend to get difficult to work with
over time
Huge resource requirements
Reduced agility over time
Coarse-grain transactions
14
Source: https://bit.ly/2vf6eov

14. Microservices
Smaller manageable functional units
Multiple smaller code bases
Single service provides single functionality
Single responsibility per service
Clearer separation of concerns
Independently scalable services
Polyglot persistence as applicable
Polyglot programming language as applicable
Independently deployable
Easier on-boarding process
Frequent functionality releases
Decentralized ownership
Team that develops it, manages it
Distributed System Architecture
Design, Development, Deployment, CAP theorem
Handle Increased orchestration
Troubleshooting challenges
Call Traceability
Log aggregation
Data consistency issues
Eventual consistency
Compensatory & reconciliatory procedures
Increased latency due to remote calls
Distributed Configuration Management
Organizational Maturity
Company Culture
Engineering practices
IT Operations
Software defined networks
On-demand infrastructure provisioning
Architectural complexity
15
Source: https://bit.ly/2vf6eov

15. Microservices Drawbacks Solution
Plan ahead
DevOps
Use supporting platforms
Cloud
Containers
Architect
Low Coupling, High Cohesion
Schema/API Versioning
16

16. Cohesion
The degree to which a module
performs one and only one function
Strive for high cohesion
A module can be:
Library (assembly, shared module, DLL)
File
Class
Method
COM/CORBA component
(Micro) Service
Any reusable element

17. Coupling
The degree to which each program module
relies on each of the other modules
Low coupling often correlates with
high cohesion, and vice versa
Low coupling is
A sign of a well-structured computer system
Good design
When combined with high cohesion
Supports high readability, maintainability, extendibility, and
reusability
Micro Service Architecture == High Cohesion & Low Coupling

18. Why Should I Care About Coupling
Tightly coupled systems tend to exhibit the following
developmental characteristics
A change in one module usually forces a ripple (cascading) effect
of changes in other modules
Assembly of modules might require more effort and/or time due
to the increased inter-module dependency
A particular module might be harder to reuse and/or test because
dependent modules must be included
The DevOps process becomes a nightmare!!!
19

19. How to Decouple Microservices
Have a managed hosting environment
Cloud, Kubernetes, Service Fabric
Use messages (not types)
Use Queues
Or use Service Locators + Load Balancers
20

20. So Should I Do Microservices?
YES, but only if you have:
Capable architects
Rapid compute provisioning
Mature CI/CD pipelines
Advanced DevOps culture
OR – get some experts to help 
21
Source: https://bit.ly/2oro8Pi

21. 22
Erez Pedro, Head of UX (CodeValue)
UX Tools for Product Discovery

22. Agenda
What challenges can UX tools help with?
What is product discovery?
Goals
When should it be done?
Variations in discovery tools by product context
Ways to do blitz type product discovery
(GV’s Design Sprint, Design thinking)
What we do in our Discovery Workshop?
23

23. Hitting the target is as easy as:
Ready, Aim, Shoot!
24

24. Ready, Aim, Shoot!
Easy, right?
Sometimes you don’t hit the mark
You have a limited number of arrows
Moving targets
25

25. Design Sprint
Understand Define Diverge Decide Prototype Validate
Google Design Sprint

26. • Group conclusion
• Joint ownership
• Quick reviews with clarifications
Product Manager
(inbound)
Business
(outbound)
UX
Architect
Technical
Architect

27. Ready – Product Vision
28

28. Ready - need to identify a target
In the beginning it is all a blur
Need to decompose the problem
29

29. Ready, for what?
Business goals
Functional goals
Usability goals
30

30. Variation in Market Focus
31
Fun consumer product
Professional tool
High
Medium
Low
Efficiency Effectiveness Error Tolerant Easy to learn Engaging

31. Stand out in the crowd
32

32. Identifying our users
33

33. User analysis tools
Origin: Anthropology
Tribal behavior
It is relevant?
Duhh!

34. Its often about desire not always needs
35
Watch & Listen to your users

35. Understanding our user’s state of mind
36“Adapting empathy maps for UX design.” Paul Boag

36. Aim - product vision  product requirements
Concentrate on customer pain points
What will create the most value - USP?
What should the product experience feel like?
37

37. Focusing on biggest pain points
OnBoarding Search Criteria Review Results Comparison
& Decision
Exit
funnel

38. Discovery is a mental
state, not just a project
phase.
“

39. Customer Friend that knows The listing system Barbershop coordinator
Need to find a
barber
Time for a cut
Search for a
barbershop
Select a barbershop
What do they offer?
List of services in selected
barbershop
Select service(s)
Find available slots
List of services
<Initial>
List of services
<available>
List of services
<Requested>
Select slot and pay
List of open slots
<available>
Set a reminder
Find relevant shops
Book the slot for selected service(s)
Book in calendar
Workflow analysis

40. Product Visualization
in Flow

41. Shoot!
Release now?
Do something before?
42

42. The solution
Guided arrow/ missile
43
https://youtu.be/PWiU_HIZ4Jc

43. Testing with LoFi prototypes

44. 45
Ronen Rubinfeld, Dev. Management & Methodology Lead (CodeValue)
Planning the unexpected…
Dealing with today's rapidly changing reality
using Agile

45. Today’s reality
Complexity
Uncertainty
Complexity
Ambiguity
Change
Fast
Early
Risk

47. So, how do we do it then?...
Complexity
Uncertainty
Risk
Change
Value
Agility

48. 49
Today’s Products are…

49. The “Agile Challenge”
Bottom Up
Top Down
Work incrementally in small steps
while
Seeing the big picture

50. The Process

51. Backlog
Feature Feature
FeatureFeatureFeature
FeatureFeature Feature
Feature Feature Feature
Feature
Feature
Overall Product
Process Outline

52. Backlog: Views
Single Requirements Repository - Different Views
Product Backlog
• Holds all Requirements of the Product
• Regardless the expected release planning
• Managed on Epic / Feature level
Release Backlog
• Defines the scope of a given Release
• Baseline is defined at the beginning of the Release
• Requirements detailing evolves throughout the Release’s lifetime
• Additions / modifications to the Release backlog are managed in a formal process
Sprint Backlog
• Defines the scope of a given Sprint on a US level
• Finalized and signed-off close to the Sprint’s begging
• Committed upon the beginning of the Sprint
Release 1
Release 2
Release 3
Product
Backlog
Sprint 1
Sprint 2
Sprint 3

53. Product Backlog: Hierarchical Structure
Epic
• Top-level breakdown of the Product
• Describe the “Investment Buckets” / Main goals of the Product
• Can be considered as a “Convenience” level
Feature
• The “what” – what is implemented
• Smallest functional increment that provides value to the end-user
• Implementation should be completed within a Release
• Can be implemented by several teams
Product Backlog Item / User Story
• The “how” – Breakdown of the Features to implementation details
• Smallest functional increment that provides value to the System
• Implementation should be completed within a single Sprint
• Should be implemented by a single Team
• Reflects the architecture and potentially the org structure
Epic
Feature
User
Story
Epic
Feature
User Story

55. Agile Heartbeat
Release 1 Release 2
Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5 Sprint 6 Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5 Sprint 6
3 Months 3 Months
2 Weeks 2 Weeks 2 Weeks 2 Weeks 2 Weeks 2 Weeks 2 Weeks 2 Weeks 2 Weeks 2 Weeks 2 Weeks 2 Weeks
Project
Product
BL

56. Release Heartbeat
Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5 Sprint 6
2 Weeks 2 Weeks 2 Weeks 2 Weeks 2 Weeks 2 Weeks
Release 1
Plan Implementation Stable
Product
Backlog
Release 1
Sprint1
Sprint2
Sprint3
Sprint4
Sprint5
Sprint6

57. Release Heartbeat
Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5 Sprint 6
2 Weeks 2 Weeks 2 Weeks 2 Weeks 2 Weeks 2 Weeks
Release 1
Plan Implementation Stable
Product
Backlog
Release 1
Sprint1
Sprint2
Sprint3
Sprint4
Sprint5
Sprint6
User
Story
User
Story
User
Story
User
Story
User
Story
User
Story
User
Story
User
Story
User
Story
Feature
Feature
Feature
User
Story
User
Story
User
Story
User
Story
User
Story
User
Story
User
Story User
Story
User
Story
User
Story
User
Story

58. Agile Heartbeat
Release 1
Plan Implementation Stable
Release 2
Plan Implementation Stable

59. 60
Takeaways

60. 62