Troubleshooting Agile

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

The final episode of our mini-series on achieving alignment. We list five different objections we hear to the goals or process of alignment, and suggest ways to address them. We also tell a success story based on achieving alignment. SHOW LINKS: - Theory X and Theory Y: https://en.wikipedia.org/wiki/Theory_X_and_Theory_Y - Alistair Cockburn's mutiny koan: https://staging.cockburn.us/self-organization-means-mutiny/ *** 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

Episode 3 of our mini-series on achieving alignment. This week, we finally explain some methods for aligning with your team, your boss, or your peers. Methods include Test-Driven Development for People (aka the Ladder of Inference) and a creative use of the two-column case study. Next time - questions from listeners and common concerns we hear when moving to alignment. SHOW LINKS: - Chris Argyris on alignment and skilled incompetence: https://hbr.org/1986/09/skilled-incompetence - Video on Test-Driven Development for People: http://douglassquirrel.com/how-i-work.html - Guide to the two-column case study technique: https://blog.jeffreyfredrick.com/2015/04/11/using-the-two-column-case-study/ *** 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

Our next instalment on alignment as a tool for agile success. If alignment is as valuable as we claimed in the previous episode, why doesn't every organisation have it? We use ideas from Dr. David Burns to classify resistance to alignment into "outcome" and "process" resistance, then give examples of each and tell a story about a startup where the founders are (according to them) totally aligned, but no one else is. Next time: steps to achieve alignment despite resistance. SHOW LINKS: - Dr. David Burns, Feeling Good: https://feelinggood.com/ - Theory X and Theory Y: https://en.wikipedia.org/wiki/Theory_X_and_Theory_Y - Thinking Fast and Slow: https://en.wikipedia.org/wiki/Thinking,_Fast_and_Slow *** 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

Today, the first instalment of a little series on a big problem affecting agile teams: alignment. What does it mean when your team or company isn't aligned? How does misalignment show itself and what effects does it have on your progress? Jeffrey and Squirrel describe four different alignment patterns and tell real-life stories about the woes of misaligned teams. Future episodes in the series will cover resistance to alignment and how to get everyone headed in a common direction. SHOW LINKS: - Eight Behaviours for Smarter Teams: https://www.csu.edu.au/__data/assets/pdf_file/0008/917018/Eight-Behaviors-for-Smarter-Teams-2.pdf - “Prevent Your Strategy Offsite from Being Meaningless”: https://hbr.org/2014/09/prevent-your-strategy-offsite-from-being-meaningless - Five Dysfunctions of a Team: https://www.amazon.co.uk/Five-Dysfunctions-Team-Leadership-Lencioni/dp/0787960756/ *** 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

How do you provide focus and drive for a team using kanban? There's no natural "sprint" unit to hang a goal on, it seems. Jeffrey and Squirrel answer this listener question and explain how to create a product narrative, avoid the feature factory, and start with "Why"? SHOW LINKS: - Kanban book: https://www.amazon.com/Kanban-Successful-Evolutionary-Technology-Business/dp/0984521402 - When Kanban Fails: https://kanbantool.com/kanban-library/kanban-results/when-kanban-fails - Feature Factory: https://hackernoon.com/12-signs-youre-working-in-a-feature-factory-44a5b938d6a2 - Start with "Why": https://www.youtube.com/watch?v=u4ZoJKF_VuA and https://fortressofs.files.wordpress.com/2016/10/diagram_1.png *** We'd love to hear any thoughts, ideas or feedback you have regarding 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

