Tag: Software Architecture

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.

Doing Architecture with Agile Teams

Alan Gawthorpe & I a talk last month on doing architecture with agile teams:

We did the session agile-style: We had cards for our topics, and the 'customers' in the audience prioritised. I think it worked okay, it would probably go smoother doing it a second time. Some of the significant books & articles that went into the slides were:

Agile Methodologies for the Enterprise

* Scott Ambler & Mark Lines - Disciplined Agile Delivery
* Scott's whitepaper on Agile@Scale

What does a technical architecture for agile look like?

* Coplien & Bjørnvig, Lean Architecture for Agile Software Development
* Poppendieck & Poppendieck, Lean Software Development: An Agile Toolkit
* http://alistair.cockburn.us/Walking+skeleton

The further reading list

* George Fairbanks, Just Enough Software Architecture
* The UK government's national audit office report on Agile Governance
* http://www.disciplinedagiledelivery.com/
* http://en.wikipedia.org/wiki/OpenUP

Agile Adoption

If a team or organisation wants to adopt agile, should they do it all in one, or gradually? How do you overcome problems in agile adoption?

Agile Principles when Adopting Agile

Agile is not about process and methodology; it's about people, relationships and learning and so turns out to be very much democratic and consensus based. Effective adoption presupposes that you've got the team(s) on board; if you have to impose agile, you're probably doing it wrong. You can't adopt faster than your teams and individuals are motivated to adopt.

If you apply the agile manifesto to the project of 'adopt agile' then you'd adopt agile incrementally, of course. I suggest an obvious principle: You can't adopt faster than you can learn.

Agile's take on organisation & adjustment is that teams self-organise with regular reflection, which enables you to see what's not going well and consider ways to correct. There is no learning without feedback. Adopt incrementally with regular reflection and adjustment.

Agile teams puts work items in priority order, in to deliver the greatest business value first. Look at your current pain points – what's not working well – and find out which practices are found to address them. Prioritise changes which add most value.

Risk management is arguably a missing subject in agile, so let's add that here: soberly consider what, at this stage, you are capable of adopting successfully. First adopting practises you're capable of to maximise your chance of early success. The choice to deliver value or to attack risk first is a judgement call. When you're doing something new the risk of failure is high, so that judgement is largely about knowing how new to your team(s) the changes you're making really are.

Finally, agile starts with the vision of a wider community learning. Any fool can learn from their mistakes but the wise learn from others' mistakes too. In the past 10 years, others have already tried out all the mistakes for you. Call in someone in who's done it before.