Troubleshooting Agile

Last (for now) in our series responding to Martin Fowler's State of Agile 2018 speech. This week we look at Fowler's third claim - that software projects should be replaced by software products - and go further, arguing that organising around user conversations is the key to a successful business outcome.

SHOW LINKS:

- Fowler on the State of Agile 2018: https://martinfowler.com/articles/agile-aus-2018.html

- Commandos, Infantry, Police: https://devblog.timgroup.com/2013/07/24/invading-the-product-landscape-a-metaphor/

- Wardley mapping: https://medium.com/wardleymaps/doctrine-8bb0015688e5

***

We'd love to hear any thoughts, ideas, or feedback you have about the show.

Email us: see link on troubleshootingagile.com

Tweet us: twitter.com/TShootingAgile

Also, if you'd like to leave us a review on iTunes (or just like and subscribe), you'll find us here: https://itunes.apple.com/gb/podcast/troubleshooting-agile/id1327456890?mt=2

We continue our series responding to Martin Fowler's State of Agile 2018 speech. This week we look at Fowler's second claim - that agile software development has forgotten that it's about software, and that technical excellence in practises like refactoring, testing, and architecting should be (but isn't) central to discussions of good agile practise. We agree with Fowler and go even further, arguing that we should be making the (strong) case for technical excellence as a source of business value - to make our products more flexible, easier to use, and more satisfying to users.

SHOW LINKS:

- Fowler on the State of Agile 2018: https://martinfowler.com/articles/agile-aus-2018.html

- Marick on forgotten agile ideas: http://www.exampler.com/discipline-and-skill.html and http://www.exampler.com/blog/2007/05/16/six-years-later-what-the-agile-manifesto-left-out/

- Reinertsen, The Principles of Product Development Flow (cost of delay): https://www.amazon.co.uk/Principles-Product-Development-Flow-Generation/dp/1935401009

- Accelerate book: https://itrevolution.com/book/accelerate/

- Our previous episode on technical excellence and the agile principles: https://soundcloud.com/troubleshootingagile/enhancing-agility-through-technical-excellence-and-good-design

***

We'd love to hear any thoughts, ideas, or feedback you have about the show.

Email us: see link on troubleshootingagile.com

Tweet us: twitter.com/TShootingAgile

Also, if you'd like to leave us a review on iTunes (or just like and subscribe), you'll find us here: https://itunes.apple.com/gb/podcast/troubleshooting-agile/id1327456890?mt=2

Martin Fowler gives us lots to chew on in the form of a speech on the state of agile software development in 2018. We start a series responding to Fowler by examining the Agile Industrial Complex - proponents of the "one true way" of agile development and out-of-the-box methodologies - and why Squirrel thinks the buyers and sellers of these "solutions" are doomed to failure by their "Theory X" cultures.

SHOW LINKS:

- Fowler on the State of Agile 2018: https://martinfowler.com/articles/agile-aus-2018.html

- Theory X and Theory Y: https://en.wikipedia.org/wiki/Theory_X_and_Theory_Y

- The Military-Industrial Complex: https://en.wikipedia.org/wiki/Military%E2%80%93industrial_complex

- Crossing the Chasm: https://en.wikipedia.org/wiki/Crossing_the_Chasm

- Cynefin Framework: https://en.wikipedia.org/wiki/Cynefin_framework

- Community of Solutions and Community of Needs: https://theitriskmanager.wordpress.com/2015/04/19/communities-of-need-community-of-solutions/

- CITCON: http://citconf.com/

A listener asks us how we reconcile the perceived conflict between learning and design - if you're iterating fast, how can you also build solid, scalable architecture? With examples from OO and Domain-Driven Design, we describe how early agile adopters addressed this issue (and how the meaning of "design" has evolved), and then make suggestions for modern teams.

SHOW LINKS:

- Elephant Carpaccio: https://dzone.com/articles/elephant-carpaccio-user

- OO design: https://en.wikipedia.org/wiki/Object-oriented_design

- DDD: https://en.wikipedia.org/wiki/Domain-driven_design

***

We'd love to hear any thoughts, ideas, or feedback you have about the show.

Email us: see link on troubleshootingagile.com

Tweet us: twitter.com/TShootingAgile

Also, if you'd like to leave us a review on iTunes (or just like and subscribe), you'll find us here: https://itunes.apple.com/gb/podcast/troubleshooting-agile/id1327456890?mt=2

Once you have a bunch of great ideas from your reflection, how can you make sure you and your team actually use what you've learnt? We illustrate several variations on one of our favourite learning-capture methods, the humble checklist - including self-improving lists and an idea that survived ten years by migrating among multiple checklist formats, from wiki page to slackbot.

SHOW LINKS:

- The Checklist Manifesto: https://en.wikipedia.org/wiki/The_Checklist_Manifesto

- Jeffrey's Glider Training Video: https://www.youtube.com/watch?v=s6QcOQ3olbE

- Elizabeth Hendrickson's Testing Cheat Sheet: http://testobsessed.com/2007/02/test-heuristics-cheat-sheet/

- Making Software Like Intensive Care or Bombing Missions: https://blog.jeffreyfredrick.com/2008/09/10/making-software-like-intensive-care-or-bombing-missions/

- Exploratory Testing: https://en.wikipedia.org/wiki/Exploratory_testing

- Human in the Loop: https://en.wikipedia.org/wiki/Human-in-the-loop

***

We'd love to hear any thoughts, ideas, or feedback you have about the show.

Email us: see link on troubleshootingagile.com

Tweet us: twitter.com/TShootingAgile

Also, if you'd like to leave us a review on iTunes (or just like and subscribe), you'll find us here: https://itunes.apple.com/gb/podcast/troubleshooting-agile/id1327456890?mt=2

