I. Introduction
Agile & Beyond is an annual conference (at least 9 years running) about the application of ‘Agile’ principles to software development… and management thereof. (And, yes, the implied reference to Buzz Lightyear’s “To Infinity, and Beyond” is not accidental.)
I’ve attended a couple of these in the past, but this year I was a guest speaker, talking about Unit-Testing: carrots & sticks — i.e., how to motivate and enable software developers to write more and better unit-tests. A subject that has been near and dear to my heart since my personal ‘light-builb’ about unit-tests lit up in 2006.
Now, A&B is a mixed experience, like many conferences: some of the talks are great, some are “fluffy”, and some just never got off the ground. But I wanted to describe my experience here for two reasons: to tell others, and to write down all the good stuff that I remember, before it disappears! Because there were definitely some ‘keepers’ that I intend to remember and use.
The rest of this post describes the talks that I went to. But there were literally 152 talks spread over 2 full days! So this is just one small self-selected sample. (Most talks were 45 minutes; somewhere around 1/6th of them were 1 hour and 40 minutes.) Most of what I’ve written below is my paraphrasing of what I heard, so it certainly doesn’t do justice to the speakers! If something sounds interesting, follow the links!
The conference was held in Cobo Center in downtown Detroit, which is freaking huge! I wanted to bring my drones and play…
II. Thursday, 5/30
- Jeff Patton, plenary speaker, 600-800 attendance. “Continuous Delivery” and just how damn fast our businesses (must) move, and how many old ideas we have to throw out. Best example: TripAdvisor.com CEO in 2011, explaining why they added a link “Plan your next ski vacation” to their home page — that went nowhere. For a day. They measured how many people clicked on it, and used that to decide if they should build that feature (or not). He wasn’t worried about the users who clicked on it and got a 404 — “they’d just blame their ISP, not us”.
- Chris (?), old friend from Gale days, personal conversation about being an Agile coach. Concept of “negative social capital”. Trying to be an Agile coach in a company where they’ve “heard all this before, and it never went anywhere”, had to work hard just to get up to “zero”! Asking innocent questions (“curious about your 1 month cycles”) and getting hugely defensive responses, indicating there’s already mixed messages, unresolved conflict that’s been stewing.
- Chris Williams, Bad Ass Agile. “Changing hearts and minds”. Chris talks like a really good radio personality, and he’s got some great podcasts that I’ll be listening to. He talked a lot about fear as the “source of all resistance”: how fear of changing things evokes the “look out for the tiger!” reactions of our ancient ancestors.
- Defensive physical reactions. Book “On Combat”
- Inoculate against fear — take small steps incrementally.
- “Drowning fear”. Who do you serve? (Would you walk across a 2×4 between two 13 story buildings? If one of them was on fire and your child was trapped?)
- “Bringing your one thing” to the table. What is it that you always have done, always will do, that brings something good to the table? That’s who you are, that’s what you do. Model to others that that thing can be done, that you are serving the group with that thing. (Funny story from attendee: good listener. No jobs labelled “listener”, but how badly modelling being a good listener is needed in our organizations!)
- MAKE IT THEIR IDEA. Elicit others’ thinking about how to solve problems, what to change. Much less resistance than if you TELL THEM WHAT TO DO.
- “Why service matters more”. Who do I want to serve? Who do others want to serve? Figure that out, to know how to reach them, talk to them, with less resistance.
- Ask & identify, which words will move them? Towards something, rather than away from something. Distinguish extrinsic motivators vs intrinsic motivators. (E.g. for me I imagine more success giving people tools to better see where they need unit-test coverage, than to tell them. Many have their own feelings about “not enough” test coverage, better to help surface their feelings than to push mine.)
- Book “Words That Change Minds”.
- Charlie Sweet, Anti-Fragile Teams. What makes teams “fragile” (or the reverse)?
- Premature or over-standardization. Example of estimation cards with values 100, 200, etc.! Helps prevent assumptions that all teams use the same metrics
- Burn-down (or up) charts. If no value to the team, yet management uses them… setup for a bad fall.
- “Tech debt Friday” lists.
- Long-lived teams can be too long-lived. Do changes fundamentally disrupt the team? Then maybe the team should change more often.
- Some stressors/changers are good, e.g. high-end developers doing bug stories.
- Team temperature reading. Based on family-systems theory and counseling by Virginia Satir (!!), and coaching work by Jerry Weinberg and Esther Derby:
- appreciations for team members
- share new information
- puzzles: what am I puzzled by (not to be solved)
- complaints with recommendations: what’s my vexation, what’s my recommendation?
- hopes & wishes
- Psychological safety assessments:
- Is a mistake held against a person?
- Is it easy to discuss difficult issues?
- Are people rejected for being different?
- Is it safe to take a risk?
- Is it difficult to ask other members for help?
- Do we value & respect others’ contributions?
- Does conflict improve or reduce productivity?
- “Admirals don’t make suggestions”. Junior person has idea, don’t immediately tell them how to improve it. Reduces their motivation.
- If there’s no way to introduce volatility, it may not be anti-fragile.
- Godfrey Nolan, Agile AI Testing. Decent set of slides in the link. In brief, how can we use AI to do better UI/Selenium/”Regression”/end-to-end testing? That top layer of the testing triangle is too brittle, and often under-appreciated.
- Too many of the existing tools are just glorified recorders that play back a session.
- Test.ai probably best tool out there now. Actually uses AI with some training, e.g. scripting language says “go look for something that looks like a search button and click on it”, rather than “identify the button by location or by CSS id”.
- Also something called Sapienz, mostly tied to Facebook, but worth watching. Changes its own testing code when tests fail.
- Louise Tamres, “Getting it Right the First Time”. Louise and I were colleagues for a while, but (unfortunately) I am in a different group, because her her tough-as-nails approach to what it means to do testing is sorely needed. Some reminders from her talk:
- You have MANY stakeholders. Customer and users are different! Let alone any relevant regulatory agencies!
- The “V” diagram: the activities at each layer can (should!) happen simultaneously! E.g. you can start writing acceptance tests during requirements gathering… and they will effect each other, in a good way!
- requirements gathering <—> acceptance testing
- systems analysis <—> system testing
- software design <—> integration testing
- module design <—> unit-testing
- Test cases often include the “do it zero times” case, and the “do it once” case, but often not the “do it twice” case. E.g. make airline reservation, upgrade to 1st class, then upgrade to 1st class again. What happens?
- Design artifacts. Just english descriptions can be terrible! “Mary had a little lamb” emphasis on each word in turn. (Did Mary give birth to a little lamb?). Diagrams, wire-frames of course, sticky notes on paper or wall. Models to clarify behavior: use cases, decision tables, state machines!
- What helps make successful products?
- Pre-grooming. Take (just!) the people who always talk anyway at grooming meetings, and use them to pre-groom.
- Estimation and refinement are different!
- Good design (re Uncle Bob) means delaying decisions as long as possible… but no longer. Document what’s being delayed.
- Perpetual 3-year-old (“but why? but why?”) make best testers.
- Michael Nir, “Persuading the bear: horizontal influencing”. This was a truly bizarre workshop. There were several good ideas, but IMHO much of the subtext of his presentation style contradicted his own messages. (E.g. he emphasized the importance of helping people feel listened to… yet he was a terrible listener. He would state things as absolutes, e.g. 7.5 below, that any engineer knows has a mix of pros and cons. Triggered? Who, me?) The good ideas include (my paraphrasing, as usual):
- Things happen in dyads and triads. When you’re in a meeting, have a “wingman”, someone who already knows what you’re going to say, and is prepared to support it.
- Watch the body language — theirs and yours. Do they move closer? Do they move away? What does that say? It may mean more than their words. Big people may need to make themselves look smaller (less threatening), small people may need to look bigger (more important).
- Make proposals in ranges. E.g. I’m asking for a raise, I’d like $5K to… and then add a lower number or a higher number depending on the immediate body language of your boss. (If they look relieved, go higher, if they look troubled, go lower.)
- Use positive words. E.g. avoid “try”, “should”, “don’t”. E.g. to a kid “stay in the yard” is different from “don’t cross the street”.
- When you have trouble with a person, look inside yourself first. For your assumptions about what they are doing, and your triggers (previous bad experiences that ‘look like’ what is happening in the present).
III. Friday 5/31
- Geepaw Hill, plenary. (Yes, that’s really his name, and he has the look, suspenders and all.)
- Virginia Satir curve: change lowers productivity for a while. If the change is good and people adapt and use it, productivity improves beyond the original level.
- When making (esp code) changes, use ENOF: easiest nearest owwie first.
- Change something every week.
- make carrots/sticks intrinsic, not extrinsic.
- “braid I-better into T-better”. Find the things you want to improve in your own practice, try to weave into the team — find where others’ I-better’s are similar enough to yours to weave some together
- Assume permission! (implied, as long as change is reversible)
- EXPERIENCE BETTER THAN ARGUMENT. E.g. helping someone have the TDD-lightbulb experience far more useful than haranguing them about it. Takeaway: how can we help CREATE those experiences?
- Dave Nicolette, Code Health Metrics (worth reading through). Which metrics really help? Which are misleading or useless? Which ones (or how they are used) diminish psychological safety?
- Take a step away from coding and look at production: measure things like “mean time to repair (bugs)”, how fast problems are reported, and then understood. See honeycomb.io.
- Static code analysis. E.g. SonarQube. But takes work to decide on which rules you really want to use. Takeaway: would be interesting to use this on just the changed class/methods in a story branch. FindBugs does some of this, but SonarQube does a lot more. Which measurements/rules actually help us improve? E.g. lines/method, lines/class… ?
- Unit-testing: carrots and sticks. Oh, wait, that was me! I learned a lot by taking a video of the 1st half, though. Recording here for improvement and humility. 🙂
- Putting business cards (w links to my blog) on each chair, good idea.
- Take video of whole talk: feasible, but needs better stand further back. Really useful for improvement. Someday might be good enough to publish (not yet!)
- I worked from my long blog post, but skipped around because I knew it was too long. Prepare chunks of it as slides — I spent too much time transitioning between them.
- Engage the audience earlier. The breakdown into organizational, social, and technical domains was good, and doing my most successful example (The Martinizer) in all 3 domains was good… but then I should have stopped and asked which domain they wanted to hear about.
- I aimed to be intense, and not boring. Did I succeed? Find out from participants: too intense? OK?
- Sajid Mohammed, Refactor away the code smells. Good talk but boring to me. Only takeaway is that IntelliJ(?) has better automated suggestions for improving the code. Worth looking at.
- April Jefferson, “Undividing a Land on Immigrants”. A great idea (bring together voices from both side of US immigration argument, and train them in ways to listen to each other). The experiment failed for logistical reasons, but they talked about it anyway.
- Paul Boos, Using Mikado & Kanban to save your legacy software. Mikado is the Asian/European name for the game the US calls “pick up sticks”.
- Basic idea: you want to make a significant change to your app. (E.g. split a monolith into two parts, running on different servers). Diagram it as a growing tree: make the 1st change (e.g. extract some service or whatever), see what breaks. Add the necessary next changes as nodes on your tree. Revert. Now try making one of the ‘next’ changes. Apply the same pattern. Eventually you have a tree with ‘leaf’ nodes that you can actually change and commit to trunk. Rinse and repeat.