Some recent thoughts on estimation, in view of recent events and tweets. My particular focus will be on whether and how we might estimate total effort in incremental, iterative development efforts. Agile as it should be done (in my view.) By "total effort", I mean the estimation of the total cost, in time/money, of building some contemplated "whole thing". To many, this is a big, important, necessary question that must be answered.

I signed up so as to reply, saying:

This is the most outrageous public intentional example of Dark Scrum that I have ever seen.

The very notion of "insubordination" is counter to Scrum principles and Agile principles.

https://twitter.com/RonJeffries/status/1488520161737027607

The notion that the ScrumMaster (thanks above for term ScrumBastard) can give any orders is directly opposed to the notion of ScrumMaster as a servant leader.

The idea that management gets to say whether people stand up or sit down is ludicrous.

I'm wondering some things about developers on Scrum teams. If you are one, please try these surveys, and pass the thread on to other Scrum devs.

How many developers on your team? Do you have a trained ScrumMaster and/or Product Owner?

I have what seems to me to be an "interesting" problem in my long-running Dungeon series. A dungeon is an array of tiles. Randomly placed in the array are rectangular rooms.

1/8 Rooms are connected from room N to room N-1 by halls from center to center, either first H then V or first V then H. This means that a given all way can cut through any other room, two halls can be side by side, making a wide hallway, and so on.

2/8

What matters?

Could we maybe stop fomenting hatred?
Could we maybe start calling it out as wring?

1/2 What doesn't matter?

Dungeon 124
I want to get a creature to lead us to the WayDown. And I feel the need to improve the campground. Also St. Gertude. And, as often happens, we don't go where I expect. Neat outcome, though
ronjeffries.com/articles/020-d…

2/2

while i wait for a call from "the nurse", here are some thoughts about tests, including but not limited to TDD.

XP describes to kinds of tests, Programmer Tests, and Customer Tests. These names describe who the tests primarily serve. Now in XP there are really only two main roles, programmer and customer. i don't want to argue about this right now, but customer is who the product is being written for, or their representative, and programmers are all the devs, testers, whatever software makers you have.

The thing about a framework, Scrum, TDD, whatever, is that it is a massive simplification of how the thing "should" be done.

A good framework has rumble strips and guard rails. When you hit those, they alert you to issues that the beginner would likely miss on their own.

1/9 As such, the framework IS NOT TRUE. If you follow it blindly, you will probably be OK, but you'll not be doing as well as you could, nor as well as the framework provider has in mind.

2/9

OK, strong article to follow but for now, listen up.
There's this idea, the red/green/refactor thing, the never write a line of code not required by a failing test thing, the evolve the design based on the test and code plus your lovely imagination thing, the keep it clean thing. I say "idea". You can see many ideas there already.

There is a name, TDD, Test-Driven Development or Test-Driven Design, that is applied to that bunch of ideas. We want to draw a bright line around the ideas that /are/ TDD, and to keep out the ones that are not TDD.

I'm writing a thing about what it feels like to do TDD, in a kind of response to the articles and remarks by @jcoplien and @dhh and others. I agree, of course, that 100% line coverage, which you get for free with TDD, doesn't mean much in a theoretical sense.

1/6 Even 100% branch coverage doesn't mean much. While I don't subscribe to all the math in Cope's article, it's true that, theoretically, a program with high coverage can include plenty of errors.

What's interesting is that in practice, theory doesn't quite work.

2/6

Well, I was going to write about "Doing it wrong" today, but it turns out that I already have. This article isn't quite what I'd say today but it's close:

ronjeffries.com/articles/019-0…

1/12 What would I say today that's different? Well, I'd clarify that there are at least three main ways that a TDD that doesn't work could differ from one that does:

- different design style.
- different problem: "TDD doesn't work here"
- different thing: "not TDD"

2/12

But seriously, here are a number of ways in which mastering Scrum is difficult ...

1/5

https://twitter.com/alshalloway/status/1208803053656166405

Creating a good backlog is difficult to master (DTM), especially since it's best to backlog problems, not solutions or stories.

Sprint Planning is DTM because it works best as a collaborative meeting, not a PO tells team what to do meeting.

2/5

TDD works for some people, not for others. The people it works for often (nearly always?) find it useful in some forms of development and less so in others.

To some degree, the second sentence may explain the first: some may be applying it where it doesn't work well for anyone. Further, TDD works best with very highly-factored designs, which provide lots of little things that can benefit from testing, and where TDD's forces suggest ways of doing that factoring.

That synergy, or its lack, may explain why some don't find TDD useful.

We spoke of the need to keep our design clean, in order to be able to improve the product at a consistent pace. Here's a bit more detail.

We start with a good design. (Note: the null design that does nothing is a good design.)

1/10 A new capability is requested. We see that it needs support that is part of the blue, orange, and green components, or somewhat /like/ those components.

2/10

When we start with a clean design ...

1/13 ... and a new feature comes along ...

2/13

This new Procreate feature must be good for something ... Apparently there's more to it than I supposed ... since that's supposed to be animated.

So, metrics. Metrics as goals or measures.

The Apple Watch has three "activity" rings, one that closes if you burn N calories, one that closes if you are on your feet in 12 separate hours, and one that closes with 30 minutes of exercise.

1/7 I decided to use those rings as incentive to get a little exercise, possibly live longer or happier. I've closed all three rings every day since September 1, 108 days or something like that.

2/7

Possibly, I have some thoughts on "safety", the notion that people need to have a feeling of safety in order to collaborate effectively. To pick an example we can maybe all understand, imagine that we're trying to communicate with the Red Queen.

1/14 The Red Queen is prone to shout "Off with her head" whenever you say anything the least bit critical or even misunderstanding of her ideas. And her courtiers are quite willing to execute that order -- no pun intended.

2/ 14

"Scrum is a lens. Work is done under the lens, not by the lens".

Scrum's foundation is "Inspect and Adapt", the notion that impediments to success will be identified ... and that the organization will remove them.

I'm puzzled about what often happens instead.

1/10 When we hear of a Dark- or Dimming-Scrum situation, we see the same issues again and again. A common one is failing to complete all the planned work, Sprint after Sprint. The team themselves point this out. Why have they not fixed the problem?

2/10

TDD. By which I mean the thing where you write a tiny test, see that it doesn't run, write just enough code to make it run, refactor the code to remove duplication and add clarity, repeat until done.

Why do we do that?

1/7 One word: productivity. A few words: most cost-effective path from here to done.

It's not about beauty, craft, a sense of pride, although it can provide all those things.

It's about using the most productive approach to getting our whole job done.

2/7

Even if we keep the design as clean as we can manage, our understanding of what the design "should be" grows and deviates from what the design is. Ward described how, sometimes, when we put that improved understanding into the actual design, the system improves.

2/22 There should be no surprise here: we've mostly all seen systems with designs that don't support their requirements well, and I hope most of us have seen systems whose design does a great job of supporting the system capabilities.

3/22

I think people generally do the best they can at any given moment in time, given all the forces acting upon them. They give what they've got, and allocate it across all the demands they're facing.

And yet, we manage to improve. How does that happen?

1/10 We are constrained ... but [most of us] are not entirely constrained. We have a bit of freedom, a bit of leeway, a bit of choice.

We can choose to use a bit of that bit of time to change how we operate, maybe even just to change a habit.

2/10