We continue our mini-series on how to learn by considering ways to realise your learning - that is, how to convert what you've learnt (say, from a retrospective) into changed behaviour. We discuss how and why to create pre-planned actions in response to situations where you'd like to do better, for instance software outages or suspiciously optimistic delivery dates.

SHOW LINKS:

- Feynman on the Challenger disaster: https://science.ksc.nasa.gov/shuttle/missions/51-l/docs/rogers-commission/Appendix-F.txt

- Reg Revans, Action Learning: https://www.brookes.ac.uk/services/ocsld/resources/theories.html#action

- Helicopter pilot story: https://www.verticalmag.com/features/ejection-decision/

- Ejection Decision: https://www.youtube.com/watch?v=Aa1Ba_NEobs

***

We'd love to hear any thoughts, ideas, or feedback you have about the show.

Email us: see link on troubleshootingagile.com

Tweet us: twitter.com/TShootingAgile

Also, if you'd like to leave us a review on iTunes (or just like and subscribe), you'll find us here: https://itunes.apple.com/gb/podcast/troubleshooting-agile/id1327456890?mt=2

Second of two episodes on reflection. We often say that learning is horrible and suggest you do it anyway - but how exactly can you learn? We use a model from Chris Argyris - single-loop and double-loop learning - and concentrate today on the double-loop style, which you might want to try if you want to radically change your thinking and try something completely new (which might or might not work!)

SHOW LINKS:

- Argyris on single- and double-loop learning: https://hbr.org/1977/09/double-loop-learning-in-organizations

- Crossing the Chasm: https://en.wikipedia.org/wiki/Crossing_the_Chasm

- Innovator's Dilemma: https://en.wikipedia.org/wiki/The_Innovator%27s_Dilemma

- The Lean Startup: https://en.wikipedia.org/wiki/The_Lean_Startup

***

We'd love to hear any thoughts, ideas, or feedback you have about the show.

Email us: see link on troubleshootingagile.com

Tweet us: twitter.com/TShootingAgile

Also, if you'd like to leave us a review on iTunes (or just like and subscribe), you'll find us here: https://itunes.apple.com/gb/podcast/troubleshooting-agile/id1327456890?mt=2

First of two episodes on reflection. We often say that learning is horrible and suggest you do it anyway - but how exactly can you learn? We use a model from Chris Argyris - single-loop and double-loop learning - and concentrate today on the single-loop style, most appropriate for gradual improvement of a particular metric or characteristic.

SHOW LINKS:

- Argyris on single- and double-loop learning: https://hbr.org/1977/09/double-loop-learning-in-organizations

- Shu Ha Ri: https://martinfowler.com/bliki/ShuHaRi.html

***

We'd love to hear any thoughts, ideas, or feedback you have about the show.

Email us: see link on troubleshootingagile.com

Tweet us: twitter.com/TShootingAgile

Also, if you'd like to leave us a review on iTunes (or just like and subscribe), you'll find us here: https://itunes.apple.com/gb/podcast/troubleshooting-agile/id1327456890?mt=2

We have a look at Jason Palmer's "You Don't Need Standup" with a mutual learning, curious attitude. What can we learn from Jason? What information does he have that we don't? Where do we agree with him? We conclude that indeed some teams may be better off without standups - see Fred George's Programmer Anarchy for example - but before embarking on the experiment, it's worth asking "how will I know if it's working or not?"

SHOW LINKS:

- You Don't Need Standup: https://medium.com/@jsonpify/you-dont-need-standup-9a74782517c1 (By Jason Palmer, https://twitter.com/palmerj3 )

- Hacker News discussion of YDNS: https://news.ycombinator.com/item?id=17671464

- Fred George on Programmer Anarchy: https://www.slideshare.net/fredgeorge/programmer-anarchy-and-managerless-processes

- Cockburn on people in software development: http://web.archive.org/web/20170620211523/http://alistair.cockburn.us/Characterizing+people+as+non-linear%2c+first-order+components+in+software+development

***

We'd love to hear any thoughts, ideas, or feedback you have about the show.

Email us: see link on troubleshootingagile.com

Tweet us: twitter.com/TShootingAgile

Also, if you'd like to leave us a review on iTunes (or just like and subscribe), you'll find us here: https://itunes.apple.com/gb/podcast/troubleshooting-agile/id1327456890?mt=2

A few more thoughts on alignment, inspired by a list of "XP Mistakes" from the great J. B. Rainsberger. We look at some of the antipatterns and lessons learnt and, as usual, tell a few of our own stories about mistakes we've made and observed.

SHOW LINKS:

- XP, My Greatest Misses: https://blog.jbrains.ca/permalink/xp-my-greatest-misses

- CITCON: http://citconf.com/

- "Are you frustrated? It's probably your fault": https://vimeo.com/131854234

- Five Dysfunctions of a Team: https://en.wikipedia.org/wiki/The_Five_Dysfunctions_of_a_Team

- Eight Behaviours for Smarter Teams: https://www.csu.edu.au/__data/assets/pdf_file/0008/917018/Eight-Behaviors-for-Smarter-Teams-2.pdf

- The First Thing to Build is Trust: https://bradapp.blogspot.com/2005/02/first-thing-to-build-is-trust.html

- Cockburn article on people in software development: http://web.archive.org/web/20170620211523/http://alistair.cockburn.us/Characterizing+people+as+non-linear%2c+first-order+components+in+software+development

***

We'd love to hear any thoughts, ideas, or feedback you have about the show.

Email us: see link on troubleshootingagile.com

Tweet us: twitter.com/TShootingAgile

Also, if you'd like to leave us a review on iTunes (or just like and subscribe), you'll find us here: https://itunes.apple.com/gb/podcast/troubleshooting-agile/id1327456890?mt=2