Agile 8 – Some commentary on SAFe

https://bit.ly/2AOaUBm

Copyright Graham Berrisford. One of several hundred papers at http://avancier.website. Last updated 04/04/2019 17:37

Avancier’s agile papers

This is a supplement to a series of mostly short papers.

It is assumed here you have read paper 6.

1.      On the beginnings of agile

2.      On agile software development

3.      On agile businesses and systems

4.      On systems thinking ideas used in agile

5.      What is agile architecture?

6.      EA in the world of agile architecture

 

This paper is a commentary on some of the ideas in SAFe.

“Thanks! You article contains some really good reflections on the difference between developing with agile methods and designing solutions to be agile.”

The Scaled Architecture Framework (SAFe)

The authors of SAFe have produced a lot of material, with various lists of concepts, ideas, principles and practices.

How far is SAFe scalable above software architecture?

Is it about the abstract architecture of a system, or the system itself?

And is it a coherent framework or a collection of sometimes conflicting ideas?

 

To begin, the authors define agile architecture thus:

·         “Agile Architecture is a set of values and practices

·         that support the active evolution of the design and architecture of a system

·         while implementing new system capabilities.”

Core concepts or principles

https://www.scaledagileframework.com/safe-lean-agile-principles/

SAFe practices are based on nine concepts that have evolved from Agile principles and methods, Lean product development, systems thinking, and observation of successful enterprises.

#1 – Take an economic view

The means making decisions are made in a proper economic context, wrt value, cost and timeliness

#2 – Apply systems thinking

This is ambiguous since there are two very different kinds of systems thinking.

General system theory and cybernetics applies to the systems under design and development.

Social systems thinking applies to the teams who design and develop systems.

#3 – Assume variability; preserve options

The means maintaining multiple requirements and design options as long as possible; commit as late as possible.

#4 – Build incrementally with fast, integrated learning cycles

The means each iteration results in an integrated increment of a working system.

Subsequent iterations build on the previous ones.

Increments allow fast customer feedback and risk mitigation.

They also may become minimum viable products (MVPs) or prototypes for market testing and validation.

In addition, these early, fast feedback points help determine when to ‘pivot,’ where necessary, to an alternate course of action.

#5 – Base milestones on objective evaluation of working systems

In Lean-Agile development, integration points provide objective milestones at which to evaluate the solution frequently and throughout the development life cycle.

There is regular evaluation of financial, technical, and fitness-for-purpose measures needed to assure that a continuing investment will produce a commensurate return.

#6 – Visualize and limit WIP, reduce batch sizes, and manage queue lengths

Lean enterprises strive to achieve a state of continuous flow, where new system capabilities move quickly and visibly from concept to cash.

The three techniques do three things: match demand to capacity, enable fast completion, and minimise wait times.

#7 – Apply cadence, synchronize with cross-domain planning

Cadence creates predictability and provides a rhythm for development.

Synchronization causes multiple perspectives to be understood, resolved, and integrated at the same time.

Applying development cadence and synchronization, coupled with periodic cross-domain planning, provides the tools needed to operate effectively in the presence of uncertainty, inherent in product development.

#8 – Unlock the intrinsic motivation of knowledge workers

Lean-Agile leaders understand that ideation, innovation, and the engagement of knowledge workers can’t generally be motivated by individual incentive compensation.

#9 – Decentralize decision-making

Achieving fast value delivery requires fast, decentralized decision-making.

However, some decisions are strategic, global, and have economies of scale that justify centralized decision-making.

Since both types of decisions occur, creating a reliable decision-making framework is needed.

Other  ideas

Other core ideas are listed in this sentence:

“The Agile Architecture principles support Lean-Agile development through

·         collaboration,

·         emergent design,

·         intentional architecture,

·         design simplicity, as well as

·         designing for testability, deployability and releasability.”

Collaboration

Let us take collaboration between architects, developers and others for granted.

Emergent design

Intentional design would mean designing a system ahead of development.

Emergent design means that the design of a system emerges from incremental development.

Intentional architecture

Intentional architecture implies some up-front, high-level, design documentation.

Explicit articulation of higher-level architecture(s) is the basis of all enterprise and solution architecture frameworks (including TOGAF of course).

