Troubleshooting Agile

We answer a listener question about standups for feature teams, but we think the problem is actually a larger one of disengagement. A common symptom is people sitting down for their standup (oxymoron alert!) We recommend some ways to overcome disengagement using Coherence Busting and the Ladder of Inference, tools we've been discussing on recent podcasts. SHOW LINKS: - Feature teams: http://featur...

Last time we talked about sharing reasoning and building trust in your agile team using TDD for People, one way to use the Ladder of Inference. Today we look at how the Ladder can help you discover your own reasoning as well, to discover ways to promote mutual learning with your own behaviour. SHOW LINKS: - Top Business Podcasts for CEOs, from Fiona Anderson: https://www.rocktime.co.uk/insights/li...

As promised, we start describing our favourite trust-building technique: the Ladder of Inference. Our take this week is on using the Ladder to understand someone else's reasoning and align your stories, creating trust as a foundation for further improvement in your agile team. Surprisingly, the experience of using the Ladder in this way is similar to Test-Driven Development: careful, understandabl...

We start previewing the ideas in our forthcoming book on using conversations to improve your agile results. First up: why you need trust before you do anything else (including hold a standup, write unit tests, or move your desks together). Next week, a step-by-step technique to build trust. SHOW LINKS: - The first thing to build is trust, Brad Appleton: http://bradapp.blogspot.com/2005/02/first-th...

We cap our five-part series on undermining your agile team with the pinnacle of ineffective behaviour: the belief that you are not contributing to the problem. Inaccurate estimates, useless meetings, directionless standups - so long as you're sure all these are entirely someone else's fault, you'll be sure never to fix them, and thus leave your team high and dry. Master this technique and never wo...

Why listen to team members and peers when your feelings and behaviours are obviously justified? We continue our how-to series on undermining your agile team with two stories about people who, believing they are clearly correct about how to improve their agile teams, move to shut down communication and manipulate the environment to ensure their approaches are adopted - with, predictably, zero inter...

Another in our top tips for ensuring your agile team does not achieve its goals - assume you have pure motives and others are actively malicious. We describe several helpful biases that, if adopted, can help you take up this mindset, and describe a founder duo with negative beliefs about each other who had mastered the art of "Getting to No" - until they read Fisher/Ury and discovered they actuall...

More this week on ways to fail with agile by making unilateral assumptions - this week's tip is to believe you are right and everyone else is wrong. In fact, even the underlying assumption that there is a single right answer should get you a long way to fracturing your team and ensuring discord. Squirrel tells a story of someone particularly skilled at explaining why he knows the One True Agile Wa...

Turning our usual subject on its head, this week we start a short series on how to make sure your team does NOT improve. The first assumption to this end: the belief that you understand the situation while others don't. The change that's needed is obvious; all you have to do is convince others to adopt it. Easily adaptable to kanban, scrum, SAFe, or any other method that seems (to you!) to be the...

Squirrel and Jeffrey look at a recent article by Luke Tomas on the "employee engagement industry" (we didn't even know it *was* an industry!) Jeffrey rapidly links this to Brian Marick's idea of Ease and Joy at work and we all agree that engagement, happiness, and joy are all useful, but lagging, indicators of team success - so you can't improve them directly with bigger bonuses or tougher objecti...

A Squirrel-only show since Jeffrey's away. Squirrel described the Post-It Factory Game which illustrates both work-in-progress limits and the more general notion of "Throughput over Utilisation" - as well as making your colleagues fall over themselves trying to produce blue squares at top speed. SHOW LINKS: Kanban by David Anderson: https://www.amazon.co.uk/Kanban-Successful-Evolutionary-Technolog...

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-...

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, argu...

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" cul...

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: h...

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 Ch...

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 Ch...

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!...

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 learnin...

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...

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 prob...

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-organizat...

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...

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,...

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...