I'm pretty "agile" is mostly dead if not all dead--at least for marketing purposes. I do believe that its dozen principles (the meat of the values) remain valid, and many people would still buy into them if packaged appropriately.
I'm not going to begin to go into how damaging Scrum was in the evolution of all this. I won't forget being told by a "thought leader" to just get behind Scrum, because that was how we were going to win. (Well, it's how "they" won by making a small fortune off an MLM.)
I've stopped talking about it explicitly (for the most part) for many years, and instead have been just showing teams by example how to incrementally tackle and deliver software with high quality.
Love this - mirrors so much of my experience: first contact with XP, and surprising success (sold the process to our in-house customer, but couldn't convince the team to even try pairing or TDD - nevertheless, it was a success due to enthusiastic customer engagement ).
I completely agree with you. Scrum and Agile are often misunderstood in the industry, particularly in organizations starting a SAFe transformation. Frequently, it remains a mechanical process with a siloed, top-down approach, far removed from truly embracing the Agile mindset. As more large companies adopt Scrum, poor implementation is causing significant harm to our industry.
Personally, I approached Scrum as a mindset. It was only recently that I learned more about business transformation and organizational topologies. In a top-down approach, there is little room for true agilists in that context.
For this reason, I would probably stop using the word "Scrum" and instead refer to it as "The agile team process."
Who said anything about “forcing” anyone to do anything?
I have experienced that TDD make me a better developer and the teams I’ve been in and have coached were better for it. In those cases TDD was insufficient to ensure a quality product, which required testers to handle other types of testing. I would add that having BDD in addition to TDD is a good indicator of success.
For pairing and working in an ensemble, I’ve found that people who hate the former actually like the latter. But there are situations where neither are required. Again, though, my experience has been that some form of multi-person work is an indicator of success.
I am sorry for my phrasing. It is a reaction to years of having XP people tell me things like "If you don't like TDD, then you didn't give it a chance", or "If you don't like pairing, then you are not doing it right - just keep doing it and eventually you will get it and like it".
A lot of XP proponents _DO_ want to force it on people, so my stance was defensive.
BTW, I do understand these methods. I supported the introduction of XP into my company of 200 circa 2000. And over the decades since I have thought long and hard about it. I also examined it from a risk perspective in my 2006 book High-Assurance Design.
TDD is bottom-up process: create small functions that work, and when you observe that they don't fit together as well as you had planned, refactor. That's inductive.
Many people work really well that way. But a lot of people do _NOT_ work well that way: people who need to think the whole thing through before they start, in a reductive manner.
In the sciences we differentiate between these two personality types, referring them to as "experimentalists" and "theorists", respective. They are very different. The Wright Brothers were experimentalists. Einstein was a theorist. We need both, and we need to respect the role that each plays, and not tell them that they are doing it wrong - it would be like telling Einstein to spend more time in a lab, or telling the Wright Brothers to compute the mathematics of their designs before building anything. It would be a mismatch to what is natural for them.
Pairing is similar, in that some people work well that way - they are adept at talking things through with others. Other people do _NOT_ work well that way: they think best by going into their head, alone, and come back when they have thought things through - they and only then are they ready to talk.
Nice article, thanks Dave!
I'm pretty "agile" is mostly dead if not all dead--at least for marketing purposes. I do believe that its dozen principles (the meat of the values) remain valid, and many people would still buy into them if packaged appropriately.
I'm not going to begin to go into how damaging Scrum was in the evolution of all this. I won't forget being told by a "thought leader" to just get behind Scrum, because that was how we were going to win. (Well, it's how "they" won by making a small fortune off an MLM.)
I've stopped talking about it explicitly (for the most part) for many years, and instead have been just showing teams by example how to incrementally tackle and deliver software with high quality.
Your experience sounds very similar to mine! The key difference is that I haven't stopped talking about, for better or worse. 😀
And a big, red ❤️ to "showing teams by example how to incrementally tackle and deliver software with high quality"!
Love this - mirrors so much of my experience: first contact with XP, and surprising success (sold the process to our in-house customer, but couldn't convince the team to even try pairing or TDD - nevertheless, it was a success due to enthusiastic customer engagement ).
I completely agree with you. Scrum and Agile are often misunderstood in the industry, particularly in organizations starting a SAFe transformation. Frequently, it remains a mechanical process with a siloed, top-down approach, far removed from truly embracing the Agile mindset. As more large companies adopt Scrum, poor implementation is causing significant harm to our industry.
Personally, I approached Scrum as a mindset. It was only recently that I learned more about business transformation and organizational topologies. In a top-down approach, there is little room for true agilists in that context.
For this reason, I would probably stop using the word "Scrum" and instead refer to it as "The agile team process."
If I were forced to work in an "emsemble" or a "pair", I would quit. I would also quit if I were forced to use unit-level TDD.
Who said anything about “forcing” anyone to do anything?
I have experienced that TDD make me a better developer and the teams I’ve been in and have coached were better for it. In those cases TDD was insufficient to ensure a quality product, which required testers to handle other types of testing. I would add that having BDD in addition to TDD is a good indicator of success.
For pairing and working in an ensemble, I’ve found that people who hate the former actually like the latter. But there are situations where neither are required. Again, though, my experience has been that some form of multi-person work is an indicator of success.
I’m sure your mileage may vary. 🤷♂️
Hi Dave.
I am sorry for my phrasing. It is a reaction to years of having XP people tell me things like "If you don't like TDD, then you didn't give it a chance", or "If you don't like pairing, then you are not doing it right - just keep doing it and eventually you will get it and like it".
A lot of XP proponents _DO_ want to force it on people, so my stance was defensive.
BTW, I do understand these methods. I supported the introduction of XP into my company of 200 circa 2000. And over the decades since I have thought long and hard about it. I also examined it from a risk perspective in my 2006 book High-Assurance Design.
TDD is bottom-up process: create small functions that work, and when you observe that they don't fit together as well as you had planned, refactor. That's inductive.
Many people work really well that way. But a lot of people do _NOT_ work well that way: people who need to think the whole thing through before they start, in a reductive manner.
In the sciences we differentiate between these two personality types, referring them to as "experimentalists" and "theorists", respective. They are very different. The Wright Brothers were experimentalists. Einstein was a theorist. We need both, and we need to respect the role that each plays, and not tell them that they are doing it wrong - it would be like telling Einstein to spend more time in a lab, or telling the Wright Brothers to compute the mathematics of their designs before building anything. It would be a mismatch to what is natural for them.
Pairing is similar, in that some people work well that way - they are adept at talking things through with others. Other people do _NOT_ work well that way: they think best by going into their head, alone, and come back when they have thought things through - they and only then are they ready to talk.
Very best,
Cliff