For sure, at least some architectural oversight of agile system development is desirable.

And people ought to optimise the balance between that and emergent design, depending on various factors.

 

Where does agility enter the picture?

Remember agile mean “willing and able to speedily respond to change”.

Intentional agile architecture implies:

·         Documenting an architecture that can be readily changed and/or

·         Designing a system that can be readily changed – an agile system.

 

The first might be achieved by minimising the architectural documentation, keeping it lean.

The second might be achieved by generalising the architecture, keeping it abstract and/or designing for flexibility.

These are two different ideas.

You may know that agile development favours the Keep it Simple (KISS) principle.

You may not know there is a fundamental design trade off.

Designing a system for flexibility usually makes it more complex, and run slower.

Design simplicity

Does this mean minimising the design documentation, or minimising the code written?

Or minimising the number of locations, components, messages, network hops, processes, databases?

Or minimising the size or length of components, messages, network hops, processes, databases?

There are many trade offs between these qualities.

And none of those design strategies necessarily results in an agile system.

 

In an article promoting Agile Architecture, a CTO is quoted as saying the following.

“The only way to manage a large distributed system is to keep things as simple as possible.”

OK, but isn’t that precisely because the "architecture" of large distributed systems is inherently complex?

If you want a simpler system, don’t distribute it!

As you may know, Fowler’s first law of distributed objects is: “Don’t distribute your objects”.

 

“Keep things simple by making sure there are no hidden requirements in the design.”

What are hidden requirements as opposed to visible ones?

You may know that agile development favours the You Ain’t Gonna Need It (YAGNI) principle.

The idea is not to anticipate future requirements, and to refactor when it becomes necessary.

But architecting an agile system does mean including features in the design that anticipate future requirements.

And a system cannot be agile in every possible way, it has to be designed with specific kinds of change in mind.

 

[And no] hidden dependencies in the design.”

What are hidden dependencies as opposed to visible ones?

We can make all dependencies visible in architectural documentation

OK, but that implies a heavy non-agile documentation overhead.

We can all remove synchronous interactions between distributed components,

OK, but that increases the complexity of maintaining data integrity dependencies and compensating transactions.

Read our Microservices paper for some decoupling trade offs.

 

“Cut technology to the minimum you need to solve the problem you have.”

It certainly seems a good idea not to use technologies you don’t need.

But what does this actually mean in an enterprise application design context?

Use thin clients with no application code on client devices?

Don’t use middleware when you can use REST?

Many enterprise architects promote middleware use.

Read Smart endpoints and dumb pipes for discussion of the synchronous v asynchronous trade off.

 

“It doesn’t help the company to create artificial and unneeded layers of complexity.”

OK, but nobody does this deliberately unless they are trying to design for maintainability.

And if asked, many sponsors will say they do want an agile (flexible, configurable) system.

To achieve this, you’ll have to make the system more complex than is needed in the short term.

Designing for testability, deployability and releasability

For sure, test-driven design is an agile development principle.

Tests are built as “executable specification”.

But there is a trade off, since the more test cases you build, the harder it is to change the test cases.

And therefore, the longer it takes to test and release a new system.

Some other principles

Other papers on SAFe include six or seven principles – depending on which you read.

Some are variations on agile development principles of the kind above.

Three of the more architectural principles are discussed below.

#2 The Bigger the System, the Longer the Runway

This means having enough (say 3 to 9 month) infrastructure to complete near-term product backlog without refactoring.

What is infrastructure? The term covers many things.

It can include client devices, server devices, operating systems, database management systems, middleware, data storage etc.

To a software engineer, it includes what they use by way of a database schema and module libraries (class libraries, DLLs...).

 

The trouble is, 6 months is a rolling future, and 1 month from now, the 6 month future will be different.

So, surely maintaining the runway to anticipate the 6 month ahead implies continual refactoring?

#3 Build the Simplest Architecture That Can Possibly Work

What does this mean?

If it means building the simplest system that can possibly work – that is already agile development principle.

But building the simplest possible system tends to inhibit its flexibility and configurability.

If it means building the simplest architecture – that implies documenting a simple high level design.

