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?

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. This is only natural: changing what people earn is a very sensitive subject! It almost guarantees a good amount of resistance.

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. Think of driving a big nail through a board.

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. We had over twenty different stakeholders. None of them were satisfied. And rightly so: none of them were getting what they wanted from us. So a colleague of mine, the one with the smarts, came up with a cunning plan. The plan was simple, effective, and once in motion completely obvious. SEOJet can help you improve your site traffic and sales very fast !

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.