Agile on the Beach 2021

AOTB Notes

Cancelled:

• Hiding in plain sight
• Danger - collaboration

2/9/21, Kevlin Henney, keynote

I turned this into a Twitter thread here.

• Agile = move quickly and easily
• …but agility is not about speed, it’s about being able to respond to change.
• There are two things that people hate - things changing, and things staying the same.
• Velocity is not just speed - it is speed plus direction. It’s no use going fast if you’re doing it in the wrong direction.
• The goal of the game is not to finish, it’s to keep playing.
• There’s a difference between faster and sooner.
• It shouldn’t be “move fast and break things”, it should be “move slow and mend things”
• When your job is to see things that others don’t, you have to slow down enough to be able to look.
• Decent architecture (inc. software) creates habitability - a place you can call home… A place where you can place your hand on anything without having to hunt it out.
• Productivity is a function of codebase size. Developers are dramatically less productive on larger bodies of code. Rob Smallshire.
• Prioritising by business value is not physically possible, because you have no crystal ball and don’t know, for instance, whether your innovation will sell. You can only prioritise by estimated business value.
• April Wensel, Compassionate Coding: Everyone you meet is fighting a battle you know nothing about. Be kind. Always.
• Hillel Wayne: sleep quality and stress levels matter far more than anything else, including TDD.
• The task of collaboration is in fact beautiful and serious.

2/9/21, Feminist leadership, Patti Hicks-Whaley

• you have to change leadership structures
• Patti is from Action Aid
• They deliberately changed their board to increase diversity (it was v white male middle aged)
• ** Top ten basics of feminist leadership - see photo of slide - the missing word on the right is bias (dismantling bias)
• What’s so revolutionary about that? Just common sense, right?
• Feminist theory is not about always putting women first or making men feel bad just for being men.
• It’s about looking about whether power is used to empower or disempower, and whether it’s used individually or collectively. About creating a culture that’s more explicitly aware of power
• It’s not enough to implement policies and procedures, you have to look at underlying behaviours and biases.
• Being Wrong by Kathryn Schulz - it can be enlightening to let go of your self-assumptions of infallibility.
• There’s no guilt in having privilege, there’s only guilt in failing to use it for the common good.
• Story: conf: veggies complained meat eaters ate their sandwiches. So it was changed that veggie was default and meat eaters had to opt in. None of them asked for meat. Conf was 100% veggie. Meat eaters complained no meat. When told they could have asked, they said we don’t like having to ask. Showed up the hidden privilege of being a meat eater.
• A lot of privilege / bias comes from being the first speaker in a room when asked to respond. To remove that, ask people to start by writing down their responses.
• A woman knitting a scarf in a meeting picks up red thread when a man speaks, green thread when a woman speaks. Interesting coloured scarf results. Lovely idea!
• Two sets of process goals: respectful active listening, and becoming more comfortable with disagreement. Sometimes driving to consensus is not the best way of reaching decisions. Live with disagreement for a while. Don’t make it less, make it better. Disagree with trust and respect.
• Feedback: receiving feedback can be hard. Give people time, be compassionate.
• English choral tradition: if a choir member makes a mistake they hold their hand up, to indicate they know they made a mistake and they will fix it. This means the singing can continue with no need to interrupt.
• Expecting nobody, including one’s wife, to be one’s servant… requires formidable competence.
• If it’s not hard work, you’re not doing it properly. It’s not designed to make things easier - it’s to make things better.
• Do we have to call it “feminist”? Yes. It’s not about making things incrementally better, it’s about changing the power structure. If that makes you defensive, you should examine why. If we can’t acknowledge the privilege, we can’t change it. We are reaffirming our commitment to changing that power structure.
• ** Have structures at the start of each meeting that reminds you to do respectful listening, then at the end check in and ask, did we do it? How did we do?
• making Mondays suck less - Vu Le: https://nonprofitaf.com/about/

2/9/21, Systems thinking - Christian van boven

