TDD “Good” Tests Part 3. There must be no other test that fails for this reason

When organizations adopt TDD as their development paradigm, early results can be quite good once the teams get over the initial learning curve. Code quality goes up, defect rate goes down, and the team gains confidence which allows them to be aggressive in pursuing business value.

But there is a negative trend that can emerge as the test suite grows in size over time. Continue reading “TDD “Good” Tests Part 3. There must be no other test that fails for this reason”

What I have Learned from Scrum

Here are some things I have learned from Scrum.

  • Cross functional teams are good. Just having them achieves a three to tenfold improvement over a group of people working on several projects at once. And they improve innovation by the team.
  • Time-boxing increases discipline, visibility and the ability to pivot.
  • Small batches are good and breaking work down into small pieces is essential.
  • Smaller release cycles improve most everything.
  • It is useful to have a team coach.
  • Do not expect people to figure out what they need to do just because you have put them in a framework.
  • Focus on learning the practices of a framework makes learning what you actually need to accomplish (flow) harder.
  • People like to be given a set of practices to use.
  • Defining a simple set of practices to use can lead to rigid dogma.
  • Take an approach that transitions you to the behaviors you need.
  • Approaches that work well in one context may not work well in another even though people them everywhere without noticing this.
  • And, just because you can put whatever you want into a framework, that doesn’t mean the framework is not prescriptive. In itself, the framework has things you must do.

Continue reading “What I have Learned from Scrum”

What I Think About Scrum

First of all, I like Scrum. I think it can be a great framework when used in the right place. But I also think it must be taught as a tool in your toolbox, not an end in and of itself. This means initial training of Scrum should include more of the flow model (eliminating delays in workflow, feedback and using information) on which it is based. Test-first methods should also be incorporated into this training. This combination allows for teams to avoid most of the pitfalls teams new to Scrum face. I also believe one should look to see if Scrum or Kanban is better for a particular team (or something in between). See first comment for how I do this.

See Why Agile Coaches Need to Know Both Scrum and Kanban.   

Continue reading “What I Think About Scrum”

Why Being Explicit in Workflow is Useful: Case Study, Scrum Based on Lean Flow

Scrum is a lightweight framework that encourages correct action through performing its ceremonies and practices. While that is great in theory, the lack of the “why” of the ceremonies often has them be not followed.

Consider the “sprint” in Scrum. According to the Scrum Guide, “The heart of Scrum is a Sprint, a time-box of one month or less during which a ‘Done,’ usable, and potentially releasable product increment is created.”

It implies the need to start and finish stories in the same iteration. In other words, one of its objectives is to have a short time between the beginning of a story until it is completed. Here is what this provides. Continue reading “Why Being Explicit in Workflow is Useful: Case Study, Scrum Based on Lean Flow”

Improve Your Scrum by Using Flow Thinking

Scrum is based on empirical process control, the pillars of which are transparency, inspection, and adaptation. This mostly means that instead of following a plan we observe how things are going and adjust accordingly. But this doesn’t mean that we can’t use theory. It’s just that when we do use theory we must verify it worked. Continue reading “Improve Your Scrum by Using Flow Thinking”

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”

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!

Using Cost of Delay to Improve Scrum

If you only quantify one thing, quantify the Cost of Delay” – Don Reinertsen

Cost of delay is the overall cost of loss in revenue, lost opportunity, increased risks, customer respect, etc., due to a delay in realization of value.

This jewel of advice not only tunes us in to what’s important, but it can guide us in all aspects of value creation and delivery. It’s what’s behind CICD, small stories, avoiding handoffs, not working on too many things, automated testing, test-first and more. Pause for a moment and consider how each of these remove delays in workflow, feedback, communication and error detection.

Projects miss schedules not because of one big delay, but due to a succession of small delays – each having a cumulative and cascading sequence of events that compound each other.

Using a mantra of eliminating these delays provides insights for how product owners, ScrumMasters and the team itself can work. Anticipating delays can even enable avoiding impediments instead of having to wait to hit them. The causes of delays are primarily working on items of lesser importance, lacking a focus on finishing, having too much work in process, lack of cross-functional teams, large stories and lack of collaboration. Understanding this greatly speeds up the adoption of Scrum for new teams.

 

 

 

 

Three ways to get trained in Scrum

Focus on Scrum. Use its practices, events and artifacts to drive teams to improve. For example, time boxing requires smaller stories. Releasable quality code at the end of the sprint encourages team members to work together. Retrospections are about learning. Daily Scrums provide an opportunity to pivot each day. This is the common way certified training is done.

Take a CSM course and teach it to your teams. This somewhat follows the above method as CSM classes also focus on Scrum.

Learn principles of flow (Lean) and Agile. Focus on how to do Agile work (small stories, collaboration, test-first, …) and then teach Scrum in how to support it.

The first two approaches teach Scrum but leave it to the team to learn what they need to do. The last approach gets people started on their real work and teaches how Scrum can support it.

Note: When I write things like this it seems clear to me which of these is the best way. Is it not clear to others?