Qualities, Principles, Practices

I’m going to be use 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. Principle 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.

By practice, I am referring to actions we take which have been accepted as universally good. Doctors always clean their hands and instruments. Carpenters always measure twice before they cut. Software has these “always” actions as well, and I want to examine and promote a few.

I will start with the qualities that all patterns share, then the principles they follow, then after I write about the patterns themselves I will cover some good practices that they promote.

What If?

What if a leader in Scrum, Kanban, Lean, Flow, SAFe, design patterns, ATDD, …

… when he saw a challenge with a framework he worked on overcoming it

… was focused on results not on creating a unique framework

… didn’t agree with others that there were limitations on what could be done

… didn’t think simple to understand meant difficult to implement

… attended to the dilemmas in creating approaches that were straightforward to start and guided you in improvement

… respected people’s knowledge and didn’t think they should trust consultant’s recommendations but trust themselves after a little guidance

… believed consultants should work themselves out of a job as soon as possible

… thought the attention should be on the work, not the framework

… argued for what worked, not defended frameworks

… put together a framework that incorporated the good that was learned while avoiding the limitations that had been accepted

After 20 years of working on this, there is, and the result is a new kind of framework. One based on patterns thinking that provides a tailored start and includes how to learn to improve. It’s based on laws of development, not my opinion. The first online workshop (with me guiding you) starts this week.

Please let me know if you’re interested.

How does your approach help you start and learn?

Note: This post is one of a series in the post Questions to ask about your approach.

Frameworks should provide a quick start while helping organizations continue to improve. Here are a few different approaches taken.

I. Provide a preset framework that has you do what it says until you learn to adjust (Scrum). The challenge with this is that the preset practices may not fit. This may have them lose faith in the entire transition. In addition, there is nothing in the framework that tells them how to transcend the starting practices. People may eventually feel locked in and just try new things with little guidance.

II. Provide some theory with preset practices (SAFe). This has somewhat the same challenges as I. above with the additional challenge of putting people into cognitive overload which results in few principles being remembered.

Both I & II focus on learning the framework with no training provided to transcend it.

III. Provide great detail in principles and let them figure out the practices. This does ground people in principles, but most want an answer to “what do I do?”

IV. Provide principles, a starting set of practices with options and a roadmap on how to select the practices that work for you. This gets people started on something that works for them while providing a way to improve. Yes, this is FLEX.

Advice from the GoF: Encapsulate the concept that varies

The Gang of Four book states,

Consider what should be variable in your design and encapsulate the concept that varies.

To a modern agile developer, the word “should” is a bit of a red flag. It presumes that we know, ahead of time, what is going to change. We don’t believe this and we certainly don’t want to depend on guessing correctly.

It is good to remember that the book precedes the agile movement and, in this regard, perhaps reflects an old point of view. But the advice is not obsolete, it just needs a bit of an update. It should say,

Consider what has become variable in your design and encapsulate the concept that varies.

Continue reading “Advice from the GoF: Encapsulate the concept that varies”

Lean-Agile Newsletter – July 17, 2019

Net Objectives

Last newsletter we announced our FLEX Train the trainer program. But as I’m working with clients — some using FLEX, others in improving their SAFe adoption — I find myself recommending the FLEX 3 day workshop to them so they can understand both the recommended practices and principles better, and therefore be more self-sufficient and require less coaching. We have an online one coming up next week (starting July 22), so I wanted to make sure you knew it was about to start. Continue reading “Lean-Agile Newsletter – July 17, 2019”

Know five things to be a flow whisperer

 

Getting people to work together may be difficult. Knowing whether what you are doing is moving you in the right direction isn’t. There are two mantras to follow:

  1. minimize cost of delay (deliver the most value quickly)
  2. flow when you can, pull when you must (avoid handoffs and focus on what’s most important)

The first deals with working on the right things, the second working on them the right way. Both are implemented by: Continue reading “Know five things to be a flow whisperer”

Does your approach utilize the concept of smallest realizable chunk of value that can be realized?

One of the cornerstones of Flow, Agile and the Lean Startup is quick delivery of value to customers. This reduces waste by focusing on what’s of greatest value while enabling pivoting and creating a tight bond between the organization and its customers.

We call this concept the Minimum Business Increment (MBI). The intention is to answer two questions when faced with implementing an initiative. 1:”what is of highest value that I can deliver quickest?” 2: “what besides development is necessary for the realization of this value?” MBIs lie between epics and features in size and are what calculating cost of delay (CoD) should be done on. Calculating WSJF on epics or features doesn’t make sense. Only subsets of an epic as delivered at a time, WSJF should be calculated on that. Features may not provide value on their own, so CoD is incalculable. Continue reading “Does your approach utilize the concept of smallest realizable chunk of value that can be realized?”

Advice from the GoF: Favor Composition Over Inheritance

Composition indicates a “has-a” relationship between objects. Inheritance, on the other hand, indicates an “is-a” relationship. The Gang of Four would seem to be suggesting that you lean toward (“favor”) the former rather than the latter.

The potentially confusing aspect of this is that the patterns they delineate in the book use inheritance fairly extensively. Why would they recommend against this, and then do it? Continue reading “Advice from the GoF: Favor Composition Over Inheritance”

Does your approach utilize the concept of identifying the smallest deliverable chunks of value that can be realized in order to achieve alignment and the quick realization of value?

One of the cornerstones of Flow, Agile and the Lean Startup is quick delivery of value to customers. This reduces waste by focusing on what’s of greatest value while enabling pivoting and creating a tight bond between the organization and its customers

We call this the Minimum Business Increment (MBI). The intention is to answer the question “what is of highest value that I can deliver quickest?” MBIs lie between epics and features in size and are what calculating cost of delay (CoD) should be done on. Calculating CoD on epics infers delaying the most valuable part of an epic or the rest of it. Calculating CoD for a feature that can’t be delivered by itself is meaningless. Continue reading “Does your approach utilize the concept of identifying the smallest deliverable chunks of value that can be realized in order to achieve alignment and the quick realization of value?”

What agreements does your approach suggest you make with each other across the organization?

Many frameworks imply this agreement is to follow the framework. Others, such as Scrum, go further and insist you follow at least the immutable practices, rules, events and roles. This puts the focus on how individuals follow their role in the framework instead of how they work together.

While this may seem natural, it takes everyone’s focus off agreements between each other. It also has people follow the framework instead of seeing how they should really work together.

Continue reading “What agreements does your approach suggest you make with each other across the organization?”