How Engineering Drives Agility

How Engineering Drives Agility

As mentioned at the book Accelerate: “Many Agile adoptions have treated technical practices as secondary compared to the management and team practices that some Agile frameworks emphasize. The research shows that technical practices play a vital role in achieving these outcomes.” Agility can never be achieved with crap software. Any attempt to implement Scrum in your team makes you feel uncomfortable when you have tons of technical debt in place but never prioritized.

In this talk, four important topics will be covered:
1. Why is technical excellence one of the most important area for reaching agility?
2. What are the strategies to transform the engineering team?
3. What are the technical practices to follow?
4. What is the roadmap through agility from technical perspective?

All the answers will be supported with real-life cases, with failures and successes. The workshop is highly recommended for the audience who wants to hear how and which technical practices can have impact on agility and how a technical roadmap can be designed.


Lemi Orhan Ergin

October 24, 2019


  1. 2.
  2. 4.
  3. 6.

    problem identification f*ckups and lessons learned qualitative research methods (kpi’s,

    metrics, etc.) unstructured data analysis (interviews, surveys, etc.) funnel analysis user needs identification storytelling, brainstorming product backlog management idea emerge
  4. 8.

    prototyping proposed mvp / mvi cost of delay analysis sprint

    and release planning voting, poker planning portfolio planning (big room planning) idea prioritized idea emerge
  5. 10.

    monoliths /microservices evolutionary architecture, emergent design hexagonal architecture / ports

    and adaptors branching mechanisms / trunk based development automated tests (unit, integration, functional, etc) pair & mob programming code review, team standards continuous integration design patterns & refactoring test driven development (tdd, bdd, atdd) development started idea prioritized idea emerge consumer driver contract testing transaction management static code analysis event handling / messaging non-blocking io, data streaming monitoring & traceability resilient architecture asynchronous communication cache management rest / grpc api management
  6. 12.

    load and performance testing manual user acceptance penetration testing release

    and rollback procedures exploratory testing harnessing development started idea prioritized idea emerge
  7. 14.

    deployment strategies feature flagging monitoring, tracing, profiling disaster recovery &

    chaos testing canarying & a/b testing journey tests going live harnessing development started idea prioritized idea emerge
  8. 19.

    idea prioritized development started harnessing going live idea emerge Product

    development is based on fail fast, fail early and fail safe That requires discovery by doing fast experiments
  9. 20.


  10. 21.

    Agile doesn’t cure INCOMPETENCE. You can coach teams to be

    more engaged and collaborative, but NO Agile framework, method, or mindset can save you from BLATANT FAILURE if your development team is INCOMPETENT in basic engineering practices. Technical excellence is a MUST! Mike Beedle @mikebeedle 7:48 PM · Mar 21, 2018 Mike Beedle (died at March 23, 2018) Agile Manifesto co-creator proposed the term “agile” to manifesto co-creators introduced “Enterprise Scrum” and “Business Agility”
  11. 22.

    First-Aid Strategy: Hire A-class talents Stop overtime, push for productivity

    and efficiency Increase transparency with the whole company Stop adding new features, start fixing bugs Add new communication channels with business Establish on-call procedure for engineers (Batman, Robin, Alfred) Define a roll-out plan for big refactorings/replacements Define a strategy for technical excellence HTCtechnologY hiring culture
  12. 23.

    Phase 1: Well-Crafted Base Phase 2: Robust and Maintainable Phase

    3: Continuously Delivering Value Mindset: Slow down to go faster Phase 0: Development Sucks!
  13. 24.

    Phase 0: Development sucks! Following best practices without knowledge and

    experience Following GitFlow or having long feature branches Microservice acting monoliths Too much technical debt Finish all steps and deploy at the very end No production release for months Complex deployment procedures Having silos, individual work is more valuable Developers are just code-monkeys Jira based Scrums, Scrum-fall sprints Micro-management with Scrum No/few tests, huge manual test cost No continuous verification/testing, no CI Definition of Done: Development done, and tested at local
  14. 25.

    Phase 1: Well-Crafted Base Realizing the reasons behind best practices

    Master-Feature branching mechanism Weekly releases Code reviews via pull requests CI/CD pipeline, deploy to production from the first day PreProd and production environments Manual preprod deployment with one click Pair programming Mono repository for easy refactoring Test driven development Hexagonal architecture for all microservices No Silo, Lunch & learn sessions (BBS) Definition of Done: Deployed to preprod
  15. 26.

    Phase 2: Robust and Maintainable Can define why good practices

    are better than the bad ones Common standards, efficient team work Multiple releases per week, blue/green deployment Automatic PreProd deployment after merge with master Consumer driven contract testing Anomaly detection, recovery from failures Mob programming Automatic functional testing Simulation testing, Load testing Quality assurance Domain Driven Mono-Repo Definition of Done: Complete testing at preprod
  16. 27.

    Phase 3: Continuously Delivering Value Believe no practice is better

    than others On-demand environment creation at merge requests Multiple releases per day, canary deployment Version control for everything, like db and infra More pairing and mobbing Code review sessions with team No branches, just master, feature flags Reliable, robust, resilient architecture Trunk-based Development, No pull requests Automatic acceptance tests Resilient architecture Continuous Delivery & Deployment Definition of Done: Deployed to production, and verified
  17. 28.

    Phase 4: No Framework What you do is your framework

    Highly customized for your team, your domain Empowered teams, de-scaled organization Able to introduce new stacks New team for governing architectural crosscuts Definition of Done: Metric based verification at production
  18. 29.

    Many Agile adoptions have treated technical practices as secondary compared

    to the management and team practices that some Agile frameworks emphasize. Our research shows that technical practices play a vital role in achieving these outcomes. Nicole Forsgren PhD, Jez Humble, et al. Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations