Nice to See Scrum Catching Up (or Trying To)

Recently, Scrum.org announced the integration of Kanban practices into Scrum and that “Observe Orient Decide Act (OODA) is the mindset of Scrum. This comes on top of the announcement of Scrum team training a few years ago. These are all good things. It’s nice to see the Scrum community trying to catch up to the many non-certifying consultants who’ve been doing these things for 5-10 before. Continue reading “Nice to See Scrum Catching Up (or Trying To)”

How Design Patterns Give Insights Into Process Patterns

Design patterns are often described as “solutions to recurring problems within a context.”But the real power of patterns is to see the forces that each pattern resolves. They should be used as a way to help analyze what’s needed to create a quality design. That is the goal.

Given a situation where, say, the Strategy Pattern was not quite present but its concepts could be used, no one who understood patterns would criticize the solution by saying ,“Well, that’s not a Strategy Pattern!” So why do we hear these sorts of critiques in the process world? Let’s think about it. Continue reading “How Design Patterns Give Insights Into Process Patterns”

Agile is Here to Stay (Or at Least the Being of It)

The most important words of the Agile Manifesto are, “We are uncovering better ways …” This should continue to be true.

Agile is often thought of as a way of being. But getting people to “be” Agile is hard. And it’s not clear what “doing Agile” is. Being” is good. But getting there is another issue. It requires us to continue to be “uncovering better ways.” Continue reading “Agile is Here to Stay (Or at Least the Being of It)”

Something has Happened to Me (Not My Normal Rant)

I’ve been having a very interesting two weeks. I would like to say that whenever I go into a client, I am always on, and always get my clients to see new opportunities. But I’d be lying.

However, for the last two weeks, that’s been what’s been happening… with five clients. While I feel I’ve been “on” and empathetic, that only explains half of it. Something else has been going on.

Here is what I think has been happening. In all of the cases, I started out with:

  • Depicting a value stream representing what they’d like to happen
  • Adding their team names, relating this to what people were doing now (making it less theoretical)
  • Identifying the client’s problems in this ideal flow

At this point, they started asking how to solve their problems. Often, they are stumped about how to work with non-Agile teams or how to create predictability. They would ask, “How can you do this in Agile?” “What do you think about LeSS?” Essentially they were taking solutions they knew, or had heard of, and were trying them on.

It’s like shopping for clothes. Every company is shaped differently. There may be lots of clothes (solutions) out there that don’t always fit. That’s when you want to learn to be a tailor.

This is the first of a series on the implications of these insights.

New Teams Can Avoid Common Errors by Understanding Cost of Delay

In an earlier post, I discussed how attending to the cost of delay helps us focus on removing delays in workflow, feedback, communication, and error detection. This involves a focus on finishing (not starting a new story if you can help somebody else with an existing story), working on small stories, and using test-first methods.


Note: This is a continuation of the post, Using Cost of Delay to Improve Scrum

Teams new to Scrum face many common challenges.

  • Not finishing stories at the end of a sprint because too many have been opened
  • Too many untested stories at the end of a sprint
  • Doing an analysis sprint, design sprint, coding sprint, testing sprint (“Scrumerfall”)
  • Separation of coding and testing responsibilities
  • After the demo, realizing there were misunderstood requirements

In an earlier post, I discussed how attending to the cost of delay helps us focus on removing delays in workflow, feedback, communication, and error detection. This involves a focus on finishing (not starting a new story if you can help somebody else with an existing story), working on small stories, and using test-first methods.

Review that list of challenges. Each of these challenges show up as impediments at the end of a sprint. Each can be avoided, or at least mitigated, by following the guidance of removing delays by focusing on lowering the cost of delay.

No longer will you be removing impediments after they’ve been discovered. Now, you will remove them before you even hit them!

The Future of Agile

Here are some of the things Agile has demonstrated to be of value.

  • Having self-organizing small teams
  • Building incrementally
  • Taking an iterative approach

However, an organization is not merely a collection of small teams, it must also do the following:

  • Have a vision to guide what is built
  • Have collaboration across teams

All this means we need an ecosystem that illuminates the vision and allows teams to self-organize to achieve it. Continue reading “The Future of Agile”

The Third Leg of Emergent Design: Acceptance Test-Driven Development (ATDD)

In previous posts, I discussed that the first leg of emergent design is TDD, which provides code quality and sustainability. The second leg is design patterns, which provides insights into handling variation. The third leg is ATDD, which provides us a way of discovering and clarifying the value we will get. Continue reading “The Third Leg of Emergent Design: Acceptance Test-Driven Development (ATDD)”

Design Patterns: The Second Leg of Emergent Design

TDD is the first leg of emergent design or what could be called Agile Design. Design patterns are the second. They’re often described as “solutions to recurring problems in a context.” In this way they can be thought of as recipes that have been learned. But patterns open the door to much more; they are examples of ways to think. Patterns hide varying behavior, structure or which objects to use. Continue reading “Design Patterns: The Second Leg of Emergent Design”

Test-Driven Development (TDD): The First Leg of Emergent Design

I am heartened by the surge in TDD training. To me, TDD is the second most important thing for devs to learn. ATDD is the first.

TDD is not just the automation of unit testing. It’s also intended to improve design and sustainability.

TDD’s formulation of tests, prior to code, drives design. High quality code is easy to test. The reverse is also true. Code that is easy to test is higher quality than code that isn’t. I labeled this quality, “testability,” in my book Design Patterns Explained. Test-First is a process where deciding on your tests before writing your code improves your design. Continue reading “Test-Driven Development (TDD): The First Leg of Emergent Design”