(2017-06-25) Jeffries New Software Development Framework Ideas

Ron Jeffries is not working on a new Agile Software Development framework, but he is thinking through the process to clarify his thinking.

Agile Manifesto Principles and Values

Practices (from XP)

Whole Team

Planning Game

Two key aspects at least: Iteration or Sprint planning (Planning Game), and “release planning”. Is the latter necessary?

Small Releases

This is fundamental! Bring this up to the top in the notion of Increment

Customer Tests

Good way to be sure, every iteration, that the product still works. Not sufficient on its own, or with Programmer Testing, yet often better than many teams have today.

Collective Ownership

Includes the key notion that “T-Shaped” or “Paint-drip Shaped” people are more valuable than isolated specialists.

Coding Standard

Sustainable Pace

Metaphor

some idea of common understanding among the Whole Team of how the product works. Not just the code style, or the architecture, but also the overall conceptual coherence of the product idea and design.

Continuous Integration

Too specific. Part of Increment

Test-Driven Development

Former name Programmer Testing was probably better. Perhaps the fundamental idea is Confidence

Note that Confidence is a good place to put “sapient” testing, user testing, market testing, and the like. (About which I know almost nothing.)

Refactoring

Simple Design

One aspect is that we must perforce evolve the design and should therefore start with the simplest design that can work, and must be very skilled at evolving that design

Pair Programming

Scrum

Scaling

Yes, well, I’m against it. We’ll talk about what I mean by that.

Agile Fluency Model

Variants

Terms

Part of this “New Framework” idea – maybe all of it – is to try to clarify my thinking about “Agile”, what it means, and how to express it.

we’ll need to set this in context, of course, addressing management concerns, product concerns, executive concerns, and so on. Right now, I’m not sure how far I’ll press in those directions, since more than these others, I care about developers.

Practices

It’s important to practice, and to work, mindfully

To some people, practices are just things you do mindlessly. So maybe the term is a problem.

To me, the team’s job is to decide, wisely, what practices are good for them.

What might we talk about instead? How about “skills”?

Skills

Techniques

both Technique and Skill have different connotations and the distinction might be useful

Values

I’m more and more troubled by methods having “Values”.

If we mean that XP is designed to improve communication, increase simplicity, provide better feedback, and enable courage, that’s fine

If, however, we say that in order to apply the ideas of some framework, you must have these values, I think we may be going too far.

The Whole Team

The Manifesto is about values, and principles. I share those and think they are quite important. However, I believe that what happens in the world depends on what we actually do, not on what we just believe. Therefore, I’ll be writing a lot about practices … the things we actually do.

Practices

“XP is like Scrum, except that it works.”

Whole Team

We need to deconstruct this a bit, because there’s a lot in there

Cross-functional Dev Team (product team)

On-site Customer / Product Owner

If we’re to accomplish this responsibly, we can’t be relying much, if at all, on key skills outside the team.

We need to build an increment every week or so.

this person is held responsible by the business.

the ideal point is a Team without an owner, a boss, or a manager. The Team would own itself and manage itself. That is surely an ideal and it’s not clear that we all will get there, or that we even should.

Frameworks and Brands

yesterday, I was asked to express my view on one of today’s modern approaches to “Agile”, complete with a new brand name and punchy slogans and all that. Here are some general thoughts about that

Seventeen aging white men came together in Snowbird, to talk about their common interests in what were then called lightweight methods.

After the Manifesto, things changed. 9-11 happened, and the economy went into recession or whatever they called it.

I think we could have worked in a way to join people’s thinking together, to build on each others work in a more direct fashion. I think in so doing, we’d move from “Should we do SAFe or Dad”, to more useful questions and answers, like “How can we shorten time to market” and “Let’s draw a value stream map”. I think that would have been better. I think it would have been a hell of a lot better.

So while I am writing here about a “new framework”, I’m really writing about the items I’d focus on in doing effective software development, not about the Ron Jeffries Brand Software Development Method™.

The Increment

At regular intervals, preferably every week or two

We explore then whether, if the developers did provide such a thing, the questioner would better know what’s going on and have a better sense of when things would be done. Generally the answer is “yes”.

Stakeholder Concerns

