Tag Archives: agile

A Manifesto for Post-Agile Software Development

— DRAFT —

In nearly 15 years since the Agile manifesto was penned, an entire generation of the software industry has grown up having known only ‘Agile’ methodologies. Their experience has not been entirely positive.

The ‘new’ criticisms made against agile – that is, by those who have grown up with it, not those who opposed it in the first place – are rarely criticisms of the agile manifesto. They are, often, reactions against the (abusive) experience of being pushed into processes, behaviours & relationships which are unsatisfactory; whilst at the same being stripped of any power to improve them.

We should always react against people being pushed about, and made powerless.

A manifesto is a small thing. It can fall on deaf ears. It can be interpreted to mean the opposite of what was intended, it can be misused to manipulate people. But if we make the effort to keep in touch with each other, and to keep trying to re-state what was meant, it can continue to be a valuable guide. And so I propose a 15th anniversary postscript.

Manifesto for Post-Agile Software Development: A Postscript

  • The agile manifesto was not and is not a prescription for people to impose conformity, nor a tool for controlling people.
  • There is a deeper theme to agile. At the core it is based on trust and respect, promoting workplace relationships which value people. We oppose methods, structures and behaviours which reduce respect and trust, and which reduce people to assets with no power.
  • Agile will always demand shared learning and shared improvement. Without critical reflection and learning – both from their own experiences and from the wider community – teams cannot remain agile. Without improvement based on that learning, ‘agile’ becomes fossilization.

Manifesto for Agile Software Development: A Reminder of the Original

The Agile Manifesto:

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

Comments

You may wonder why the term ‘post-agile’. It may be pointless, but it’s already in use, so we could choose to go along with those who want to learn, change and improve on their experience of ‘agile’.

As I see it, there are two essentials to agile: treating people well; and never stop learning. Each of these two is only truly possible when the other is also practised.

  • The phrase and much of the bullet point ‘There is a deeper theme…’ comes from About the Manifesto.
  • The emphasis on continuous learning is for some so obvious as to need no explanation. But some are stuck in a so-called "agile" process which they are powerless to change or improve. The irony of naming such an structure ‘Agile’ would be funny if it weren’t so painful.
    • Ron Jeffries’s reaction to criticisms of Scrum has been: "The essence of what makes Scrum work isn’t the three roles, the five meetings, the one artifact. It’s Inspect and Adapt. When things are not going as you like, you’re supposed to fix it."
    • To cry out that without continuous learning and change there is no agile, can be a powerful tool for the disempowered.
    • Calling for change in a broken process can become a step towards changing broken relationships.

Alternatives

The main alternative to a ‘post-agile’ slogan is surely Alastair Cockburn’s ‘Heart of Agile’.

A rather rushed and incomplete bibliography

Draft – Comment & Contribution Welcome.

Coplien & Bjørnvig : Lean Architecture For Agile Developers. A Review

Four years after this book came out, Agile Architecture has at last become a Thing. But as the nuance of its title hints, this book is not fad-driven. It is a carefully-thought out exposition of what architects can learn from lean and agile ideas, and what they can do better as a result.

Well. It’s partly that. If you are a practising architect, it is actually four must-read books in one.

If you are not, you might dismiss this book for two reasons. The first, that judging by other reviews & my own experience, the homespun style of the first half does not suit a bullet-pointed gimme-the-headlines-now generation. The second is that if you have not experienced the pitfalls of architecting and doing software in a real organisation with actual people in it, then Coplien & Bjørnvig’s pearls of wisdom may impress you much as the agile manifesto might impress a cattle rancher.

It is not a beginner’s book. It is the mature distillation of the sweat-soaked notebooks of a fellow-traveller who has stumbled over rocky terrain, been through the tarpits and has some hard-bloody-earned (and, academically researched) wisdom to share as a result.

I said four must-reads in one. They are:

1) The (literally) decades of experience of a leading practitioner & thinker in the field.

2) A thought-through answer to the questions, what can we learn from lean & agile. Whilst value-chains and some technique feature, the authors’ secret conviction is surely that Technology Is All About Human Beings. “Everybody, all together, from early on” is their Lean Secret. “Deferring interaction with stakeholders [users, the business, customers, domain experts, developers], or deferring decisions beyond the responsible moment slows progress, raises cost and increases frustration. A team acts like a team from the start.”

3) Which leads to that which for me, as a more techy-focused reader, was the marvel of the book. Clements et al in “Software Architecture in Practise” offered attribute-driven design, a partitioning of the system based on a priority ordering of, primarily, technical quality requirements. Coplien & Bjørnvig all but deduce a partitioning based on the priority ordering of people: Users first, Development team next.

“The end-users’ mental model” is the refrain on which they start early and never stop hammering. From this they suggest that the first partitioning is What the System Is from What the System Does. I am tempted to paraphrase as, Domain Model from Use Cases. But their point is partly that this also neatly matches the primary partition by rate of change, because the last thing to change in a business is, the business of the business. If you’re in retail, you might change what and how and where you sell, but your business is still Selling Stuff. And at lower levels inside the organisation too: an accounting department, though there has been five thousand years of technology change, still does accounting. The users know this. They understand their domain and if the fundamental form of your software system matches the end user mental model then it can survive–nay, enable!–change and stay fundamentally fit for purpose.

