Agilistic

What I've learned while working with Scrum and Agile software development.

If you are working with Scrum and you have a DTAP-pipeline or DTAP-street (Development > Testing > Acceptance > Production), it is my humble opinion 'that you are doing it wrong'. I strongly believe that DTAP - or at least having separate environments for testing (T an A) - is an anti-pattern in an Agile environment. In this post I explain why and what you can do about it. Recognize this? ... I don't say this lightly. I've just seen and been in too many Scrum Teams that struggle with their DTAP-pipeline. This struggle manifests in several behaviors: 'Deploy Friday': When deployment takes considerable…

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…

Automating manual work, such as deploying your application or running tests, can be a daunting task. Most teams agree that automation is important. But not knowing where to start with this 'huge and important thing', they keep pushing it into the future. In this post I offer a practical approach to get started with automation tomorrow. Automation is one of the cornerstones of Agile software development. The idea is that manual work is tedious, error-prone and therefore something you're likely to do as infrequently as possible. This includes tasks such as testing your application and releasing a new version of…

Technical debt is one of the greatest frustrations and de-motivators of the Development Teams I work with. Teams generally have no difficulty summoning up examples of technical debt in their codebase. Shortcuts in the code, low-quality code, temporary-but-not-really workarounds and other hacks that may solve short-term solutions but guarantee long-term pain. Development Teams are often acutely aware of the accumulation of technical debt, but feel powerless and unable to explain why technical debt should be a priority. Instead, they feel that 'business keeps adding more features over stabilizing the foundation'. In this post I offer four practical tips on how…

We (Christiaan Verwijs & Barry Overeem) wrote this post collaboratively to share our insights and lessons learned by applying Lean Change Management in practice. A couple of weeks ago Barry Overeem, Hans van der Burgh and I facilitated a workshop for an organization in the Dutch energy market. The workshop focused on two themes: Moving from “doing agile” towards “being agile” Improving the alignment and collaboration between business and IT We proposed to facilitate a one-day workshop to jointly explore the challenge and extract a handful of concrete experiments for the upcoming weeks. As the foundation for this workshop we…