This week, Jeffrey and Squirrel address a common frustration: "With all these retrospectives and planning games, when do we actually get some work done?" They cover single and double loop learning, the mundanity of excellence, and how to avoid learning in two distinct ways. SHOW LINKS: - J-curve / Satir Change Model: https://stevenmsmith.com/ar-satir-change-model/ - Mundanity of Excellence: https://www.jstor.org/stable/202063 - Tic-tac change: https://blog.jeffreyfredrick.com/2008/07/07/tic-tac-change-slides/ - Amy Edmondson, Teaming: https://www.amazon.co.uk/Teaming-Organizations-Innovate-Compete-Knowledge/dp/078797093X - Single- and double-loop learning: http://infed.org/mobi/chris-argyris-theories-of-action-double-loop-learning-and-organizational-learning/#_Single-loop_and_double-loop *** We'd love to hear any thoughts, ideas or feedback you have regarding 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

This week, Jeffrey and Squirrel answer a question from CruiseControl founder Paul Julius about what agile practises they've left behind. Surprising answers include iterations, predictability, and planning. SHOW LINKS: - PJ: http://www.pauljulius.com/ - Abnormally terminating a sprint - https://www.mountaingoatsoftware.com/blog/making-the-decision-to-abnormally-terminate-a-sprint - Kanban: https://en.wikipedia.org/wiki/Kanban_(development) - Elephant Carpaccio: http://alistair.cockburn.us/Elephant+carpaccio - Searching for an Agile Core: https://blog.jeffreyfredrick.com/2008/11/08/searching-for-an-agile-core/ - Planning Game: https://en.wikipedia.org/wiki/Extreme_programming_practices#Planning_game - TDD: https://www.amazon.co.uk/Test-Driven-Development-Addison-Wesley-Signature/dp/0321146530 - Cruise Control: http://cruisecontrol.sourceforge.net/ - GitFlow: https://datasift.github.io/gitflow/IntroducingGitFlow.html - Chris Matts: https://theitriskmanager.wordpress.com/ *** We'd love to hear any thoughts, ideas or feedback you have regarding 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

This week, Jeffrey and Squirrel help a listener with the role of design and architecture in an agile team. The answer involves arcane-sounding but fun concepts like elephant carpaccio, evolutionary design, and YAGNI. SHOW LINKS: - YAGNI: https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it - Elephant Carpaccio: http://alistair.cockburn.us/elephant+carpaccio - Evolutionary Design: https://martinfowler.com/tags/evolutionary%20design.html - XP Explained: https://www.barnesandnoble.com/w/extreme-programming-explained-kent-beck/1119347147 - GOOS book: http://www.growing-object-oriented-software.com/ - Sprint zero: https://www.frontrowagile.com/blog/posts/125-sprint-zero-for-product-owners - Trim the tail and order by risk: http://alistair.cockburn.us/Design+as+Knowledge+Acquisition - Up-front design in a previous episode: https://soundcloud.com/troubleshootingagile/enhancing-agility-through-technical-excellence-and-good-design *** We'd love to hear any thoughts, ideas or feedback you have regarding 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: itunes.apple.com/gb/podcast/troub…d1327456890?mt=2

This week, Jeffrey and Squirrel look at how to learn new skills in your agile team or elsewhere, and recommend frequent failure as a useful heuristic. SHOW LINKS: - Graham Lee blog post: https://www.sicpers.info/2018/02/to-become-a-beginner-first-become-an-expert/ - No True Scotsman fallacy: https://en.wikipedia.org/wiki/No_true_Scotsman - TDD (Test-Driven Development): https://en.wikipedia.org/wiki/Test-driven_development - Agile principles: http://agilemanifesto.org/principles.html *** We'd love to hear any thoughts, ideas or feedback you have regarding 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: itunes.apple.com/gb/podcast/troub…d1327456890?mt=2

This week, Jeffrey and Squirrel describe some of the methods they used to improve their own skills in implementing and troubleshooting agile methods. They describe techniques from rubber ducking to doppelgängers. Enjoy! SHOW LINKS: - CITCON: http://citconf.com - Breakfast with Squirrel: http://douglassquirrel.com - Communities of Needs and Solutions: https://theitriskmanager.wordpress.com/2015/04/19/communities-of-need-community-of-solutions/ - Dr. David Burns: https://feelinggood.com/ - Paradoxical Double Standard: https://feelinggood.com/tag/paradoxical-double-standard/ - Rubber Duck Debugging: https://en.wikipedia.org/wiki/Rubber_duck_debugging Alberto Savoia, older wiser self: http://www.albertosavoia.com/ *** We'd love to hear any thoughts, ideas or feedback you have regarding the show. Email us: see link on http://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: itunes.apple.com/gb/podcast/troub…d1327456890?mt=2

