Agile

In a previous post I talked about the 'case of the missing users & customers in Scrum'. While there's a lot of focus (also thanks to DevOps) on 'shipping fast', we often forget that 'shipping fast' and 'building what the user needs' are two sides of the same coin. It's wonderful to ship fast. But without actively involving the user, it is nothing more than a technical exercise. How can we build good products if we never talk or see real-life users? In this post I offer 7 powerful ways to make this kind of interaction happen (directly and indirectly)…

Scrum is about shipping fast(er). But it is also about building what the customer needs. These are two sides of the same coin. Although the former is often at the forefront of attention (also thanks to DevOps), the latter is frequently forgotten. Think about it; how often do you have real customers or real users present during Sprint Reviews? How often do developers talk with real customers and users? Although I understand why, this is not helped by the the official Scrum Guide. It has exactly zero references to ‘customers’ or ‘users’, and abstracts them away behind the business…

If you're a Scrum Master, Change Agent, Agile Coach or otherwise interested in involving and tapping into the wisdom of everyone, Liberating Structures are a wonderful extension of your toolkit. In this post I explain why and offer some concrete examples. If you'd like to experience Liberating Structures first-hand, Johannes Schartau and I gladly invite you to join our workshop at Scrum Day Europe 2017. The way we communicate in groups is broken Ever been part of a status meeting where most people are checking their phones or staring into the distance? Ever been part of a brainstorm where only…

More often than not, Scrum seems like a Bad idea. At least, judging from the reasons that are often presented to me when I am asked to help a company get started with Scrum: "We want the team to take more ownership of what they're developing". "We want teams to behave more professionally". "We want to use Scrum to improve upfront estimates and stay within budget". "We want the team to work more efficiently and become more productive". "We don't have room for a project manager, so Scrum is our best option". There is nothing wrong with these goals. I'm…

Software (& product) development is never a simple endeavor. Save perhaps for projects that run a couple of days and involve only a handful of people. The vast majority of projects can easily be considered complex. By 'complex' I mean: too many variables and potential (emergent) interactions to reliably predict the (near) future. Yet, we seem to suffer from a powerful cognitive bias that makes us discount complexity with statements like 'it can't be that hard', 'we've done this before' and 'we already know pretty well what to make'. I often run into people that feel that their 'project isn't…