[2020 devnexus] mothering a dev team

Speaker: Valarie Regas @ValarieRegas

For more, see table of contents

Wardley Maps

  • For more: https://medium.com/@swardley
  • Map/graphic inspires more confidence than strengths/weaknesses/opportunities/threats matrix or list of steps
  • Customer is anchor point – your gol is your users
  • ex: Y axis is value chain visibility
  • ex: X axis is evolution. goes from genesis (ex: in house custom solutions) to commodity (stuff can outsource0
  • Links between nodes are dependencies


  • Must have only one anchor point
  • Everything shouldn’t link to everything else
  • Need midtier examples – something between “hello world” and enterprise software
  • Disney trip example! ex: fastpasses, pack, dining. (time bound events). Y axis dates and X axis is person doing
  • Chore chart leading to donuts. X axis is people again. Used pictures for four year old.
  • Work project with y axis as time needed to do. X axis is status (planning to completed)
  • All show movement from beginning to end, shows components clearly and shows how to get from one to another

Other axis ides

  • Cost
  • Complexity
  • # people needed

Other notes

  • There is software as well. Can make whiteboard version or electronic one.
  • Can use for sprint planning.
  • Valarie creates the maps independenly

My take

I hadn’t heard of Wardley Maps. Interesting idea. I *love* the Disney example. I have planned a trip to Disney World. What a project. Also, loved the how to make PB&J sandwich reference. I enjoyed that when I was a kid. I like there was a lot of Q&A. (I noted this last year too)

[2020 dev nexus] agile software engineering

Speaker: Jeff Wilson @mjeffw

For more, see table of contents


  • “Scrum is like your mother-in-law, it points out ALL your faults” – Ken Schwaber
  • “Without requirements or design, programming is the art of adding bugs to an empty text file” – Louis Srygley
  • Cartoon – “A good architect leaves a footprint” cartoon – gave up giving them names and just name layers after the architect.
  • “Make it work; make it right; make it fast” – Kent Beck
  • “If you are releasing software into production once every six months, you aren’t very good at it. If you can release software into production every 11.6 seconds like Amazon, you are bloody good at it” – Dave Farley


  • In short term, those ignoring quality are faster. In long run, those focused on quality win
  • Common problems:
    • we can’t demo anything until all the layers are addressed.
      • product owner should understand enough that can demo through a test
      • hexagonal architecture/prots-and-adapters – interchangeable requirements, can unit test or demo parts. Note all parts and draw a hexagon around them. Each layer has its own port and understands format. Adapter changes data to standard format.
    • must have a database to test business rules
      • can use in memory database or mock objects
    • testers have a different interpretation of requirements than developers
      • problem that put testing at end of process
      • better to have the tests being the requirements.
      • cannot release code until all requirements met and no failing test cases
      • BDD – gets business, developer and QA to collaborate. Gherkin acceptance tests (given/when/then)
    • we don’t understand the user stories until 3-4 days into the sprint
    • tech debt is slowing us down
    • can’t get through coding and testing in the same sprint
      • happens if stories too big
      • happens if silos
      • “waterfalling” as sprint – spend first two days for design, and…
    • can only test thru gui or api
      • test should be at lowest possible level of code
      • test UI/API separate from rest of system
      • inverted pyramid for # of tests is an anti-pattern
    • Low level quality
      • Designing to interfaces, not implementation
      • SOLID Principle
      • Robert Martin’s “Agile Software Development” book
      • Eric Gamma’s “Design Patterns” book
      • Robert Martin’s “Clean Code” book
      • Focus on maintainability because changing code all the time – readable, extensible, clear design well-defined interfaces, ease of build/reuse, sufficient documentations
      • Create domain objects (ex: social security number) rather than just using Strings

My take

Hexagonal architecture was new to me. I want to read more about it after the session. It’s always surprising what the “new” thing I learn in this type of talk is. I’ve read all the recommended books, but good recommendations.

more techniques for making agile games remote friendly

Two years ago, I blogged on how make agile games friendly to remote/distributed teams, Last week, I went to a NYC Scrum User Group meeting and was inspired to repeat the exercise.

This time, I’m going through *how* you think about adapting games as well. The key is to identify the lessons the game is teaching and what makes it run.

Game 1: 60 steps in 60 seconds

Key lesson: the importance of self organized teams.

Description of in person game: The group is split into pairs. The “manager” of one pair gives the “worker” instructions – left/right/stop/go. They do this for a minute and count steps. It’s hard because there are lots of people walking around and the worker has no autonomy. Then the pairs repeat the exercise where the manager can give goals rather than literal steps.

My take: I’ve played this before. In fact, it was the first agile game we played when my team was new to Scrum and needed to see the importance of being self empowered.

Making it remote/distributed friendly: This one is hard. I used a similar idea with a puzzle. I made two puzzles and had people pair up to do them using the same technique as 60 steps in 60 seconds. In one, do exactly what is said. In the second one, provide more broad instructions. While I did this one in person, it is easier to adapt to remote teams. Just do online puzzles (like a children’s jigsaw) with screenshare. You’d want to use cell phones for the pairs to communicate and reserve the video conference/phone bridge for the instructions and discussion about how it went.

Game 2: The Name Game

Key lesson: People don’t multi task well.

Description of in person game: This site describe sit well (I didn’t actually play this game at the meetup because you had to choose two of four to play, but I have played a similar game).

Making it remote/distributed friendly: It’s the same game. There’s nothing inherently in person to this game. You can use screenshare for any charts you want to show

Game 3: Throw Throw Burrito

Key lesson: Working together provides better outcomes.

Description of in person game: This game was a variant of the party game throw throw burrito. The first round was the party game. Then we switched to invented rules with a more collaborative twist. The goal was to maximize the score. Finally, we brainstormed how to make it even more collaborative. (As an aside one of the people in my game noted that if your opponent misses when throwing the burrito at you, there is no need to throw it at them and hit. Just walk over and tap the person)

Making it remote/distributed friendly: This one I can’t make remote friendly. There’s no way to throw a stuffed burrito remotely. There’s going to be some like this. The key is to save this type of game up for team onsites. For example, my team threw ping pong balls at each other at on of our onsites. I mean we played catch until there was too much work in progress to sustain it.

Game 4: Deep Sea Adventure

Key lesson: Working together provides better outcomes.

Description of in person game: First we played the Deep Sea Adventure board game with regular rules. Then we played again with the goal of keeping all the players alive and maximizing the score.

Making it remote/distributed friendly: At first glance, this doesn’t seem remote friendly as it is a board game. But it definitely can. You can make an electronic version of the game board/pieces (on OneNote or an online whiteboard) and use a random number generator online to replace the dice. The players would interact with the OneNote or online whiteboard as they play.

Game 5: Space <something>

I didn’t play this one. It looked like it was about collaboratively building a spaceship by trading cards. I didn’t see enough of it to have an opinion on making it remote friendly.