This week, Jeffrey and Squirrel discuss how to avoid blame - adopting a frame of ownership or problem-solving is a useful concrete action to try to achieve this - and tell a story about replacing one problem with a much bigger one to achieve team improvement. SHOW LINKS: - The 12 Agile Principles: http://agilemanifesto.org/principles.html - Alex Hudson blog post on blame: https://www.alexhudson.com/2018/01/03/troubleshooting-agile-new-podcast-notes-ownership/ - Mark Coleman: https://www.implicit-explicit.com/ - The Power of Habit: https://en.wikipedia.org/wiki/The_Power_of_Habit - https://blog.jeffreyfredrick.com/2016/04/08/coherence-busting-explained/ *** We'd love to hear any thoughts, ideas or feedback you have regarding the show. Email us: [email protected] 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: itunes.apple.com/gb/podcast/troub…d1327456890?mt=2

This week, Jeffrey and Squirrel each tell a story about how teams they've worked with handled deadlines. SHOW LINKS: - The 12 Agile Principles: http://agilemanifesto.org/principles.html - Theory X and Theory Y: https://en.wikipedia.org/wiki/Theory_X_and_Theory_Y - Burndown charts: https://en.wikipedia.org/wiki/Burn_down_chart *** We'd love to hear any thoughts, ideas or feedback you have regarding the show. Email us: [email protected] 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: itunes.apple.com/gb/podcast/troub…d1327456890?mt=2

This week, Jeffrey and Squirrel are on the road at CITCON Vienna, interviewing Lydia Tripp about her journey through a wide variety of agile software development teams and her evolving approach to improving delivery and quality. SHOW LINKS: -The 12 Agile Principles: http://agilemanifesto.org/principles.html -CITCON: http://citconf.com/ -Extreme Programming: https://en.wikipedia.org/wiki/Extreme_programming -Lydia: https://www.linkedin.com/in/lydia-tripp-988a79/ *** We'd love to hear any thoughts, ideas or feedback you have regarding the show. Email us: [email protected] 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: itunes.apple.com/gb/podcast/troub…d1327456890?mt=2

This week, Jeffrey and Squirrel are on the road at CITCON Vienna, interviewing participants about how they use agile techniques and principles outside development. SHOW LINKS: -The 12 Agile Principles: http://agilemanifesto.org/principles.html -CITCON: http://citconf.com/ -London Organisational Learning Meetup: https://www.meetup.com/en-AU/London-Action-Science-Meetup/ *** We'd love to hear any thoughts, ideas or feedback you have regarding the show. Email us: [email protected] 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: itunes.apple.com/gb/podcast/troub…d1327456890?mt=2

In this week's podcast we move on to the final Agile Principle, number 12: "At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly." The hard truth is that learning is horrible. It means coming face to face with your own inadequacies, and challenging them. Consequently, mustering up the motivation to learn is too easily and too often avoided. Squirrel and Jeffrey discuss their own experiences with the importance of reflection and some troubleshooting techniques to make learning easier. They also discuss: -How we all need to keep sharpening the saw, because if we're constantly producing we're not learning. -Using Production Vs Production Capacity, from 7 Habits of Highly Influential People, to remind ourselves of this. -How Marginal Gains, just 1%-per-day, compound to make a huge difference over time. -How, unexpectedly, it is often something as simple as poor relationships that are blocking the natural learning a company would like to have. It's much easier to blame the circumstances than have difficult conversations, and this blocks development. Therefore, we have a challenge for our listeners: Look at your current circumstances, at what you think the problems are, reflect, and then ask yourself: what's currently preventing you from taking action on those problems (and that means YOU. You individually. Saying your boss is an idiot is not an answer). There are always opportunities available to you, should you choose to take them. If you agree or disagree with us, let us know, via email, Twitter or in a review below. We'd love to take on some of your cases in upcoming episodes. *** SHOW LINKS: -The 12 Agile Principles: http://agilemanifesto.org/principles.html -James Clear on Marginal Gains: https://jamesclear.com/marginal-gains -The 7 Habits Of Highly Effective People, by Stephen R Covey: https://www.stephencovey.com/7habits/7habits-habit7.php -London Organisational Learning Meetup: https://www.meetup.com/en-AU/London-Action-Science-Meetup/ *** We'd love to hear any thoughts, ideas or feedback you have regarding the show. Email us: [email protected] 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: itunes.apple.com/gb/podcast/troub…d1327456890?mt=2