One can always abstract to a high level design that is simple and relatively stable – but also vacuous – which doesn’t sound helpful

And it is far from clear that decoupling subsystems (as in Microservices) is well described as the simplest architecture.

 

How to simplify both the design and the communication between the teams.”

The proposal in SAFe is: “Domain-driven design, design patterns, and applying a system metaphor”

 

First, remember that “If you can’t draw it, it isn’t a pattern” Christopher Alexander.

Some articles on SAFe equate principles or standards with patterns.

But design patterns are not standards, and they often come in pairs.

What architects need is guidance on the trade-offs between patterns.

 

Wrt design patterns in general

Following design patterns tends to complexify rather than simplify.

Many common design patterns are designed to make a system more flexible by decoupling communicating parties

But, by adding a level of indirection, and perhaps allowing temporary disintegrity, they make a system more complex.

Generally, making a system more agile tends not only to make the architecture more complex, but to make the system slower as well.

 

Wrt domain-driven design in particular...

In 2002, Martin Fowler observed that Domain-Driven Design is difficult to learn and best reserved for complex systems with “rich domain models”.

And in January 2017, Wikipedia said: “Microsoft recommends that [domain-driven design] be applied only to complex domains.”

(Where I guess rich implies substantial use of inheritance.)

 

In the 1980s. the UK government’s structured design method (SSADM) had transformed an object-based domain model into event-oriented procedures.

Fowler wrote that event-oriented “Transaction Scripts” are simpler for many enterprise applications.

Both sources presumed reuse would be achieved by delegation to subroutines from event procedures or transaction scripts.

 

Read Domain-Driven Design, Transaction Script and Smart UI for discussion of the simple v complex trade off.

It seems likely that many if not most enterprise applications are more easily designed and maintained using Transaction Script or Smart UI patterns.

You simply factor out data object-based modules where data-centric rules are invoked from several transactions or screens.

Transaction scripts can equally well publish events (for others to consume) and log events (for subsequent query and replay).

 

Wrt a system metaphor...

A good system metaphor helps to facilitate communication.

Use this link to find a good discussion of the idea https://en.wikibooks.org/wiki/Software_Engineering_with_an_Agile_Development_Framework/Iteration_One/System_metaphor

Note that the metaphor for an agile system has to be generalised, which can weaken the clout of the metaphor.

 

And beware, of course, that metaphors can be misleading.

Analogies with the architecture of concrete buildings, airplanes and city plans have misled many about the nature of enterprise, solution and software architecture.

You may look at the architectures of buildings (in run-time reality) and at architectural drawings of them (in design-time descriptions).

You can see immediately (visually) whether the run-time reality resembles design-time description – or not.

By contrast you cannot look at the run-time reality of a software system.

You can see only a user interface that reveals nothing of the software architecture.

Enterprise and solution architects rarely look at the executable design-time description.

And looking at the code of a software system can be of little or no help anyway.

Instead, architects document a much more abstract design-time description using natural language and graphical models.

They then govern software development for compliance of the code to the intent of that documentation – rather than to its visual form.

#6 There Is No Monopoly on Innovation

OK, but how does this help us produce an agile architecture?

Surely here, to be agile means being able in mid-course software development to adopt an innovation with relative ease.

However useful an innovation might prove to be, adopting it is a departure from incremental development.

Until the innovation is understood, we don’t know how to anticipate it.

Until the innovation is on the road map, we don’t know we need to anticipate it.

And at that point, adopting the innovation is likely to incur the time and cost of substantially re-architecting or re-enginering the system.

So, in what sense does researching innovations enable “Agile Architecture”?

 

To the mirage of agile architecture we should add the mirage that after a series of YAGNI and KISS increments, substantial refactoring to resolve a major problem or introduce a major innovation can readily be accommodated without major time and cost implications.

Concluding remarks

SAFe includes a lot more than above

It includes other management-oriented ideas such as "lean portfolio management" and "flexible budgets”.

 

 

All free-to-read materials at http://avancier.website are paid for out of income from Avancier’s training courses and methods licences.

If you find the web site helpful, please spread the word and link to avancier.website in whichever social media you use.