"We have an ordered list (backlog), but the developers say first they have to build infrastructure or architecture or something about frameworks and stacks and Dockers or Nikes or something. They tell us they’ll work on our list after that."

What we know how to do here in the 21st century is to deliver business capability every couple of weeks, while building up the underpinnings as we go. I say “we”. What I mean is that there are known and practical techniques for doing that. Quite probably, your team doesn’t know how to do that.

"The team can’t really do very much in only a couple of weeks. Our needs are large, so it can take months before they have anything worth looking at."

I’d like to suggest that you’re conflating two ideas, “worth shipping”, and “worth having”.

Your first responsibility in providing that ordered list of things to do is to learn to make those things small enough to be done in a couple of weeks (and a couple of days is better, and usually possible).

They’re showing us what they’ve got, and it’s good, but they’re not going fast enough. We need to go faster.

Your first job as stakeholders is to observe the real progress, and make your decisions based on what happens, not what you wish.

Absent a Genie, your first strategy in response to real progress is to be sure you are picking the most important things to do, and to slice them down as small as possible. Your job is to get the most valuable possible product, at the end of each iteration. You do that by carefully selecting what to do and what to defer.

Possibly the team needs to slow down.

Possibly the team needs skills that aren’t available on the team

Possibly the team needs to have higher skills. Building software Incrementally isn’t easy. They may need training or coaching.

How I work (mostly) TDD-style

A wild TDD flowchart has appeared!

This thing is weird in a number of ways

I found a PDF of the article.

I’d interpret the results of this tiny experiment this way:

• Using more varieties of tests is likely to find more bugs than using fewer varieties;
• TDD alone is probably not enough for robust testing of a complex program.
• Instructing students to use many ways of testing probably delivers better results than telling them to use only one kind of test.

the development-focused Agilistas I know recommend acceptance-level tests as well as the smaller-scale TDD tests. See Programmer Tests and Customer Tests in classic XP. Agilistas also recommend “sapient” exploratory testing by people with strong testing skills.

I believe that if a Customer Test fails, or a defect is found, we can always think of a valid Programmer Test that is missing or wrong. I believe, in other words, that every defect in a program can be, and should be, detected by a low-level test of a single object or a very small number of collaborating objects. (I’m wrong in this belief and I can prove it, but it’s the way to bet.)

Here, I plan to describe how I develop code, with TDD a key part of what I do.

The big picture

With TDD, the code grows around a simple framework of Red / Green / Refactor.

What really goes on is continuous thinking, experimenting, wandering, learning, trying.

In some detail …

I’m thinking about the information I have, and how I can transform it into the information I want.

Very often, there’s some system object that we need to learn about to build our feature. Maybe it’s in the base libraries or some library that we use, or could use. Maybe it’s in our own code base, but we don’t remember much about it. So we need to learn about it. In a word, we’re experimenting.

Maybe we’ll write a little program in a file, with print statements in it, run it and see what it prints. We’ll change the inputs, and run again.

Personally, I try to remember to put assert statements in these but sometimes I still just print things out. What I’m doing in this case is building something to save. The test cases can be used later to remind me how this object works. Using asserts works better, because it records the learning in the test, so I hope you help me remember to do this as we pair

Maybe we’ll create a new test class, and put test cases into it, much like the cases we’d use in a sandbox or file.

Of course, we need less of all this if the objects in question are already in the system and have useful low level tests. Lesson to learn here: write low level tests.

First, we usually run our tests to be sure that they all still run. If they don’t, we fall out of this process

When I’m at my best, you can slow me down, and we set out to create a new TestCase, or begin to extend an existing one.

We write a small test (Arrange, Act, Assert, with Assert written first most times). What we’re doing here is designing.

Now, often, I forget to watch the test fail. I’m sure it will, so I just go ahead and move to the coding step below. When you catch me doing this, please correct me.

Now, we write as little code as we can to make the single failing test pass

I think I’d do well to have a five- or ten-minute timer to alert me when the tests haven’t gone Green for that long

When the test passes, I usually have the next step in mind. Probably you’re the same. I try always to remember to look at the code and clean it up.

Wait, isn’t TDD just Red, Green, Refactor?

sometimes, strict TDD seems to get in my way. My thoughts are so ill-formed that I can’t even yet imagine a test – or it seems that I can’t.