This week we take a short break from the Agile Principles to discuss The Squirrel Test - 12 questions to help founders improve their scale-up company's performance. We also find out if Squirrel, in creating the test, has practiced what he's preached regarding the agile principles. Has he produced working software? Sought early feedback? Kept it simple? Made the most of face-to-face communication? Retained a constant pace? Created a supportive environment for his team? Find out in this week's podcast. We'd like to apologise for the sound quality this week. With Jeffrey on the road we had some mic difficulties that we were unable to fix. We thought about not posting an episode at all, but didn't want to disappoint regular listeners by missing a week. So, again, our apologies for the quality. Next week we will be back to a silky smooth sound. *** LINKS: -The Squirrel Test: http://squirreltest.com -The Joel Test: https://www.joelonsoftware.com/2000/08/09/the-joel-test-12-steps-to-better-code/ *** We'd love to hear any thoughts, ideas or feedback you have regarding the show. Email us: [email protected] 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: itunes.apple.com/gb/podcast/troub…d1327456890?mt=2

In this week's Podcast we're on to the penultimate Agile Principle, number 11: 'The best architectures, requirements, and designs emerge from self-organizing teams.' Amongst much more, we discuss: -How what should actually constitute a team is the sharing of a problem, not a manager. -The importance of employing a dynamic team approach, rather than a static one, to solving problems. -How the unique specificity of this principle is designed to get us away from the old 'phase' approach and avoid costly hand-offs. -Specific techniques to inspire a mutiny and become a self-organizing team, with some lessons from Stephen Bungay's 'The Art of Action', such as how to employ Direct Opportunism. -The Spotify model and the importance of shunning the easy route of adopting an off-the-shelf model. *** SHOWNOTES: -The 12 Agile Principles: http://agilemanifesto.org/principles.html -Alistair Cockburn's mighty fine Koan for Agile development: "Management tells the workers to mutiny. The workers refuse" http://alistair.cockburn.us/Self-organization+means+mutiny -Stephen Bungay's brilliant book, 'The Art of Action': https://www.amazon.co.uk/Art-Action-Leaders-between-Actions/dp/1857885597/ -The unique case of the General Electric plant in Durham, North Carolina: http://www.fastcompany.com/magazine/28/ge.html -Spotify's self-organised teams, not an off-the-shelf model to copy: https://labs.spotify.com/2014/03/27/spotify-engineering-culture-part-1/ -Sign up to CITCON in Vienna, there aren't many spaces left: http://citconf.com/ *** We'd love to hear any thoughts, ideas or feedback you have regarding the show. Email us: [email protected] 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: itunes.apple.com/gb/podcast/troub…d1327456890?mt=2

