What role do value streams play in your approach?

To be clear, I am referring to Lean’s (not SAFe’s) definition of the value stream – the set of actions that take place to add value to a customer from the initial request to delivery. The value stream begins with the initial concept, moves through various stages for one or more development teams and on through final delivery and support. You can’t define value streams – they are what is. You can, however, map them, define a “to be” value stream and you can improve them.

Continue reading “What role do value streams play in your approach?”

Good enough to ship is OK, even probably good. Good enough to stay, however, is not

The opening of the Agile Manifesto is:

“We are uncovering better ways of developing software by doing it and helping others do it.”

I would assert, however, that any approach (primarily frameworks) that has fixed practices in it (e.g., Scrum, SAFe) without a method of guiding how to go beyond them (e.g., Scrum, SAFe) may be great starts but are not truly Agile. The key is also _may be_ in that predetermined practices are not universal. BTW – LKU Kanban has its shortcomings as well in not attending to the entire value stream nor attempting to get to cross-functional teams.

There is nothing wrong with this. The trap is that people stop trying to go beyond them. Continue reading “Good enough to ship is OK, even probably good. Good enough to stay, however, is not”

Why If You’re Asking “Should I Use Scrum or Kanban?” You’re Asking the Wrong Question

originally posted July 2017. Co-written by Jim Sutton and Al Shalloway

Abstract: This blog suggests that instead of looking at whether we should choose between Scrum and Kanban, we can see Scrum and Kanban as process patterns and benefit from the best of both.

Scrum and Kanban are often presented as “solutions” for developing software within an organization. Yet every real organization combines unique histories, personalities, and individual skills and beliefs. Even the best off-the-shelf “solutions” require variations to fit the context of the real organization to which they are being applied. If the adopted approach is not designed for these variations, the results will be less than hoped for.

Continue reading “Why If You’re Asking “Should I Use Scrum or Kanban?” You’re Asking the Wrong Question”

Advice from the GoF: Design to Interfaces

Behavior in object-oriented systems is a reflection of the interaction of objects. If you change the objects, or alter their interaction, the resulting behavior changes.

This means that objects have relationships to other objects, usually through references that are used to call methods. The Gang of Four recommends that these relationships should be defined based on how the objects look to each other, not by how the objects are implemented. Continue reading “Advice from the GoF: Design to Interfaces”

Why you only need 2 hours to discover your impediments when you understand Flow

20 years ago, when we didn’t understand why Agile works as well as we do now, it made sense to discover impediments by attempting to get code completed within a 4 week sprint. But now it should only take you a couple of hours. How? By understanding Flow

Virtually all impediments are caused by a delay in the workflow, work being too big or too much work in process (WIP). Let’s see why this is true – here are some common impediments:

  1. incomplete stores at the end of a sprint (usually caused by large stories or because test lags coding or too many stories were started)
  2. unclear requirements (time from getting a requirement until verifying it is long)

What’s more, however, delays in workflow, large stories, and too much WIP virtually always cause impediments (try to find a case where they don’t)

So, next time you’re going to start Scrum, before you do, get a headstart by attending to delays, batch size and WIP. Once started you can continue to improve by changing your workflow to further reduce these. Of course, you always have to do retrospections to make sure you’re really getting improvement.


Methods in

  • A simple start is good, but using the same simple start everywhere is not
  • Enabling the adding of practices is good, giving guidance on which ones to add and providing them is even better
  • Some practices are really good, but none are optimal everywhere, so demanding everyone do them can be counter productive
  • Making it easy to adopt a framework is good, but doing it by leaving out critical parts is not
  • Adding functionality to a system is good, but it shouldn’t require making the system complicated
  • Incorporating practices from other mindsets is good, but pretending that this means your approach has the same mindset is not
  • Recognizing that most companies need to do similar things is good, pretending this means most companies need to start the same way is not

what other D.O.G.M.A. is out there?

What Design Patterns Represent

The Design Patterns movement, begun (in software) by Gamma, Helm, Johnson, and Vlissides, essentially elevated certain design elements as valuable, repeated, high-quality examples of a particular approach to design.

Their general advice was given in three parts:

  1. Design to Interfaces.
  2. Favor composition over inheritance.
  3. Encapsulate the concept that varies.

All patterns adhere to this rubric in different ways. Continue reading “What Design Patterns Represent”

Side affects of frameworks that focus on their practices and not your flow

Most of the behavior we get comes from the system in place. This means how the people are organized and the agreements (or not) they make with each other. When adopting frameworks, you are creating a new system. There are particular patterns of behavior driven by frameworks that focus on their practices more than on the flow thinking that is needed: Continue reading “Side affects of frameworks that focus on their practices and not your flow”

A new series by Scott Bain: Design Patterns

I recently wrote a long series of posts here on various topics about Test-Driven Development. I ended up writing so many of them, they resulted in a little book I published through Amazon Kindle Direct called The TDD Companion.

I’ve started to hand out copies of this book to student in my TDD courses.

That worked out so well, I thought to do it again on another set of topics, in this case centered on good object-oriented analysis and design. It’s another topic I teach, and I’m hoping it will result in another handy field guide, likely to be called The Design Patterns Companion, as I use the patterns as my way of teaching good design and analysis in OO.

Part of what made this work for me was the terrific feedback I got from many individuals on my LinkedIn, though I also put these up on Net Objectives Thoughts. So if you enjoyed the TDD posts, I hope you’ll find this new series to be equally valuable and that you’ll continue to share your thoughts on these topics with me.

There’s more to coaching than “being”

I’m not saying that how a coach “be’s” is not important. But it’s also not the only critical aspect of things. Good energy, knowing what to explain and explaining them well are critical. A great coach can explain the right things to people so that they can learn on their own.

The Agile community is currently focusing on certification and frameworks that make it easy to start. I believe this is much of the reason for Dark Scrum and Fake Agile.

We need to shift our focus to the laws of effective software development embodied in Flow and Lean thinking. These are usually touched on in framework training but then used to justify practices that are only partially consistent with them.

It’s amazing to me how this is as effective as it is. It is better when you integrate true Flow and Lean thinking with your practices. Go for smaller pieces, shorter timeframes and greater visibility. How to do this is easier with a framework designed around the value stream.

Don’t rely on framework thinking, rely on real thinking-yours. Don’t buy the quick excuses I hear many consultants espouse- “if only they’d do what’s in the guide”, “management wasn’t involved”, …

The job of the consultant is to guide the way, not blame their clients. That’s true being.