What causes dark Scrum
- management not involved
- people lack motivation
Other reasons I see:
What causes dark Scrum
Other reasons I see:
Coupling exists when one part of the system is impacted by changes to another part. Where there is too much coupling, changes to a system can be difficult, time-consuming, and often destructive.
That said, coupling is also necessary. When objects collaborate with each other then they must interact, and this always creates some form of coupling among them.
Given that coupling is both needed and can also be problematic, this means that there is both good and bad coupling in a system.
“Loose” is the term most people use when they think the coupling is the way it should be. I prefer the term “intentional” because it means the coupling was created on purpose, and will therefore make sense and be expected to exist. Developers are smart; they never intend bad or excessive coupling.
“Tight” is the term people use to describe poor or excessive coupling, but I prefer the term “accidental.” The coupling we don’t want is the coupling we never intended in the first place; it’s a mistake. When we discover coupling that exists but serves no purpose, we find a way to eliminate it.
Here again, the patterns will help us. The coupling in each pattern is there for a defined reason, is logical and meaningful, and therefore intentional.
This begins a new blog series called FLEX Coaches Corner. I have just started Adopting FLEX online. Each lesson has a ‘coaches corner’ where I present coaching tips for participants. Each week I’ll put one of these out on Net Objectives Thoughts and collect them as Coaches Clinic.
We are told people always resist it, but this is an over-simplification. Consider this excerpt from A Simpler Way. Margaret Wheatley & Myron Kellner-Rogers
Frameworks should be architected in the same way that software systems are. Both need to be able to evolve without adding complexity, be robust and be clear in how their different components interact. Few frameworks, other than FLEX, however, have what could be called an architecture. Most are collections of value and practices loosely overlaying some principles (which, often enough the framework itself doesn’t follow well).
When I started writing up Net Objectives’ 14 years of experience in Agile at scale that has now become FLEX I came from a foundation of the following:
Cohesion is a quality indicting alignment. The best way to understand and remember this is to relate the root word “cohere” to the term coherent. Lasers are often called coherent light because all the of the beams of light in a laser are perfectly aligned.
What does this mean in software? It has to do with scoping, and we focus on two version of creating scope: class scope and method scope. Continue reading “Qualities Patterns Share: Strong Cohesion”
In my earlier post I explained why we needed this. In this one I’ll describe some principles and practices that should be in it
Use some degree of test-first. At a minimum, anytime a request is made the question “how will I know I’ve done that” should be asked
An understanding that delays in feedback, workflow and between getting and using information causes unplanned work
Scrum proponents take pride in the fact that Scrum can work anywhere, in any domain. But keeping it in its generic form leaves big gaps in the practices people should be using.
The result of this is often that people have to reinvent things and don’t have ready access to concepts that would guide their adoption. These challenges are exacerbated when the immutable aspects of Scrum need to be modified a little. What often happens is people try to follow Scrum, often referring to the Scrum Guide and what they learned in their CSM class. They should be using Scrum as an open framework as it’s intended.
The Adopting FLEX online workshop gets into full gear next week. I believe this is the start of the next wave of Agile on many levels
Since ’05 I’ve been working on overcoming several challenges:
FLEX solves these challenges by incorporating approaches various Net Objectives consultants have done over the last 20 years. FLEX is an expert system that guides consultants in how to help an organization improve by both providing guidance and creating a shorter workshop tailored for the organization that will implement FLEX.
I am excited to have a group of people working with me on taking this into the future.
Learn more here
I’m going to be using the terms quality, principles, and practices quite a bit, so it might be useful to explain how I am using them, just for the sake of clarity.
By quality, I am referring to an aspect of design that is desirable or, if missing, is a deficit. In general, the qualities I look for make it easier to change things, since maintenance is the major expense in most systems.
By principle, I mean general guidance about design, concepts that can inform our decisions in many different ways depending on circumstances. Principles are almost never perfectly achievable, but they are always important to keep in mind. The Golden Rule is a principle that we try to follow in polite society. That’s the sort of thing I mean. Continue reading “Qualities, Principles, Practices”