We're on to Agile Principle 10 this week: "Simplicity - the art of maximizing the amount of work not done - is essential." In comparison to the dark old days when the Agile Manifesto was written, the way projects are simplified and broken down seems a huge improvement. But simplicity plays an essential role in achieving the all-important first Agile Principle of "satisfying the customer through early and continuous delivery of valuable software," so Squirrel and Jeffrey discuss why this principle is still so important today. They discussed: -How simplicity asks you to exercise discipline and restraint. -How Elephant carpaccio helps to provide an environment in which that restraint is easier. -How simplicity is not just a call for businesses to restrain themselves in their demand for features, but for developers to restrain themselves in their demand for best practices- and how they can employ YAGNI instead. -What YAGNI is. -How to build a whole application's worth of software without actually writing any software. *** SHOWNOTES: -The 12 Agile Principles: http://agilemanifesto.org/principles.html -Alistair Cockburn's brilliant Elephant Carpaccio lesson: http://alistair.cockburn.us/Elephant+carpaccio -What is YAGNI?: https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it -Zapier: https://zapier.com/ -IFTTT: https://ifttt.com/ *** We'd love to hear any thoughts, ideas or feedback you have regarding the show. Email us: [email protected] 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: itunes.apple.com/gb/podcast/troub…d1327456890?mt=2

This week on the Troubleshooting Agile podcast it's Agile Principle 9: "Continued attention to technical excellence and good design enhances agility." The dark old days of big up-front design may send shivers down the spine, but the Lean Startup 'move fast and break things' approach of scrapping design altogether goes too far. Jeffrey and Squirrel ask how principle #9 can be used to find balance between the two. They also discuss how a shared body of knowledge is the key to making quicker and better decisions in regards to technical excellence and good design; and ways in which managers can expand this body of knowledge through Lunch and Learns and making bad judgements well. *** SHOWNOTES: -The 12 Agile Principles: http://agilemanifesto.org/principles.html -The Boy Scout Rule, from Uncle Bob: http://programmer.97things.oreilly.com/wiki/index.php/The_Boy_Scout_Rule -Uncle Bob himself: https://en.wikipedia.org/wiki/Robert_C._Martin - Martin Fowler on Event Sourcing: https://martinfowler.com/eaaDev/EventSourcing.html *** We'd love to hear any thoughts, ideas or feedback you have regarding the show. Email us: [email protected] 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

In this week's episode of Troubleshooting Agile we are on to Agile Principle 8: "Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely." Drawing on sport psychology, Al Pacino movies and their years of consulting experience, Squirrel and Jeffrey discuss and troubleshoot a number of fascinating issues surrounding this principle: -How many people find this the easiest Agile Principle to argue with, and, in doing so, entirely miss the point. -Why the Hollywoodesque idea of "Crunch Time" and pulling-an-all-nighter may appeal to Theory X bosses and the delusional, but is detrimental to productivity and long-term effectiveness. -Why you need to ensure that exceptions to your sustainable pace really are the exception. -How, when it comes to psychology, recovery, nutrition, environment and support, Software Developers and Professional Athletes are not so dissimilar, if long-term effectiveness is what you're after. -How constant pace works as a counter-balance to the dangers of a team focussed purely on Customer Delivery. *** LINKS: -The Agile Principles: http://agilemanifesto.org/principles.html -Cost of Delay: https://en.wikipedia.org/wiki/Cost_of_delay - The Challenger Launch Decision: Risky Technology, Culture, and Deviance at NASA: https://www.amazon.co.uk/Challenger-Launch-Decision-Technology-Deviance/dp/0226851761 -Any Given Sunday, with Al Pacino and the "Inch by Inch" speech: https://en.wikipedia.org/wiki/Any_Given_Sunday *** We'd love to hear any thoughts, ideas or feedback you have regarding the episode. You can email us, here: [email protected] Tweet us, here: twitter.com/TShootingAgile Or find our website, here: troubleshootingagile.com/ Also, here is a link to our iTunes: itunes.apple.com/gb/podcast/troub…d1327456890?mt=2 If you have a moment, please like, subscribe and share with your friends. We really appreciate it.