• use systems thinking as a tool to visualise dynamic processes
• Validate whether influencing factors can easily map onto a model
• Learning organisations - the fifth discipline by Peter senge
• Which areas in the system are high leverage?
• Shared vision
• Personal mastery
• Mental models
• Team learning
• These are the existing four disciplines
• The fifth is systems thinking (I think?)
• You want combined team iq to be higher than individual IQs but often that’s not the case
• We tend to look for simple fixes to simple problems, eg sales are not meeting targets so hire another sales rep
• But in reality there’s a lot more complexity
• It’s not just individual entities that contribute to how a system behaves, it’s the interaction between those elements
• Instead of reducing a system down to individual parts, look at synthesis of how all parts interact
• You get reinforcing loops, which keep growing.
• Example of a reinforcing loop: sales growth creates demand creates word of mouth creates FOMO creates more sales growth
• You get balancing loops, which stay about the same (growth immediately balanced by decrease)
• Example of a balancing loop: success of product creates demand for more features creates too much work creates lower quality creates less demand… Things balance back down again.
• You get negative feedback loops (? Might not be called that?) which keep decreasing (I think I might be assuming this third kind? Not sure it was actually mentioned?)
• Systems thinking allows us to evaluate how to link software development to the business reality around us - provides guidance on what areas can have more leverage
• Understanding fault line drivers:
• Events - react
• Patterns and trends - anticipate
• Underlying structures and systems - design
• Mental models (assumptions, beliefs and values) - transform
• See photo for an example of the above, based on APIs and open source
• See second photo for another example - this time, increasing sales but R&D can’t meet demand and are worried about impacts on quality.
• See third photo for the diagram of the loops that are represented in this example
• These loops allow you to visualise how different parts of your org might be wiring against one another
• Might allow you to see your need to address your balancing loops rather than your reinforcing loops
• See pic of loops re software backlogs

2/9/21, Simon Skelton and Steve Smith - you build it you run it