Second, don’t fight Conway’s law. “Organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations”. The deduction for agile teams is, partition so as to maximise the long-term autonomy of your self-organising teams. Even when the team divisions are imposed for non-technical reasons–geography, politics, whatever–still allow that fact to trump more ‘technical’ considerations. This may not match your vision of technical perfection, but it will still be the best way. Ruth Malan recently paraphrased Conway’s law as, “if the architecture of the system and the architecture of the organization are at odds, the architecture of the organization wins”. Don’t be a loser.

These points seem to me obvious in hindsight, yet they turn traditional approaches to high-level designs on their head. After considering People, yes we can considering rates of change, quality attributes, technology areas. But it’s always People First.

4) And finally. This is the first book-sized exposition of DCI architecture, which I would describe as an architectural pattern for systems that have users. Having separated What the System Is from What the System Does, DCI provides the design pattern for how What the System Does (the Use Cases) marshals the elements of the What the System Is. There are at least three notable outcomes.

Firstly that use cases are mapped closely to specific pieces of code; in the best case each use case can be encapsulated in its own component.

Secondly, that the relationship between Domain elements and Use Cases are expressed as “In Use Case X Domain element Y plays the Role of Z”. This brings significant clarity to both, and is part of the key to ‘componentising’ use cases; the Roles needed for a use case become, in the code, its public dependencies. In UML-speak, the Required Interfaces for such a UseCaseComponent are the roles needed to ‘play’ the use case, and those roles are Interfaces which are Implemented by Classes in the Domain Model. Coupling is reduced, cohesion is gained, clarity abounds.

Thirdly, the simpleness of the mapping from business architecture to code is greatly increased. Suddenly one can draw simple straight lines between corresponding elements of architecture and code.

The authors say of their work, “This book is about a Lean approach to domain architecture that lays a foundation for agile software change”. To my mind, this hits the agile architecture nail on the head. Agile software development always only ever succeeded at scale because the people doing it either knew, or had given to them, enough architecture to make it work. Software Agility, just like every other software Ility, must either be supported by the architecture or it ain’t gonna happen.

But the best thing I got from this book was the proof, before my very eyes, that correct technical design flows from knowing how to put the human beings central.

Where to Buy

UK



ebay (UK): Lean Architecture for Agile Software Development


Amazon (UK): Lean Architecture for Agile Software Development

USA



Amazon (USA): Lean Architecture for Agile Software Development

Estimates and NoEstimates

We had a debate&discussion at XP-Man on NoEstimates for which I did some notes. Reading the NoEstimates stuff, I was most attracted to the sense of “Let’s not be satisfied with second rate” and of a thirst for continuous improvement.
I was left with the sense (possibly because I already believed it) that there are contexts in which NoEstimates works, and contexts in which it doesn’t. But I was very glad to be provoked to ask in each case, “What value if any is our estimate/planning effort adding?” and “Isn’t there a better way to deliver that value?”

What is an Estimate?

An estimate for a Project is (1) a list of things to work on; (2) a cost-range for those things; and (3) a list of risks, that is (3a) of Dependencies that 1&2 rely on, and (3b) of things that might cause significant change.

An estimate or plan for a sprint is (1) a list of things to work on, (2) a “cost” (eg story points) for those things and (3) a list of things we are uncertain about, or (4) need to get help with.

The value of a project estimate is to feed-in to (1) A go/no-go decision and (2) seeing things we want to see sooner rather than later (e.g. should we hire more people, do we need help from specific 3rd parties, is releasing in time for Christmas possible)

The value of a sprint estimate is, to see things we need to ask for in advance (ie external help or resources); to give everyone a sense of confidence about what we’re doing; to fail-faster, that is to see sooner what we can’t achieve.

Just Enough Design Upfront? How to draw the line between enough and too much

Earlier this year the term Hayim Makabee proposed the term ‘Adaptable Design Up Front’ as a way of pointing the way forwards between the Scylla of BDUF and the Charybdis of degenerating into a Ball of Mud.

Others have used the term ‘Just Enough Design Up Front.’ But what counts as just enough?

That’s the wrong question. Because ‘just enough’ is an insight that misdirects you. Design is not a scalar quantity like length. There is no amount of up-front design that is the right amount. The question is, what are the useful bits of design to do up front?

And this is what ‘Adaptable Design Up Front’ addresses. What you must do up-front is support the change and development to come — usually growth or change in functionality — whilst nailing down the things that ought to be fixed: the invariants which give stability so that developers don’t have to re-learn the system from scratch each day they come into work.

So the basic idea is this: you want just the up-front design that helps you to draw lines between things that will change frequently and things that remain stable over time.

So how to do it?

For the 3 minute kick-start, Hayim has an excellent set of slides to get you going. His ‘architecture vs interior design’ analogy and the idea of applying the open/closed principle at the architecture level hit that ‘brilliantly simple’ spot that make it all seem obvious in hindsight.

ADUF – Adaptable Design Up Front –Hayim Makabee

For more detail on designing for what changes vs. what stays stable, I seriously recommend Jim Coplien & Gertrud Bjørnvig’s under-rated book Lean Architecture: for Agile Software Development which contains decades of hard thought and wisdom. They know the pitfalls on the way first-hand and they can help you navigate them. More important, they show how to prioritise the human factors in your technical architecture. Which, as every architect knows, is what really matters.