It's Episode 9 of the Troubleshooting Agile podcast! This week we're discussing Agile Principle 7: "Working software is the primary measure of progress." Some of the topics we cover are: -The importance of "moving past the 'phase model' or the 'percent-of-budget model'" in measuring progress. -How Burn-Up/Down Charts simplify and optimise the process of measuring progress by assigning value only to that which provides value to the customer. -And how they also build trust between the business and software development sides of a company by delivering regularly. -The dangerous pitfall of taking Agile Principal 7 too literally and finding yourself toiling away in a Feature Factory. -How to avoid this pitfall by motivating your team with Type Y Management - perhaps taking inspiration from Star Trek's Jean-Luc Picard - and focussing on Business Outcomes. -That an unexpected outcome of focussing on 'working software' is often less software. 'But the software you end with, you know works. And you know it matters.' ** LINKS: -The 12 Agile Principles - http://agilemanifesto.org/principles.html -An extract from Alistair Cockburn's brilliant Crystal Clear: A Human-Powered Methodology for Small Teams on Earned-Value and Burn-Charts - http://alistair.cockburn.us/Earned-value+and+burn+charts -Mary and Tom Poppendieck's brilliant book on Lean Software Development - https://www.amazon.co.uk/Lean-Software-Development-Agile-Toolkit/dp/0321150783 -John Cutler's blog on how to tell if you're working in a Feature Factory - https://hackernoon.com/12-signs-youre-working-in-a-feature-factory-44a5b938d6a2 *** We'd love to hear any thoughts, ideas or feedback you have regarding the episode. You can email us, here: [email protected] Tweet us, here: twitter.com/TShootingAgile Or find our website, here: troubleshootingagile.com/ Also, here is a link to our iTunes: itunes.apple.com/gb/podcast/troub…d1327456890?mt=2 If you have a moment, please like, subscribe and share with your friends. We really appreciate it.

In Episode 8 of Troubleshooting Agile it's Agile Principle 6: "The most efficient and effective method of conveying information to and within a development team is face-to-face conversation." A few of the things we discuss: -The pros and cons of different communication channels. -Looking at Alistair Cockburn's book "Agile Software Development", why micro-gestures and physical interaction make face-to-face communication so much richer. -Why we need to remember that "a Story Card is a promise for a conversation". -The origins of CRC Cards back in the 90, and their real value as a conversational tool and in building a shared understanding. -How effective communication also increases the effectiveness of isolated reflective thought. -How to apply this principle effectively to distributed and remote teams. -"Don't measure your software productivity by linear feet of documentation on the shelf." *** LINKS: -Chapter 3 of Alistair Cockburn's Agile Software Development: http://alistair.cockburn.us/ASD+book+extract%3A+%22Communicating,+cooperating+teams%22/v/slim -Alistair's Richness of Communication graph: http://alistair.cockburn.us/get/2287 -Alistair on coining "A story card is a promise for a conversation": http://alistair.cockburn.us/Origin+of+user+story+is+a+promise+for+a+conversation -CRC Cards: http://www.extremeprogramming.org/rules/crccards.html -Jeff Bezos's Management Tool for Self-Discipline: http://blog.idonethis.com/jeff-bezos-self-discipline-writing/ *** We'd love to hear any thoughts, ideas or feedback you have regarding the episode. You can email us, here: [email protected] Tweet us, here: twitter.com/TShootingAgile Or find our website, here: troubleshootingagile.com/ Also, here is a link to our iTunes: itunes.apple.com/gb/podcast/troub…d1327456890?mt=2 If you have a moment, please like, subscribe and share with your friends. We really appreciate it.

