A New Software Development Framework: Ideas

Here are some notes about where I might like to go in considering the New Framework idea. I’ll update this from time to time and maybe bump its date when I do. We’ll see.

Manifesto Principles and Values

This is where it all began, and for me, it all comes back to this. We’ll try to refer to the Manifesto where it’s appropriate, and may write some articles starting from it.

Practices (from XP)

Whole Team

A central idea, beginning with having at least all the developer and testing skills you need inside the team. Includes the Product Owner / Customer notions from Scrum and XP. The ideal, however, is surely a cross-functional, self-organizing Team with full responsibility and authority for building the desired product. Consider a team in a garage, or a Lean Startup.

Planning Game

Two key aspects at least: iteration or Sprint planning, and “release planning”. Is the latter necessary? If so, how should it be done? What responsibility does a self-organizing team have to think long-term, reveal its thoughts, commit to schedule?

Small Releases

This is fundamental! Bring this up to the top in the notion of Increment and make it central. Note that the Manifesto refers to “working software” about 300 times.

Customer Tests

Good idea, too specific?¹ Good way to ensure we understand and agree on the meaning of the next story slice. Good way to communicate when Customer is (somewhat) separate from development team. 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

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

Any “pair” can improve any code, any time. See Pair Programming

Coding Standard

Too specific, but a key point: we all try to code alike so that we can all understand everything we have all done.

Sustainable Pace

Many ideas hiding here? Dark Scrum pressure, “twice the work” thinking, concerns about commitment, prediction, estimation.

Fundamental idea is to work at a pace such that real progress is steady and consistent and predictable, and so that people don’t burn out. Consider human values like having a life.

Metaphor

This goes to 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. This is how you get the ability to build an Increment every iteration: if you don’t integrate every day, you’re in for a hellacious Friday and a long weekend of work.

Test-Driven Development

Too specific, yet a key skill to have. Works, when you’re good enough at it, better than anything else, especially in a team situation. Former name Programmer Testing was probably better. Perhaps the fundamental idea is Confidence, an increasing certainty that the product actually works, does what you intended, isn’t regressing, and is heading where you currently think you’d like to go.

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

Again too specific, yet absolutely critical. See Nature, need for incremental design implies refactoring implies automated tests.

Simple Design

Possibly Shared 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, using Refactoring and Programmer Tests, and Customer Tests to have Confidence that everything still works.

Pair Programming

A marvelous and difficult practice. Compare with Mob Programming, which may be less difficult and is certainly in the same idea space as pairing. Helps with Whole Team and Collective Ownership, helps to ensure team resilience under change, and flexibility as priorities shift.

Scrum

We’ll surely be talking about Scrum, and may or may not start articles from a look at Scrum

Scaling

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

Agile Fluency Model

An interesting model that may get referred to …

Variants

Other “name brand” forms exist. SAFe, which is politically safe at least. Modern Agile, FASTagile, DaD, LeSS, etc etc. We might find it desirable to compare with these but we’re going to try to avoid the Strawman trope.²

Etc

Doubtless there will be other angles showing up as time passes. We’ll see.