If you want to go fast and have high quality, communication has to be instant, and you need to automate everything. Structure the organisation to make this possible, learn to use the tools to do the automation. There's a lot going on about DevOps and Continuous Delivery. Great buzzwords, and actually great concepts. But not … Continue reading DevOps and Continuous Delivery
I wrote a while back about set-based design, and just recently about a way to frame scaling Agile as a mostly technical consideration. In this post I want to continue with those themes, combining them in a model for scaled agile for production and research. Scale In the previous post, we found that we can … Continue reading Scaling Agile with Set-Based Design
Last Friday I gave a talk at the Dare 2013 conference in Antwerp. The talk was about the experiences I and my colleague Ciarán ÓNeíll have had in a recent project, in which we found that sometimes a very directive, Just Do It approach will actually be the best way to get people in an … Continue reading The ‘Just Do It’ Approach To Change Management
organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations. -- Melvin Conway We often run into examples of Conway's Law in organizations where silo-ed departments prompt architectural choices that are not supportive of good software design. The multi-functional nature of Agile teams is one way to … Continue reading Conway’s Organizational Structure Heuristic
There's a lot of discussion in the Agile community on the matter of scaling agile. Should we all adopt Dean Leffingwell's Scaled Agile Framework? Do the Spotify tribe/squad thing? Or just roll our own? Or is Ron Jeffries' intuition right, and do the terms scaling and agile simply not mix? Ron's stance seems to be … Continue reading Scaling Agile?
Change processes are difficult to do. Most of them fail to have the intended results. The reasons for that can be many, of course. There is one, though, that is of particular interest to me today. “It is difficult to get a man to understand something, when his salary depends on his not understanding it.” … Continue reading Show me the money!
One of the concepts that came from XP is the Spike. Especially in teams new to agile, there can be confusion on what a Spike is, and how to deal with them. The best definition of a Spike I've found is this one: "Spike" is an Extreme Programming term meaning "experiment". We use the word … Continue reading Spikes, they’re sharp
Estimation is a sensitive subject in Agile. Should we estimate? Do we avoid estimation in days or other time-based units? If we use relative estimation like story points, do we standardize across teams? What do we use estimation for? Are we explicit enough in emphasizing the distinction between estimations and commitments? How do we prevent … Continue reading Not Estimating At Scale
Any good Agile initiative aims to get better at delivering business value. One might say that ultimately, that is what it's all about. So when we were well on our way to getting the nitty gritty details of software development under control, we knew we needed to get the business closer in the loop. We … Continue reading Business Value vs. Politics
Last year at the Lean and Kanban Benelux conference I attended a session by Michael Kennedy: Set-Based Decision Making: Taming System Complexity. Watch that video, where he explains the way that Toyota uses set-based design to be innovative without risk to the schedules of their new product development projects. I thought that was a very interesting … Continue reading Set-based design in software