This week, in Episode 7 of Troubleshooting Agile, we discuss Agile Principle Number 5: "Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done." Talking points this week include: -Why perceptions of this principle differ immensely depending on whether your adopt Theory X or Theory Y. -Directed Opportunism - and who used it better, General Clausewitz in 1870 or Darth Sidious a long, long time ago. -How trusting your team and recognising the ingenuity inherent within all employees creates psychological safety that motivates your staff and advances your business. -Different ways to deal with an unyielding Theory X-er. -How to recognise when it's come down to a case of "change your organisation or change your organisation." And finally, can you can think of a good Theory Y boss/environment depicted in TV or Film? (think corporate Mr Miyagi) Let us know down below, or Tweet us @TShootingAgile and we'll give your ideas a shout out in an upcoming episode. *** LINKS: -The 12 Agile Principles: http://agilemanifesto.org/principles.html -Stephen Bungay's 'The Art of Action': https://www.amazon.co.uk/dp/B01HPVHLHG/ref=dp-kindle-redirect?_encoding=UTF8&btkr=1 -The LEAP Institute: http://dramador.com/the-leap-institute/ -Niels Pfläging's blog, 'Why we cannot learn a damn thing from Semco, or Toyota': https://vision.haufe.de/blog/en/why-we-cannot-learn-a-damn-thing-from-semco-or-toyota/ *** We'd love to hear any thoughts, ideas or feedback you have regarding the episode. You can email us, here: [email protected] Tweet us, here: twitter.com/TShootingAgile Or find our website, here: troubleshootingagile.com/ Also, here is a link to our iTunes: itunes.apple.com/gb/podcast/troub…d1327456890?mt=2 If you have a moment, please like, share and subscribe. We really appreciate it.

In Episode 6 of Troubleshooting agile we talk about the Fourth Agile Principle: 'Business people and developers must work together daily throughout the project.' Some of the topics discussed are: -Why this is the only principle containing the word MUST. -How to easily overcome a principle which at first sight can appear impractical to implement. -What business people can do that developers can't. -The importance of customer proxies in bridging the communication gap between departments. -How this speeds everything up and helps developers maintain their flow. -As well as motivating teams, through trust and inclusion, in a way that can spark innovation. -Eating your own dogfood *** LINKS: -The 12 Agile Principles: agilemanifesto.org/principles.html *** We'd love to hear any thoughts, ideas or feedback you have regarding the episode. You can email us, here: [email protected] Or send us a tweet, here: twitter.com/TShootingAgile Or you can find our website, here: troubleshootingagile.com/ Also, here is a link to our iTunes: itunes.apple.com/gb/podcast/troub…d1327456890?mt=2 Please like, share and subscribe.

In episode 5 of Troubleshooting Agile we discuss the Third Agile Principle: 'Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.' Evolution in our thinking, since the Agile Manifesto was written back in 2001, makes what was once considered 'shorter timescales' seem laughable now, but, when retrospecting, 'working software frequently' remains one of the core agile disciplines. But, as Squirrel and Jeffrey highlight through various client stories, it is far from easy to implement continuously. We hear where, why and how so many companies fail to fully employ this principle, and Squirrel and Jeffrey discuss some interesting techniques to overcome common problems - from slicing up elephant carpaccio to employing continuous integration with nothing more than a rubber chicken. *We apologise for a few sound difficulties at the start of the episode with Jeffrey's mic. Stick with it and they soon pass.* *** Squirrel and Jeffrey have told us which common obstacles they regularly witness that prevent organisations from delivering working software frequently. Now we want to hear from you guys on the matter. You can leave your answers in the comments below, you can email us at [email protected], or you can find a poll on our Twitter feed @TShootingAgile. What are the obstacle for your organisation to delivering working software frequently? 1. The tech team aren't offering to do this, or don't know how. 2. Customers (external or internal or both) don't know it's possible or how to use it if offered. 3. Both 1. and 2. 4. Neither - we already deliver frequently! *** SHOWNOTES: -Agile Manifesto Principles - http://agilemanifesto.org/principles.html -Continuous Delivery, by Jez Humble and David Farley - https://martinfowler.com/books/continuousDelivery.html -Continuous Delivery - https://continuousdelivery.com -CITCON - https://citconf.com -James Shore's blog: "Continuous Integration on a Dollar a Day - http://www.jamesshore.com/Blog/Continuous-Integration-on-a-Dollar-a-Day.html -Alistair Cockburn's blog: "Elephant Carpaccio" - http://alistair.cockburn.us/Elephant+carpaccio *** We'd love to hear any thoughts, ideas or feedback you have regarding the episode (or regarding anything else for that matter). You can email us, here: [email protected] Or send us a tweet, here: twitter.com/TShootingAgile Or you can find our website, here: troubleshootingagile.com/ Also, here is a link to our iTunes: itunes.apple.com/gb/podcast/troub…d1327456890?mt=2 If you feel like liking, Sharing and/or Subscribing, we'd really appreciate it.