• john Lewis has moved from 10 releases per year in 2017 to 5000 in 2021
• Lockdown has resulted in online sales taking much larger proportion of overall sales (many high street shops shut
• They had already combined delivery and ops but failed and split it back out again due to overload of operational effort
• But previously they had manual testing, minimum product owner input, bad correlation between test and live environments, various other problems
• See photo for list of you build it you run it principles, starting with “grow awareness”
• Availability targets are calculated by looking at what the revenue loss might be in case of problems, and that determines whether people are on call or not
• Slack incident channels are public, which means that people can observe and learn from how incidents are handled
• Low availability target = not on call, but any out of hours outages need to be dealt with the following day… So they are still incentivised to minimise those outages.
• Testing proficiency with quarterly chaos days
• Some team members (the most experienced ones) play the role of agents of chaos - which they really enjoy! By taking out the most experienced ones, you really test the amount of knowledge sharing with the rest of the team.
• People tend to prioritise fixing the issues they detect during chaos days

2/9/21, Lightning talk - leading indicators / lagging indicators

• wiki in a cafe full of customers, want to know how much business will be done here in the next hour?
• Look at the tables, because it’s so busy you might think they’re going to do great business - that’s a lagging indicator because these people have already ordered. Maybe this is the end of lunch hour?
• Or you could look at the queue. If it’s long, that suggests they’re about to do great business. That’s a leading indicator because the sales haven’t happened yet.
• A good example from tesco: a button offering new functionality you would like to use. When you click on it, it says (paraphrased) “sorry, this function doesn’t exist yet. We are just trying to gauge customer interest in this potential new feature.” How many people click on that button will give you a leading indicator!

3/9/21, Keynote - Gitte Klitgaard, psychological safety

Menti.com 4455 1044

• Esther Derby - “being professional is sometimes code for ‘suppressing personal emotions and needs’ “
• When you take your mask off, you don’t know who you are any more. You’ve been putting it on to fit in.
• My thought : masking is not only a thing for autistic people!
• Being yourself and psychological safety includes helping men to unwind the conditioning that they must not show emotions
• People trust her easily and readily because she is clearly herself (same applies to me?)
• She is explicit with clients at the start of engagements, that she will be honest and colourful etc - and if that doesn’t work for them, they shouldn’t hire her. I should do that too!
• Have psychological safety training sessions, where you ask people, what does psychological safety mean for you? What would you need?

3/9/21, Emily Bache - Samman technical coaching

I turned this into a Twitter thread here. The actual content of the tweets is here.

• My tweet thread of these notes is here: https://twitter.com/ClareSudbery/status/1434130606976339968?s=20
• Samman = Swedish, means “together”.
• An agile journey includes technical agile, and that’s the part that the Samman technical coaching method focuses on.
• Emily did a survey in the talk (using @Mentimeter) about what makes coding fun. The top choices were
  • 1. An end product that users care about, and
  • 1. Code that is clear and easy to understand.
• “Tech debt = deficiencies in internal quality that make it harder than it would ideally be to modify and extend” - @MartinFowler
• Research in 2019 suggested that companies waste 23% of their time due to technical debt.
• Tech debt is unavoidable: Iterative and incremental development automatically creates it. There will always be a gap between the design that’s in production and what you’ve realised (via user) you actually need.
• We can’t eradicate tech debt, but we can minimise it by creating code that is easy to extend and maintain .
• “satisfaction and wellbeing correlate with productivity” - Forsgren (@nicolefv) et al.
• What you want is developers who are skilled, take pride in what they do, and have a team culture of creating excellence.
• If you practice TDD, this will have a big impact on that goal.
• Samman consists of
  • 1. Daily learning hour
  • 1. Ensemble working.
• Daily working hour - planned and articulated with learning goals, using the techniques from Sharon Bowman (@sbowperson) - Training from the Back of the Room (https://www.bowperson.com/sharons-books/).
• Emily’s coaching website has suggestions for katas and other exercises you could use during a learning hour: https://sammancoaching.org/
• The first step in the learning hour will be a short “connect” activity, to discover what people already know, and connect that with what they’re about to learn.
• The learning hour should be a bit like a skiing lesson. You might already know how to get yourself from the top to the bottom of the slope on skis, but not how to slalom. A learning hour might involve people who can already code, but don’t yet know TDD.
• Learning TDD in a learning hour is like learning how to ski on a smooth simple slope with no obstacles and no other skiers. TDDing in real life (rather than in the artificial environment of a learning hour) is much harder!
• This is where the second part of the Samman method - ensemble work - comes in. Ensemble working is another (more positive) name for mob programming.
• This is described by Woody Zuill as “All the brilliant people working on the same thing, at the same time, on the same computer.”
• Ensemble working consists of:
  • Typist
  • Navigator, getting or requesting feedback from the rest of the team
  • Team members, providing input to the navigator
• You should rotate roles often - it’s a good idea to use a timer, although experienced teams may stop using a timer once they are confident in their ability to work together effectively.
• The coach will teach the team the ensemble working technique and the basics of TDD, and once they get comfortable with it take more of a step back, just giving extra guidance when needed.
• Ensemble working is much more likely to be successful if you start out with a facilitator.
• Emily has a training course about good ensemble working techniques.
• A Samman coach will have the technical skills and experience of techniques such as pairing and TDD, and also the coaching skills to facilitate teams to learn these techniques.
• Another component of Samman is onboarding workshops:
  • Gain the trust of the team
  • Set expectations
• You have to have a good relationship with the team before you start working with them.
• The coach will not be working full time with the team.
• Coaching comes in chunks of 10 days spread over 3 weeks - typically in half days.
• 10 days is enough to move the needle.
• In the break between coaching sessions, the team can do business as usual (although it’s worth noting that the ensemble sessions will also involve working on their day-to-day work - this way, they can learn the techniques in a real-world scenario).
• There might also be a break of a few weeks for knowledge to sink in, before another 10-day coaching session (spread again over three weeks).
• You can do the coaching remote or on site.
• Remote coaching has some benefits and can work well.
• Feedback from participants: “We’ve talked about TDD for years, but these coaching sessions have given us a proper idea of what it actually entails.”
• Outcomes:
  • Improved teamwork, better collaboration
  • More likely to write unit tests
  • Committing code more often
  • More likely to refactor
• Part of the process is gaining the trust of managers and convincing them of the cost of tech debt and the value of techniques like TDD (Test Driven Development).
• “There must be five million makers working under the thumb of Scrum, and most of them simply do not have the skills you need to work effectively in Scrum.” - @RonJeffries
• “There is a huge unserved market out there… it seems either to have no money, or not to know that it needs help.” - @RonJeffries
• TDD makes coding more fun, and @EmilyBache has been on a mission for a long time to spread that joy to other programmers.
• There’s currently no obvious or clear career path to becoming a technical coach. @EmilyBache wants to change this! She has written a book, Technical Agile Coaching with the Samman Method (https://leanpub.com/techagilecoach), and has a website: https://sammancoaching.org/. She aims to offer training to coaches wishing to use the Samman coaching method.

3/9/21, Jim barritt - software architecture

• “all models are wrong but some are useful” - George box
  • Principles
  • Patterns
  • Practices
  • Guidelines
• wiki Many maps! See photo in phone. Jim highly recommends Simon Brown’s C4 system.
• wiki Gov.uk API technical and data standards - really useful
• For summary of top tips, see photo of final slide :
  • Make it a thing
  • Lightweight ADRs
  • Maps
  • Cross functional requirements (CFRs)
  • Organise teams around the things
  • API standards
• Enterprise integration patterns, by Gregor
• See phone for list of how to be an architect
  • Architecture is also a practice
  • Have empathy
  • Be an enabler for delivery teams
  • Be engaged in the rituals of delivery - close to the teams
  • Understand your business and its goals
  • Be a decision escalation point
• Should architects code? Yes. At the very least they should pair with devs. And QAs, and BAs, and PMs!
• For things like scalability, it’s crucial that you define what you mean in a measurable way. Create scalability tests to check progress / success.

Emily Bache talk - tweets:

I really enjoyed @EmilyBache’s talk about her Samman Technical Coaching technique (@CoachingSamman) yesterday at #AOTB21. Here are my notes.

Samman = Swedish, means “together”. An agile journey includes technical agile, and that’s the part that the Samman technical coaching method focuses on.

Emily did a survey in the talk (using @Mentimeter) about what makes coding fun. The top choices were

1. An end product that users care about, and
2. Code that is clear and easy to understand.

“Tech debt = deficiencies in internal quality that make it harder than it would ideally be to modify and extend” - @MartinFowler Research in 2019 suggested that companies waste 23% of their time due to technical debt.

Iterative and incremental development automatically creates tech debt. There will always be a gap between the design in prod and what you’ve realised (via user) you actually need. We can’t eradicate tech debt, but we can minimise it by creating code easy to extend and maintain.

“Satisfaction and wellbeing correlate with productivity” - Forsgren (@nicolefv) et al. What you want is developers who are skilled, take pride in what they do, and have a team culture of creating excellence. If you practice TDD, this will have a big impact on that goal.

The Samman technical coaching method consists of

1. Daily learning hour
2. Ensemble working.

The daily working hour is planned and articulated with learning goals, using the techniques from Sharon Bowman (@sbowperson) - Training from the Back of the Room (https://www.bowperson.com/sharons-books/).

Emily’s coaching website has suggestions for katas and other exercises you could use during a learning hour: https://sammancoaching.org/ The first step in the learning hour will be a short “connect” activity, to discover what people already know, and connect that with what they’re about to learn.

The learning hour should be a bit like a skiing lesson. You might already know how to get yourself from the top to the bottom of the slope on skis, but not how to slalom. A learning hour might involve people who can already code, but don’t yet know TDD.

Learning TDD in a learning hour is like learning how to ski on a smooth simple slope with no obstacles and no other skiers. TDDing in real life (rather than in the artificial environment of a learning hour) is much harder!

This is where the second part of the Samman method - ensemble work - comes in. Ensemble working is another (more positive) name for mob programming. This is described by Woody Zuill as “All the brilliant people working on the same thing, at the same time, on the same computer.”

Ensemble roles:

• Typist
• Navigator, getting / requesting help from team members
• Team members, providing input Rotate roles often - it’s a good idea to use a timer. But experienced teams may stop using timer once they’re confident in their ability to work together effectively.

The coach will teach the team the ensemble working technique and the basics of TDD, and once they get comfortable with it take more of a step back, just giving extra guidance when needed. Ensemble working is much more likely to be successful if you start out with a facilitator.

Emily has a training course about good ensemble working techniques.

A Samman coach will have the technical skills and experience of techniques such as pairing and TDD, and also the coaching skills to facilitate teams to learn these techniques. Part of the process is gaining manager trust - showing the cost of tech debt and the value of TDD.

Another component of Samman is onboarding workshops:

• Gain the trust of the team
• Set expectations You have to have a good relationship with the team before you start working with them.

The coach will not be working full time with the team. Coaching comes in chunks of 10 days spread over 3 weeks - typically in half days. 10 days is enough to move the needle. In the break between coaching sessions, the team can do business as usual…

(although it’s worth noting that the ensemble sessions will also involve working on their day-to-day work - this way, they can learn the techniques in a real-world scenario).

There might also be a break of a few weeks for knowledge to sink in, before another 10-day coaching session (spread again over three weeks). You can do the coaching remote or on site. Remote coaching has some benefits and can work well.

User feedback: “We’ve talked about TDD for years, but these coaching sessions have given us a proper idea of what it actually entails.” Outcomes:

• Improved teamwork, better collaboration
• More likely to write unit tests
• Committing code more often
• More likely to refactor

“There must be five million makers working under the thumb of Scrum, and most of them simply do not have the skills you need to work effectively in Scrum.” - @RonJeffries

“There is a huge unserved market out there… it seems either to have no money, or not to know that it needs help.” - @RonJeffries

TDD makes coding more fun, and @EmilyBache has been on a mission for a long time to spread that joy to other programmers. There’s currently no obvious career path for a technical coach. @EmilyBache wants to change this!

Emily aims to offer training to technical coaches wishing to use the Samman coaching method. See @EmilyBache’s book, Technical Agile Coaching with the Samman Method: https://leanpub.com/techagilecoach Also her website: https://sammancoaching.org/.