Technical tasks

How would you feel about an emergent architecture, where each Product Backlog Item adds/ modifies just the parts of the architecture that are needed at that moment?

I second Simon's remark. Look at it this way; let's say I want to drive a sunny destination, starting in Amsterdam. Now, at the beginning of the journey, I decide that it's going to be to Madrid. I pave the entire road (being your architecture), but 20% into my journey, I see that maybe Rome would be a better fitting destination. Because the entire architecture has been decided and layed out, I have very limited options:

- Continu to Madrid and have an end result that does not fit my needs anymore

- Stay where I am currently

- Drive back to Amsterdam

- Break down the entire road and reconstruct it

The idea behind emergent architecture is to prevent these kind of scenarios. See where you want to go at this point in time and construct the road you need to move forward, fitting the current conditions (this is very much nutshell work, but I'm guessing you catch my drift). The provides a lot more agility and ability to inspect the current situation and adapt the road forward when needed. 

Hope this helps.

Thank you both for your responses. Let me see if I understand correctly. As an example, let's say we're dealing with an inventory system. The first part of that could include stories for parts. The development team would then review the stories and start adding their sub tasks to those stories for getting the work done. These sub tasks would involve setting up the data access layer, the UI, the services layer, etc. They'd only focus on the pieces that would make it possible to manage parts for an inventory, but part of that requires them to build all the areas that would be required.

Later on, more stories are added and they build upon and/or refactor what's there to achieve the new goals. Is that about the just of it?

From my perspective, you have caught on to what @Simon Mayer and @Sander Dur are suggesting.  I've had this conversation with a number of managers of development teams and product architects.  The way I have the most luck with explaining is by asking two questions.

How many times have you seen code that has never been used but was put there in case it could be needed?

How many times have you seen a defect introduced because someone wrote code that suddenly traversed a code path that had never been used?

That is what happens when you try to build the infrastructure for something before you build the something.  Don't write code that isn't needed. It just complicates your code base and actually increases the risk of introducing bugs.  This goes back to the foundations of Lean.  Write code the you need, not code that might possibly be needed in the future if a series of specific events happen to occur. 

It's a bit hard to relate to your specific example, but I think you've understood.

Rather than use a technical example, I'm going to try it with a computer game:

Did you ever play Sim City?

You start with a completely blank map, and you have visions that one day you're going to have a metropolis with state-of-the-art infrastructure.

But in the beginning, you start small. You only need a basic water and electricity supply, so you get the simplest/cheapest option. You need basic facilities, low cost housing, and some businesses. Everything is minimal, and you watch that you don't spend too much in advance, as it's important to realize the value (have a functioning town, paying you taxes).

At some point, your city grows and you realize those early decisions you made to help a small town get up and running (small roads, and no public transport) just don't work for a mega city. So then you have to refactor. You might have to tear down large parts of your city to build a motorway or train line. Maybe those cheap polluting power plants you bought in the beginning are no longer sufficient. You now need best in class, and you're a position to invest in it, so you replace them.

In short, you build for your current needs. If you can defer decisions until more is known, or you can make decisions that are easy to reverse, it makes this approach even easier.

What you learn from releasing a useable product to the market could affect your decision about what future changes are needed to the architecture.

They'd only focus on the pieces that would make it possible to manage parts for an inventory, but part of that requires them to build all the areas that would be required.

As long as they are following the law of parsimony, and are building no more than is required, that is correct.

Later on, more stories are added and they build upon and/or refactor what's there to achieve the new goals. Is that about the just of it?

Rethink “later on”. One of the keys to mastering an emergent architecture is to refactor continually.