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.

1. Agile Technical Leadership
Alex Bolboacă,  @alexboly,  alex.bolboaca@mozaicworks.com
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

11. There’s another way
Constraints!

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.

23. Let’s Explore Together

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, alex.bolboaca@mozaicworks.com
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