In this episode Squirrel and Jeffrey discuss the Second Agile Principle: ‘Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.’ We hear how the principle is closely related to Lean Startup and Minimal Viable Product, and how, at its core, it is about understanding and learning from one’s environment as quickly and as often as possible. This reminds Squirrel of the OODA loop, the decision cycle developed by military strategist and US Air Force Colonel John Boyd, and he tells us a story about fighter jet dogfights in the Korean War. Jeffrey also tells us a story, about a startup he started way way back in the first dotcom bubble in 1999, which brings to mind another military lesson that ‘no plan survives contact with the enemy.’. Finally, we hear examples of common errors witnessed over the years, such as refusals to fully embrace the Second Agile Principle in favour of misguided efficiency and an often irrational attachment a plan. *** SHOWNOTES: -The 12 Agile Principles: http://agilemanifesto.org/principles.html -The OODA Loop: https://en.wikipedia.org/wiki/OODA_loop -Lean Startup: https://en.wikipedia.org/wiki/Lean_startup *** We’d love to hear any thoughts, ideas or feedback you have regarding the episode (or regarding anything else, for that matter). You can email us, here: [email protected] Or send us a tweet, here: twitter.com/TShootingAgile Or you can find our website, here: http://troubleshootingagile.com/ Also, here is a link to our iTunes: https://itunes.apple.com/gb/podcast/troubleshooting-agile/id1327456890?mt=2 If you felt like liking, Sharing and/or Subscribing, we’d really appreciate it.

In this third episode of Troubleshooting Agile, Squirrel and Jeffrey take a look at the first of the 12 Agile Principles: "Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.” As Jeffrey point out, this principle contains so much that it "could have been an agile manifesto in itself.” Squirrel and Jeffrey both tell stories about previous consulting experiences to highlight where clients have failed to fully deliver on this vital principle in the past, and how businesses can troubleshoot various common problems that arise. Show Notes: - The 12 Agile principles: http://agilemanifesto.org/principles.html - “The Goal: A Process of Ongoing Improvement”, by Eliyahu M. Goldratt: https://www.amazon.co.uk/Goal-Process-Ongoing-Improvement/dp/0566086654/ref=sr_1_1 - CITCON website: http://citconf.com/ We’d love to hear any thoughts you have about this Agile Principle, or about the podcast in general. You can email us, here: [email protected] Or send us a tweet, here: https://twitter.com/TShootingAgile Also, why not Like, Share and Subscribe. We’d really appreciate it.

In episode 2 of Troubleshooting Agile, Squirrel and Jeffrey look at what to do when you've adopted good agile practices but are not seeing good business outcomes; how the most beautiful kanban board on earth doesn't necessarily mean results; and why the 12 agile principles work as a form of feedback and a great guide. Shownotes: - Jeffrey's 2008 blog post – https://blog.jeffreyfredrick.com/2008/11/08/searching-for-an-agile-core/ - The 12 agile principles – http://agilemanifesto.org/principles.html - Chris Matts's blog – https://theitriskmanager.wordpress.com/2015/04/19/communities-of-need-community-of-solutions/ Why not let us know what you think on Twitter @TShootingAgile https://twitter.com/TShootingAgile

In this week's podcast Jeffrey tells us a story about the dangers of blaming human error in the workplace, and we discuss root cause analysis, the blameless postmortem approach and how these are essential components in building productive systems and a great agile team. Normal Accidents – http://bit.ly/2CtawMg http://troubleshootingagile.com/