All of this content used to be spread over three different blogs at three different domains and it's now been merged into one. Why was it ever three? Because at the time it seemed reasonable that each of them was for a different audiences, and yet over time I've found that the lines between topic areas got blurrier and tended to overlap. So now they're all together in one place.
If you encounter things that seem broken, please let me know and I'll get them fixed.
Browse by topic area:
- Psychology & Behaviour (Formerly UnconsciousAgile.com)
- Flow, Kanban, Scrum (Formerly ImprovingFlow.com)
- Technical Practices (Formerly AgileTechnicalExcellence.com)
There's a lot here and if you're not sure where to start, here are some popular starting points. From these, you'll find crosslinks to even more topics. Enjoy!
- Psychological Safety: An overview. For the science, see the SAFETY model. For Google's research into why it's important for high performing teams, see Project Aristotle. What happens when we don't have that safety?
- Anxiety and Stress: For the science, see Polyvagal Theory or a description of some neuroscience, illustrated with a bear encounter. To let go of that anxiety, see the Anti-Anxiety toolkit.
- Recommended reading: I'm often asked for book recommendations.
- Generally more about the brain: Cognitive bias, motivation, default mode network, systems 1 & 2 and neurotransmitters (chemicals) that drive behaviour.
- Language patterns: Why language is so important, and Clean Language, a specific language pattern that has excellent application for coaching.
- Improving your meetings: Specifically retrospectives (my video course), and standups. What if your people won't participate?
- Improving learning: with neuroscience and LEGO.
- Flow & Kanban: Flow metrics, probabilistic forecasting, and understanding waste.
- Technical practices: Continuous integration, TDD as design, and ensemble programming.
- Something fun: The millennial whoop, and inattentional blindness.
Jira API: Intro and authentication
I’m the primary author of the jirametrics tool that extracts data from Jira and generates reports. This tool evolved to satisfy my own pain of not being able to get useful data out of Jira with the built-in reports and along the way, I’ve learned more about Jira internals than I ever wanted to know.
Data Accuracy
We have a tendency to believe that anything we see in a chart is 100% accurate, although that’s often not true. To understand the accuracy of the chart, we have to understand a couple of things:
- How accurate the initial data was.
- How much of the original data set was used in the chart.
- How good the chart is at communicating the right message.
Autonomy
I’ve spoken to a number of people recently who have complained about a lack of autonomy at work. They talk about being micro-managed by their bosses. About being given solutions to implement, rather than problems to solve. About restrictions on what they can and cannot do in the environment.
Team working agreements with LEGO
Team working agreements (sometimes called team norms) are all about how we are going to work together as a group of people. To do this effectively, we need fairly deep and honest conversations, and yet we see many working agreement sessions stay fairly superficial. The approach in this article uses LEGO® Serious Play® for the core discussions to get those more meaningful conversations.
Quickstart for JiraMetrics
I’ve created a Quick Start guide for the jirametrics tool.
My people aren’t participating
I frequently hear “my people won’t speak up during standup” or “they aren’t participating in retro” or other activities. Unfortunately, there are many different reasons why this might be so it’s not a simple problem to fix. Step one is to figure out why this might be happening.
Stalled work
As I talked about in this earlier video on standups, the work on our board can loosely be grouped into three categories. It’s either active, blocked, or stalled. We tend to spend a lot of time talking about the active and blocked work and have a tendency to forget about the rest, which results in stalled work aging unnecessarily. That in turn will make the overall system less effective and less predictable.
Warning levels
Over my career, I’ve noticed that a significant number of programmers ignore compiler and linter warnings. They either turn the warning levels down or just ignore the output. I’ve worked with teams using SonarQube that would have tens of thousands of warnings that they wouldn’t even look at.
“This is a safe space”
I’m seeing more and more situations where someone will say “this is a safe space” in a meeting invite or at the beginning of a session. While I appreciate that the person saying the words really wants that to be true, the fact they feel the need to say it, highlights the fact that it probably isn’t. If it really were safe, we would already know that.
Slicing epics
We talk a lot about slicing stories but then when it comes to slicing larger types (epics, features, etc), we tend to wave our hands and say “it’s the same, only bigger”, which while true, is rarely helpful.