8. Scaling up is like jumping directly
from childhood to parenthood,
skipping important phases of your life.
The play is over.
It’s serious business,
with serious responsibilities.
“
”
11. GROWTH CHANGES TEAM DYNAMICS
11
• Team Imbalance is lurking
• Roles need to get more Focused
• Reporting Lines may need to be adjusted
(carefully - potential trouble ahead)
• Split Conflicting Roles
• CTO ≠ (any Agile role)
• Lead Dev ≠ CTO ≠ CIO
• PO ≠ CTO
• PO ≠ Developer
• CEO ≠ PO ≠ HR ≠ COO (more later)
COMPANYSTRUCTURE&CULTURE
12. BEAWARE OF CHANGING DYNAMICS
12
• Risks when hiring more Juniors
• Coaching role may not suit every senior
• Issues with (perceived) Productivity
• Junior/senior Imbalance
• Risks when hiring more Seniors or changing Reporting Lines
• Team Members Feeling Undervalued
• Negativity
• Toxicity
COMPANYSTRUCTURE&CULTURE
13. QUIT STARTUP HABITS
13
• Re-evaluate Opportunistic Decisions
• Most early Startup decisions are extremely pragmatic
… but might hurt later on
• CEO/Founder roles need to change
• A Pioneer is (mostly) not a Manager
• Quit being the go-to-point for everything
• Hire Operational Manager?
• HR & Hiring Strategy
• Be clear about your Core Values
• Keeping developers Loyal is crucial but complicated
It’s a buyers’market
• Recruiters & Headhunters are a Reality to deal with
• Give your people a realistic Growth Path
• Care for a good Team Culture
COMPANYSTRUCTURE&CULTURE
15. TEAM CULTURE CAN BE INFLUENCED
15
• Make communication a priority
• Reinforce the Important Ideas consistently
• Show the Bigger Picture to Everyone!
• Help everyone understand how they contribute
• Value everyone’s Ideas
• Trust your team
• Let team members get to know each other outside work
• Have some Fun!
• Disrupt the all-male culture
It works ;-)
• Empathic, Facilitating Leadership
Instead of Directive Management ➔ How can you make people thrive?
• Promote a Culture of Learning
COMPANYSTRUCTURE&CULTURE
17. VALUE & EXIT STRATEGY
17
• Potential investors or purchaser will do Due Diligence on your company,
and they will look very closely at your Intellectual Property.
• Maintain focus on Intellectual Property through the entire life of the
business.
• Negligence in protecting IP influences the Selling Price.
…but…
What does this have to do with Team & Process?
DEVELOPMENT TEAM&PROCESS
18. IT’S THE IP, BABY
18
• Insource & Outsource pieces of Software Development based on…
DEVELOPMENT TEAM&PROCESS
YES NO
Insource
(if possible)
Outsource,
Contract,
Partner
One Simple Question:
Is Intellectual Property involved?
19. NOT EVERYBODY KNOWSAGILE ENOUGH
19
A few reminders about Agile…
Why work Agile?
• Decrease Time-to-Market
• Accelerate Product Delivery
• Improve Effectiveness to manage changing priorities
• Enhance Software Quality
• Enhance Delivery Predictability
• Improve Project Visibility
• Reduce project Risk
DEVELOPMENT TEAM&PROCESS
20. HOW TO DOAGILE?
20
There is no single “right” way
Agile Manifesto’s Values & Principles:
• Effective interaction between people is critical to any project success.
• Teams should be trained together, undergo deliberate team formation, and be
given the time to understand what it means to work in an Agile fashion.
• Do not underestimate the need for and impact of customer collaboration and
response to change.
• Trust of and within the team.
DEVELOPMENT TEAM&PROCESS
21. THE MOST IMPORTANT AGILE ELEMENTS
21
• The Rituals (ceremonies)
• Sprint Planning
• Daily Stand-up
• Iteration Review/Demo
• Retrospective
• Keeping Stakeholders Close
• Continuous Feedback
• Product Backlog is a Living Document
… and you need a dedicated PO (more…)
DEVELOPMENT TEAM&PROCESS
22. DEDICATED PRODUCT OWNER (PO)
22
• Product Backlog
Prioritized features list for the product
• User Stories
As a < type of user >, I want < some goal > so that < some reason >.
• Definition-of-Done
Consistent acceptance criteria across all User Stories
• Backlog Refinement (grooming)
• Removing user stories that no longer appear relevant
• Creating new user stories in response to newly discovered needs
• Re-assessing the relative priority of stories
• Assigning estimates to stories which have yet to receive one
• Correcting estimates in light of newly discovered information
• Splitting user stories which are high priority but too coarse grained to fit in an upcoming
iteration
DEVELOPMENT TEAM&PROCESS
23. CODE NEEDS TO SCALE TOO (1/2)
23
• The acronyms ;-)
DEVELOPMENT TEAM&PROCESS
24. CODE NEEDS TO SCALE TOO (2/2)
24
• Sustainable Code Base
• SOLID principles
• Clear Separation of Concerns (SoC)
• Modular / Reduced Complexity
• Require Documentation
• Unit Testing
• Reduce Technical Debt (structurally)
• Isolate Core and Integrations
• Attention to Non-Functional Requirements
Such as Robustness, Reusability, Fault-tolerance, Stability, Resilience…
DEVELOPMENT TEAM&PROCESS
25. CONTROL YOUR SH*T
25
• Quality Assurance & Control
• Peer Reviews + Peer decision making
• Testing at all levels
• Deployment (CI/CD)
• Technical Governance (CTO)
• Security
• Compliance
• GDPR/AVG
• SLAs
DEVELOPMENT TEAM&PROCESS
26. DOCUMENTATIONAND KNOWLEDGE SHARING
26
• Documenting is Developers’ least favorite activity
• Documenting has proven to improve software!
Especially if done early!
• Everyone’s responsible, everyone should contribute!
• Make Inline Documentation in code mandatory → DoD
• Implement a good Knowledge System
Consider a Wiki (such as Confluence)
• Implement Review Dates & Workflows
• QA is end-responsible
• CTO oversees & implements Governance
DEVELOPMENT TEAM&PROCESS
28. RECONSIDER YOURARCHITECTURE
28
• Don’t keep building on top of a Prototype/PoC
• Architecture & Release Platform are interdependent
Cloud is not just an alternative
Infrastructure!
ARCHITECTURE&INFRASTRUCTURE
29. CLOUD SOLUTIONS: REDUCED RESPONSIBILITIES
Focus on your Applications and Data
29ARCHITECTURE&INFRASTRUCTURE
30. CLOUD SOLUTIONS:A DIFFERENT SPECIES
You better adapt!
30
Traditional on-premises Native Cloud
Relational database Polyglot persistence
Strong consistency Eventual consistency
Design for predictable scalability Design for unbound scalability
Serial and synchronized processing Parallel and asynchronous processing
Monolithic, centralized Decomposed, de-centralized
Snowflake servers Immutable infrastructure
Integrated authentication Federated authentication
Design to keep app running (MTBF) Design for failure (MTTR)
Onetime big update Frequent small updates
Manual management Automated self-management
ARCHITECTURE&INFRASTRUCTURE
31. POLYGLOT PERSISTANCE
31
• Data is part of the architecture!
• Bottlenecks are often related to Storage
• Relational Databases are not Self-Evident anymore
• Consider Polyglot Persistance
• RDBMS (SQLServer, Oracle, MySQL, Postgres, etc.)
• Document Databases (Mongo, Cosmos/DocumentDB, etc.)
• Graph Databases (Neo4J, )
• Cache (Redis)
• Search Databases (ElasticSearch/Lucene, Solr, etc.):
• Binary Storage (Blob, etc.)
• Row Stores (TableStorage, etc.)
• Take Use-Cases into account for Choice of Storage
Transactional, high read throughput, high consistency?
ARCHITECTURE&INFRASTRUCTURE
32. AFEW CONSIDERATIONS
32
• Modularize!
(Micro)services, data layers, REST, etc.
• Use PaaS/Serverless where possible
(Avoiding Cloud lock-in doesn’t prevent that)
• Leverage ready-to-use Intelligent Cloud Services
• Remove Bottlenecks & Single Points of Failure
Queues, Cache, Events, etc.
• Think Async
The Mobile Revolution’s impact
• Invest in an integrated deploy pipeline
Only possible if you first invest in structural testing!
ARCHITECTURE&INFRASTRUCTURE
34. AGILE ROADMAP
34
• Domain Knowledge is essential!
• In Agile, a product roadmap as a Statement of Intent
• Evaluate the Role of Time for your roadmap
• Remember the Audience of your agile product roadmap
and tailor to them
• Make it visible within the whole Team
PRODUCTDESIGN&ROADMAP
36. MAKE UX LEADING
36
• Personas ➔ Journeys ➔ Flows
• Storyboarding
• Use/Create a Modular Design System
Atomic design
• Use modern UX Tooling
Clickthrough Prototypes
PRODUCTDESIGN&ROADMAP
37. INVEST IN FEEDBACK LOOPS
37
• Direct Feedback about your product, preferably contextual.
• Take feedback serious and use it in for Continuous Improvement
(Design Thinking)
• Continuous Measurement of interaction with the product,
all feeding back into design and development.
Booking.com A/B ➔ Conversion ➔ auto-deploy
PRODUCTDESIGN&ROADMAP