If TOGAF Could Be Agile …
… we could pick any concept from TOGAF, and try to think how it relates to agile.
And, vice versa: we could take any concept from agile, and try to think how it relates to TOGAF.
Sounds like a “mapping” exercise, doesn’t it?
What Would Be The Minimum Viable Product for Enterprise Architecture?
Just for argument’s sake, and just to start somewhere, let’s start with the agile concept of minimum viable product.
Let’s use Eric Ries’ definition of MVP:
“Minimum Viable Product is that version of a new product which allows a team to collect the maximum amount of validated learning about customers — with the least effort.”
So we want to deliver some initial enterprise architecture benefit that allows us to achieve the greatest discovery of what our stakeholders really want from enterprise architecture — rather than the architects picking some enterprise architecture output or process because that’s what they think the customer needs. Architecture is not about what the architects want, is it? It’s about finding what will deliver the greatest benefit to the business.
For anyone who remembers TOGAF, this approach probably makes you think about TOGAF’s “Preliminary Phase”.
And, in this example, I’m not talking about using enterprise architecture or agile to design or realise a digital business solution. Solutions come later. First, we have to design architecture, then we can use it.
Let me summarise the hypothetical for you:
“If we want to set up an enterprise architecture capability for the entire organisation — from scratch — and we wanted to do that using an agile approach, what would be our initial minimum viable product (MVP) for an enterprise architecture capability? What would that MVP have in it — what would it leave out in the first iteration?”
High Velocity!
Whatever it would be, it would have to be something that could be delivered quickly. Because that’s agile, right? I’m thinking “quickly” means days or weeks. Not months and years. And if it’s “weeks”, it’s no more than four weeks, and we’re getting through two or three high-velocity iterations in that time.
Who?
And — if we’re going to relate our thinking back to TOGAF — we’d need to be taking full account of the “concerns of the stakeholders”. Whatever those concerns may be. And whomever the stakeholders are.
What Would You Do?
I know what I’d do first. And I think I know how I would “iterate” through multiple subsequent “Program Increments” to build a more fully functional enterprise architecture capability over time.
But what would other people do as an MVP for enterprise architecture?
Would your MVP for enterprise architecture be only one single deliverable output? Or would it be several things, all of which would have to be limited in depth and scope?
But Not That Bit …
Alternatively, if we think of something in either TOGAF or agile that has no relevance at all to anything in the other method — we would have to say:
“Umm, yeah. You know, this thing here? It doesn’t really relate to anything in the other method, in any way, shape, or form. So let’s forget about that.”
- Is there anything in TOGAF that sits entirely outside agile thinking?
- Is there anything in agile that sits entirely outside anything in TOGAF?
Or … TOGAF and Agile Inhabit Different Layers!
Maybe TOGAF in it’s entirety exists at a level above “agile”. And agile practices are a lower-level extension or specialisation of TOGAF? Agile projects may use TOGAF outputs, but TOGAF and agile are fundamentally two different things. And the best we could say is that they “are complementary” and there is no overlap between them.
Or … Let’s Get Rid of TOGAF Altogether! We Don’t Need It! We’re Using Agile!
… which — seriously — is what some organisations are saying these days.
“We only need one method. TOGAF is a heavy-weight waterfall method. Agile is all we need. Forget TOGAF!”
Not sure about that one. Actually, I am sure about it. I think it’s lame.
