O slideshow foi denunciado.
Utilizamos seu perfil e dados de atividades no LinkedIn para personalizar e exibir anúncios mais relevantes. Altere suas preferências de anúncios quando desejar.

Agile Technical Leadership

267 visualizações

Publicada em

Slides for a workshop on agile technical leadership.

Agile teams are complex adaptive systems. In order to obtain a certain level of consistency, required when you want effective teams, teams have to set constraints on themselves and to make strategic decisions. This workshop explores some of the constraints and the difficulties of making strategic technical decisions.

Publicada em: Software
  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

Agile Technical Leadership

  1. 1. Agile Technical Leadership Alex Bolboacă,  @alexboly,  alex.bolboaca@mozaicworks.com October 2017
  2. 2. The Problem One Solution: Technical Leadership Some Context Let’s Explore Together Closing
  3. 3. The Problem
  4. 4. Tell me if this sounds familiar Someone made a decision 5 years ago that is now very costly to maintain and very costly to change Eg. caching
  5. 5. Tell me if this sounds familiar A set of incremental decisions has led to a difficult context Eg. customize the product for each customer, end up with hundreds of different versions
  6. 6. Tell me if this sounds familiar More teams work on a product, each made their own architectural decisions and now code is inconsistent Eg. 15 different interprocess communication methods
  7. 7. What do these have in common?
  8. 8. Complex adaptive systems! … dynamic network of many agents (which may represent cells, species, individuals, firms, nations) acting in parallel, constantly acting and reacting to what the other agents are doing. John H. Holland
  9. 9. Interesting because … The control of a CAS tends to be highly dispersed and decentralized. If there is to be any coherent behavior in the system, it has to arise from competition and cooperation among the agents themselves. The overall behavior of the system is the result of a huge number of decisions made every moment by many individual agents.
  10. 10. So
  11. 11. There’s another way Constraints!
  12. 12. One Solution: Technical Leadership
  13. 13. Agile Technical Leadership The responsibility of setting constraints in order to make the development more effective on mid/long term The responsibility of making strategic technical decisions
  14. 14. Can there be technical leadership in agile? Not only it can, there always is. We want more. We want effective technical leadership.
  15. 15. Who should do technical leadership? • Technical leads? • Architects? • CTOs? • Everybody? • Nobody?
  16. 16. Main thesis Technical leadership is a core competency that will be filled formally or informally in any development team. To ensure effective development, we need to understand better how technical leadership works in agile teams.
  17. 17. Some Context
  18. 18. All our practices are constraints Code review - someone else needs to give feedback on the code you wrote Pair programming - work with someone else on complex tasks TDD - write one failing test, write the minimum code to make it pass, refactor Continuous Integration - keep everyone’s changes integrated as quickly and as often as possible Daily meeting - synchronize daily with your team mates
  19. 19. Crafters movement As a software crafter, I choose to impose constraints on myself because I believe they are valuable Following constraints = discipline
  20. 20. Side note “Scrum assumes craftsmanship”, Ken Schwaber, OpenAgile Romania 2009
  21. 21. Strategic vs. Tactic decisions Strategic decisions are decisions you need to make but are difficult to revisit later Eg. choice of programming language, architecture style, deployment etc. Tactical decisions are decisions you need to make but are easy to revisit later Eg. how we implement an algorithm
  22. 22. Few more ideas “Cross functional” means teams have all the necessary competencies. This includes the competency of setting constraints and making strategic technical decisions Technical leadership is formal or informal. It doesn’t matter as long as it’s effective.
  23. 23. Let’s Explore Together
  24. 24. Group exercise: Constraints As a group, discuss and write down a list of constraints that you use in your teams and the reasoning behind using them. Hint: imagine you had no constraints at all, and compare with the current way of working
  25. 25. Example In Mozaic Works we use: • checklists because they help us maintain a high level of quality even when under pressure • unit testing because it validates faster the correctness of the product • design elements because it allows people who are learning design to create consistent and correct code faster • BDD Specs because they help clarify requirements before starting • domain modeling because it helps minimise database migrations • continuous deployment because it helps reduce deployment risks
  26. 26. Group exercise: Practices of technical leadership As a group, imagine you are the new technical lead for your product. Imagine you can change anything. What would you do? Can you extract a list of practices?
  27. 27. Example In Mozaic Works, I have: • defined a clear technical vision: only full stack developers, responsible from analysis to deployment, responsible for the quality of their work • defined a testing strategy: what we test, with what types of tests etc. • defined coding guidelines. Key ideas: focus on simplicity & readability, write as little code as possible • defined the configuration management policy: when to push, when to branch, when to merge, how branches relate to production / staging / testing etc. • helped developers adopt the practices we need: training, deliberate practice with daily katas & coding dojos etc. • kept in touch with the developers needs through one-to-one meetings and writing code together
  28. 28. Group exercise: make a strategic decision You are in charge with deciding what web framework to use for a brand new project in your company. What criteria do you use to make your decision?
  29. 29. Answer When I picked groovy on grails for our product, I looked at three different frameworks, built prototypes and compared: • how easy it is to write a simple web application • how easy it is to write tests • the community • the reported bug count
  30. 30. Reflect Was it difficult to make this decision? Why? How confident are you that you made the right decision?
  31. 31. Group exercise: Strategic decisions As a group: • think about and write down a list of strategic decisions that were made for your product • pick one decision you are unhappy with • what would you decide instead? Reminder: strategic decisions are decisions difficult to change once they are made. They typically affect more people and have effect over a longer period of time.
  32. 32. Example In Mozaic Works, I have decided to: • use groovy on grails for all web applications • use reactjs for complex front end pages • use wordpress for all our websites BUT: • I am looking at more lightweight alternatives to grails (memory consumption is high and costly on cloud). • I put too much emphasis on learning and not enough on speedy delivery.
  33. 33. Group exercise: mindset required for strategic decision making You are now part of a technical leadership group for your product. You need to make decisions related to: • architecture that can affect next 2 years of development • practices to use in teams to help improve effectiveness • tools to adopt for improving code quality As a group, think and write down: • what is challenging when making strategic decisions? (hint: uncertainty, incomplete information) • what mindset should somebody have to make effective strategic decisions? (hint: should be able to cope with uncertainty)
  34. 34. Learning strategic decision making Bad news: not native Good news: can be learned through practice Where to start: • decision models • find three solutions for every problem • understand advantages and disadvantages for each solution • CIA checklist • identifying criteria before evaluating solutions • looking at a problem from different angles • thinking at different levels of abstraction • be comfortable with incomplete information and uncertainty
  35. 35. Closing
  36. 36. What did you learn? Individually, write down one thing you learned today. Can you apply it in your team?
  37. 37. Learn more Mozaic Works blog https://blog.mozaicworks.com
  38. 38. Thank you! I’ve been Alex Bolboacă, @alexboly, alex.bolboaca@mozaicworks.com programmer, trainer, mentor, writer at Mozaic Works Think. Design. Work Smart. https://mozaicworks.com
  39. 39. Join me for Berlin workshops https://mozaicworks.com/calendar/#Berlin
  40. 40. Q&A Q&A