Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Technical Leadership in an Agile World

Technical Leadership in an Agile World

Software development process has changed dramatically since the advent of Agile methodologies. The fast pace of change of Agile has introduced a number of challenges that the industry has been having a hard time to overcome. Although technical leadership is not part of Agile, the role of technical lead is present in many companies organizational charts. The goal of this presentation is to discuss that role and how it can align with Agile values.

Marcelo Benites

April 04, 2019
Tweet

More Decks by Marcelo Benites

Other Decks in Programming

Transcript

  1. Agile Manifesto Timeline • 1999 - Continuous Integration/Continuous Delivery/Continuous Deployment

    (Kent Beck) • 2000 - Test-Driven Development (Kent Beck) • 2000 - Refactoring (Martin Fowler)
  2. Agile Manifesto Timeline • 1999 - Continuous Integration/Continuous Delivery/Continuous Deployment

    (Kent Beck) • 2000 - Test-Driven Development (Kent Beck) • 2000 - Refactoring (Martin Fowler) • 2001 - Extreme Programming in Practice (Robert Martin)
  3. Agile Manifesto Timeline • 1999 - Continuous Integration/Continuous Delivery/Continuous Deployment

    (Kent Beck) • 2000 - Test-Driven Development (Kent Beck) • 2000 - Refactoring (Martin Fowler) • 2001 - Extreme Programming in Practice (Robert Martin) • 2001 - Agile Manifesto
  4. Agile Manifesto Timeline • 1999 - Continuous Integration/Continuous Delivery/Continuous Deployment

    (Kent Beck) • 2000 - Test-Driven Development (Kent Beck) • 2000 - Refactoring (Martin Fowler) • 2001 - Extreme Programming in Practice (Robert Martin) • 2001 - Agile Manifesto • 2003 - Domain-Driven Design (Eric Evans)
  5. Agile Manifesto Timeline • 1999 - Continuous Integration/Continuous Delivery/Continuous Deployment

    (Kent Beck) • 2000 - Test-Driven Development (Kent Beck) • 2000 - Refactoring (Martin Fowler) • 2001 - Extreme Programming in Practice (Robert Martin) • 2001 - Agile Manifesto • 2003 - Domain-Driven Design (Eric Evans) • 2006 - Behavior-Driven Development (Dan North)
  6. Agile Manifesto Timeline • 1999 - Continuous Integration/Continuous Delivery/Continuous Deployment

    (Kent Beck) • 2000 - Test-Driven Development (Kent Beck) • 2000 - Refactoring (Martin Fowler) • 2001 - Extreme Programming in Practice (Robert Martin) • 2001 - Agile Manifesto • 2003 - Domain-Driven Design (Eric Evans) • 2006 - Behavior-Driven Development (Dan North) • 2008 - DevOps (Patrick Debois and Andrew Shafer)
  7. Agile Manifesto Values • Individuals and interactions over processes and

    tools • Working software over comprehensive documentation • Responding to change over following a plan • Customer collaboration over contract negotiation
  8. Software Engineer • Has excellent Verbal Communication. • Easily switches

    between different levels of abstraction. ◦ Discuss Story/Behavior with Product Manager. ◦ Discuss Technical Details with other Software Engineers.
  9. Software Engineer • Has excellent Verbal Communication. • Easily switches

    between different levels of abstraction. ◦ Discuss Story/Behavior with Product Manager. ◦ Discuss Technical Details with other Software Engineers. • Collaboratively breaks high level Features into independent Stories.
  10. Software Engineer • Has excellent Verbal Communication. • Easily switches

    between different levels of abstraction. ◦ Discuss Story/Behavior with Product Manager. ◦ Discuss Technical Details with other Software Engineers. • Collaboratively breaks high level Features into independent Stories. • In programming-time translates a Story to Technical Requirements.
  11. Software Engineer • Has excellent Verbal Communication. • Easily switches

    between different levels of abstraction. ◦ Discuss Story/Behavior with Product Manager. ◦ Discuss Technical Details with other Software Engineers. • Collaboratively breaks high level Features into independent Stories. • In programming-time translates a Story to Technical Requirements. • Writes the minimum amount of code that delivers the Story.
  12. Software Engineer • Has excellent Verbal Communication. • Easily switches

    between different levels of abstraction. ◦ Discuss Story/Behavior with Product Manager. ◦ Discuss Technical Details with other Software Engineers. • Collaboratively breaks high level Features into independent Stories. • In programming-time translates a Story to Technical Requirements. • Writes the minimum amount of code that delivers the Story. • Practices Incremental Design over Upfront Design.
  13. Software Engineer • Has excellent Verbal Communication. • Easily switches

    between different levels of abstraction. ◦ Discuss Story/Behavior with Product Manager. ◦ Discuss Technical Details with other Software Engineers. • Collaboratively breaks high level Features into independent Stories. • In programming-time translates a Story to Technical Requirements. • Writes the minimum amount of code that delivers the Story. • Practices Incremental Design over Upfront Design. • Practices Continuous Refactoring.
  14. Software Engineer • Has excellent Verbal Communication. • Easily switches

    between different levels of abstraction. ◦ Discuss Story/Behavior with Product Manager. ◦ Discuss Technical Details with other Software Engineers. • Collaboratively breaks high level Features into independent Stories. • In programming-time translates s Story to Technical Requirements. • Writes the minimum amount of code that delivers the Story. • Practices Incremental Design over Upfront Design. • Practices Continuous Refactoring. • Writes different layers of Automated Tests so he/she is not afraid of the code.
  15. Software Engineer • Has excellent Verbal Communication. • Easily switches

    between different levels of abstraction. ◦ Discuss Story/Behavior with Product Manager. ◦ Discuss Technical Details with other Software Engineers. • Collaboratively breaks high level Features into independent Stories. • In programming-time translates a Story to Technical Requirements. • Writes the minimum amount of code that delivers the Story. • Practices Incremental Design over Upfront Design. • Practices Continuous Refactoring. • Writes different layers of Automated Tests so he/she is not afraid of the code. • Easily switches between different platforms/programming languages to deliver the Story.
  16. What is NOT Technical Leadership? • Budget Management. • Expectation

    Management. • People Management. • Career Management.
  17. What is NOT Engineering Management? • Software Architecture. • Project

    Management. • Technical Decisions. • Team Assembling*
  18. High Level External Interfaces - Android - iOS - Web

    - MacOS - Windows - REST API Application Business Rules - Logic for a specific application. - Irrespective of technology.
  19. High Level External Interfaces - Android - iOS - Web

    - MacOS - Windows - REST API Application Business Rules - Logic for a specific application. - Irrespective of technology. Enterprise Business Rules - Cross- Application Logic - Infrastructure - Security
  20. High Level Chief Architect Architect Architect Architect Technical Leadership Mentorship

    Architecture Consistency Guidance Software Culture Software Practices Decision Making
  21. Low Level Architect Software Engineer Software Engineer Technical Leadership Mentorship

    Architecture Consistency Guidance Software Culture Software Practices Decision Making Software Engineer
  22. There is a limit for parallelism. Sometimes more people will

    just make the company slower, not faster.