Agile Technical Leadership
1 like454 views
The document outlines the importance of technical leadership in agile development, emphasizing that it is a core competency necessary for effective decision-making and development. It discusses the distinction between strategic and tactical decisions, noting that strategic decisions can have long-lasting impacts and are often difficult to revise. Group exercises are proposed to help teams understand and implement effective technical leadership practices and decision-making skills.
Agile Technical Leadership
- 1. Agile Technical Leadership Alex Bolboacă, @alexboly, [email protected] October 2017
- 2. The Problem One Solution: Technical Leadership Some Context Let’s Explore Together Closing
- 3. The Problem
- 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. 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. 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. What do these have in common?
- 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. 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. So
- 12. One Solution: Technical Leadership
- 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. Can there be technical leadership in agile? Not only it can, there always is. We want more. We want effective technical leadership.
- 15. Who should do technical leadership? • Technical leads? • Architects? • CTOs? • Everybody? • Nobody?
- 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. Some Context
- 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. Crafters movement As a software crafter, I choose to impose constraints on myself because I believe they are valuable Following constraints = discipline
- 20. Side note “Scrum assumes craftsmanship”, Ken Schwaber, OpenAgile Romania 2009
- 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. 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.
- 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. 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. 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. 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. 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. 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. Reflect Was it difficult to make this decision? Why? How confident are you that you made the right decision?
- 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. 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. 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. 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. Closing
- 36. What did you learn? Individually, write down one thing you learned today. Can you apply it in your team?
- 37. Learn more Mozaic Works blog https://blog.mozaicworks.com
- 38. Thank you! I’ve been Alex Bolboacă, @alexboly, [email protected] programmer, trainer, mentor, writer at Mozaic Works Think. Design. Work Smart. https://mozaicworks.com
- 39. Join me for Berlin workshops https://mozaicworks.com/calendar/#Berlin
- 40. Q&A Q&A