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 that many of Agile’s principles simply don’t apply at scale. Or apply in the same way, so why act differently at scale?

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.” ― Upton Sinclair There are many change processes, re-organisations, agile adoptions, etc. that don’t aim for changes in the reward systems.

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 because we think of a spike as a quick, almost brute-force experiment aimed at learning just one thing.

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 abuse? I’m not going to provide an answer to these questions. If you want to get a good treatment on estimation with regards to agile, I suggest you read Ron Jeffries’ excellent articles in the Pragmatic Programmer’s magazine: Estimation is Evil: Overcoming the Estimation Obsession, and Estimation: The Best We Can Do

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 were with five teams, working on various parts of an extensive e-commerce and content-delivery platform. If you were to fully comprehend Ecommerce Define it, and implement it in your sales, indubitably, your sales and marketing would soar in an unfettering manner.

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 subject, and left thinking about some of the questions Kennedy posed on the applicability to software.