Bill Wake on Building Agile Developer Skills (Scaling Tech Podcast Ep7)

Sep 6, 2022 | Agile, Developers

On episode 7 of the Scaling Tech Podcast, hosts Arin and David speak with noted Extreme Programming consultant and thought leader Bill Wake. Bill discusses topics around the technical and process aspects of Agile, including Mob or Ensemble Programming, User Stories, Refactoring, the state of Test Driven Development, and the challenges he sees teams face as they adopt extreme programming methods. In addition, he shares with us how to improve your development skills and more about his Twitch channel and the regular coding sessions he broadcasts there.

Arin first met Bill nearly 20 years ago when he was an Extreme Programming consultant hired by his boss at the time. Bill taught Arin’s team about test driven development techniques, which made Bill one of the first people to expose Arin to the concepts of agile software development. Bill is still well known in the agile coaching community and has worked in that capacity for a number of companies, independently and through Industrial Logic. He’s the author of several books on Extreme Programming, Refactoring, and Design Patterns. You can learn more about him at this Extreme Programming website,, and by following him on Twitch where he regularly does live coding sessions.

Listen on Spotify
Listen on Apple Podcasts

Watch the video:
Show notes with links to jump ahead are below

Show Notes from Episode 7 – Bill Wake on Building Agile Developer Skills
Timestamp links will open that part of the show in YouTube in a new window

  • 00:00 Arin notes how interesting this conversation with Bill was, and how much he learned from it. David agrees and says that he’s always admired Bill’s work but did not have the chance to meet him until now. This is a very technical conversation that our engineering team members should really enjoy.
  • 03:46 Arin intros Bill Wake and talks about how they first met when Bill was a consultant teaching Arin’s team about test driven development and agile techniques twenty years ago. You can learn more about him at and through his many publications, some of which we’ve listed below.
  • 04:40 What is Extreme Programming? Bill thinks of it as having a people side and a technical process side, which helps teams to do more evolutionary software development. Agile as a term is more of an umbrella term which includes many processes under it, such as Scrum, TDD, Crystal, and others. XP has it’s own twist on some things that are different Scrum
  • 06:10 David talks about how much he loved Extreme Programming when he was a developer, but he faced a lot of friction when trying to teach it to others in Central America. He liked how “extreme” it was, but joked that he would have preferred a different name like “Extremely Good Practices” that wouldn’t have scared away some people. Bill notes how Mob Programming faces a similar problem today since the term Mob doesn’t have great connotations, so some people try to call it Ensemble Programming instead. But sometimes the most controversial names (like Scrummaster or Sprints) are the ones that get the attention and then stick around.
  • 08:52 Bill talks about how he got into XP while working at a financial institution that was waterfall driven. Bill was working on some early Web projects using the RUP (Rational Unified Process), and decided to work out their own lighter process that included things like 3 week iterations. As he researched what others were doing, he found Kent Beck and Ward Cunningham’s writings on XP and went to their first training class.
  • 10:20 What is the state of TDD today? Bill still meets people who aren’t familiar with it or are not using it properly. He frequently consults to companies like that, even though it’s more well known than in the past. It’s much more widely adopted but not universal. Bill has seen clients that really are not helped by TDD, in use cases like graphic heavy applications or statistical based applications where the answers are not predictable. You still need to find some way to have assurance your app works.
  • 12:50 David asks about most common misconceptions or myths with TDD. Bill points out the fear that tests will always be brittle, but this can be addressed by following patterns and best practices. Other groups run into problems when they are good at developing tests, but don’t also focus on refactoring and so the tests end up being harder than they have to be.
  • 14:15 David notes two impactful things about TDD. The TDD cycle must start with writing a test that fails. The quality of the code to make the test pass for the first time doesn’t have to be beautiful, just get it to pass. Then you can use the Refactoring step to make it beautiful, and David sees this as a powerful tool for concentration and focus. The other insight is understanding that the tests you write should only be the meaningful ones initially, you don’t have to cover all scenarios. You can come back to writing additional exception scenarios. This is not a mindset taught when we were all in college, concepts like Maintainability and Refactoring were simply not covered.
  • 17:35 Arin notes how much TDD can help when you are starting a giant problem. Going through the TDD cycle gives you something of a checklist, and helps you to tackle big problems one bite at a time.
  • 18:20 Bill encourages new developers to focus on the main path scenarios like David said. This is a challenge for people to simplify big problems. Another interesting thing is to consider the design choices you make when you choose which test to write next. Not a lot is written about this, but deciding what tests to work on next can help drive how your application architecture evolves. Bill gives an example of this with a parser that he wrote.
  • 20:40 Arin asks about Emergent Design and the balance necessary with Enterprise Architecture groups. Bill prefers an evolutionary design approach, though sometimes those decisions are already made by the time that a consultant like him is brought in. When you can, using a prototype phase can help evolve the design up front, but the reality is you have to be comfortable with changes in design over time.
  • 22:45 David talks about how he fell in love with Functional Programming because of TDD. He asks Bill if modern languages are adding more functional features, is TDD helping to push that transition? Bill sees this trend of more pipeline driven and functional programming, but it’s not necessarily tied to TDD even though they are mutually beneficial in many cases.
  • 25:55 Bill talks about how he got into doing Twitch streams. He started it during the pandemic as a way to practice what he’s preaching, by taking a programming idea and implementing it on-screen incrementally, without worrying about it being polished all the time. It shows the reality of what programming is like, as opposed to perfect video presentations that a pre-recorded tutorial often shows. He does minimal prep beforehand, sometimes a slide or two explaining the concept of what he wants to build next, but typically no more than that.
  • 29:35 Arin asks about how much Bill teaches on pair programming these days, and Bill notes that it’s not much. Ensemble or Mob programming are more popular topics these days than Pair Programming. Bill defines Ensemble Programming as the notion of getting the whole team programming together. People take turns as the typist, and sometimes another team member is the “voice of the team” who says what to work on next. The whole team contributes their point of view to code as it’s developed, and team members frequently rotate roles. This helps to share knowledge and get the team’s best effort as a whole, instead of just the sum of the best efforts that individual team members can do on their own.
  • 31:40 David talks about how hard it was to be the Driver when he was first pair programming. He had to count to three before telling the Typer that they are making a mistake – usually they will notice their mistake in that time but it’s hard to restrain yourself! Bill talks about how Mob programming is an easier ramp up than Pair Programming since you can pop in and out when needed, and it’s a more gentle approach to collaborative development.
  • 33:45 Arin talks about how it’s a challenge for growing tech teams who are using TDD. An initial rule like “every user story needs a UI test” works great, but over time becomes a very large and brittle set of tests that were written on a story-by-story basis. Bill talks about coaching teams through that challenge, and that UI tests have benefits but also costs. The UI is always going to change over time and so those tests will always break over time. He prefers to focus on more behavioral tests below the UI. Some tests can be used at the UI level to “taste the peanut butter”, where you just check around a few areas to see that everything is ok and functioning at a basic level. He discourages detailed UI testing, he’s happier at a level down.
  • 37:25 Arin talks with Bill about his writings on user stories, and in particular the INVEST acronym for how to write user stories. This has always been one of Arin’s favorite pieces from Bill. Bill talks about how he came up with that phrase, as a way to help judge if a user story makes sense. Arin jokes with Bill about how hard it is for him to say “Estimable”, and that he’s not sure it’s a real word. The concept of INVEST provides an interesting way to consider the tradeoffs when writing a story. Bill notes he now often replaces “Estimable” with “End to End” when explaining INVEST, because he also likes that alternate emphasis on making sure developers consider the full end-to-end value of a user story. Sometimes he also uses “Scalable” instead of “Small” to draw attention to the importance of having user stories of an appropriate size that can be implemented within the sprint, without creating 3000 user stories. If you make things too small, you do lose sight of the big picture of what you’re trying to accomplish.
  • 44:19 How do you recommend an engineering manager keep their skills up to date? Bill gets a lot of value from his Twitch sessions, in keeping his own skills fresh. He also reads a lot of books, and likes to read older programming books to see the mentalities used in the past and how that might have influenced the way we develop today. Some of those older abstractions come back around again in modern development.
  • 46:30 David asks about Bill’s favorite tools for collaboration, for things like remote pair programming. For Bill, they are often dictated by his clients. He frequently uses Zoom, Slack, but has dabbled with many tools.
  • 47:56 David asks what excites you in the programming world right now? Bill talks about enjoying learing Swift, and even though it’s not new, he’s really enjoying seeing teams work with Mob Programming in different size groups. He’s also using Kanban more and seeing the value of managing the flow of work. For a while he felt programming languages got a bit stuck, but now there’s so many new ones it’s hard to keep up with them all.
  • 50:00 Bill asks what David and Arin are interested in now technically. David talks about how interested he is in React right now, and how it’s helped him to enjoy front-end work more. He sees it now as more predictable and easy to work with, React brings some of those benefits of back end code to the front end. David also notes he has a guilty pleaure of learning Clojure. For Arin, he talks about his curiousity and skepticism of AI driven pair programming like GitHub’s CoPilot. Arin talks about his mixed views on the potential power of “advanced auto complete”, but also how we’ve seen that machine learning algorithms don’t automatically drive to the best solutions.
  • 53:29 We wrap up – if you want to follow more about Bill’s work then see our links below to his Twitter profile and Twitch streams, and go to his website at! Arin notes how much Bill influenced him early in his Agile journey, and thanks Bill again for how much he has influenced so many!

Links from Episode 7 – Bill Wake on Building Agile Developer Skills