Emergent Design/Architecture – Techniques to help emerge design/architecture

I really struggled online to find a clear definition of what Emergent Design/Architecture is, other than a couple of definitions and what one of the principles behind the Agile Manifesto says

The best architectures, requirements, and designs emerge from self-organizing teams. – Principles behind the Agile

I’m not one to reference Wikipedia much but it also gave me this;

Emergent Design is a phrase coined by David Cavallo to describe a theoretical framework for the implementation of systemic change in education and learning environments. This examines how choice of design methodology contributes to the success or failure of education reforms

Key words that drew me to this definition are “Systemic Change” and “Learning environments” – We’ll revisit these words later.

My definition of Emergent Design/Architecture without stating the obvious is that it is the process of producing deliverables without defining the design or architecture upfront and allow the design/architecture to materialise over time in order to be able to respond to systemic change quicker in a learning environment with little to no impact. Oh wait, have I just stated the obvious?

Most organisations struggle with the practice of emergent design in an Agile environment because they are so used to designing everything up-front. They have individuals in roles solely responsible for designing before teams implement that design. Or they try to be Agile and put the individuals in Agile teams and call them Agile and still struggle to deliver anything because they are still designing up front.

This, like any other way of working to deliver great software to paying customers and provide the level of customer value and satisfaction needed is a mindset change. Oh oooh! There it is again – mindset.

Without turning this article into one just about mindset, I’ll quickly state that for this to work in teams, the organisation needs to buy into it, and provide the environment to foster this behaviour; culture, self-organising/managing teams, cross-functional teams etc. Software development is a learning environment. Actually, scratch that! Everything is a learning environment!

Back to the main focus of this article. I would like to share some ideas/techniques to help teams struggling to get into emergent design/architecture or hopefully help teams who have completely not accepted or never done it.

Note: These techniques all deserve a full post in isolation so I will only cover what’s important about the technique and how it helps teams and organisations practice emergent design

User Story Mapping

Story mapping is the technique of mapping user’s journey through your product development in the form of user stories on a walls, charts, windows (anything big enough to radiate that information) visible for all to see, to interact with and evolve.

With story mapping, teams can visualise the customer journey and when releases are scheduled so the design/architecture can evolve around that. Incremental deliveries now becomes a bit easier for the technical minded to know how to structure code to accommodate for what’s coming next. – This is a learning environment so be prepared for change!

Visualising work and customer needs and evolving your design this way enables you to reduce waste in over-engineering design/architecture upfront and you can easily adapt your design when direction or priority changes with little to no impact on your design.

Prioritised Backlog

Going back to the basics and using what is most often taken for granted by Agile teams when it comes to practicing emergent design – a prioritised backlog.

A prioritised backlog is what the customer wants done in priority order. – Simple right? Yes, but most teams struggle with backlogs and thereby lack vision and direction. This leads to design/architectural murkiness and hence the tendency to create a “catch-all design/architecture”.

Get your backlog sorted and prioritised with your users and team. The team will then be able to visualise what’s coming and evolve the design/architecture as they go through their iterations. – Learning environment so be prepared for change.

Product Roadmap

In Agile environment, your roadmap is effectively your story mapping or prioritised backlog (discussed above) with necessary milestones incorporated to measure success based on your customer feedback. Or something specific like this below by Roman Pichler.

Again, this helps give the team and organisation vision, direction and clarity of what is being delivered and when. The team can then evolve their design/architecture as they meet the forecasts (commitments if you prefer this word better). Teams can adapt to any changing requirements after each iteration without having to do all the design/architecture up front. – Learning environment so be prepared for change.

Refactoring

Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure. — Martin Fowler in Refactoring Improving The Design Of Existing Code.

Another definition I like is by Version One and they say refactoring is;

the process of clarifying and simplifying the design of existing code, without changing its behaviour.

Refactoring code plays a crucial part in emerging architecture and to be able to have the mindset to respond to change architecturally. Coaches need to help teams understand this concept and not just from the angle of refactoring makes our code better. Yes it does but most importantly, it positions us to be able to respond better to our customers and market demands.

Refactoring goes hand in hand with our next topic of techniques to emerge architecture and that is using mocks, stubs, dummies, spies and fakes.

Test Doubles – Dummy, Stubs, Mocks, Spies and Fakes

I am not going to pretend I know how to implement all these test doubles or what they truly mean behind the scene. To my simple mind, they all mean, put “something there” to be able to reach end to end and come back at a later date to fully implement it.

I couldn’t find any images on Test Double Spies so I figured they are doing a pretty great job as spies otherwise I’ll be worried 🙂 – sorry for my dry sense of humour!

I’ll close Refactoring and Test Doubles with a principle;

Continuous attention to technical excellence and good design enhances agility. – Principles behind the Agile Manifesto.

The “Fluffy” stuff

I hear this term a lot; “fluffy stuff”! This is basically anything to do with mindset, culture, behaviours, relationships etc. The intrinsic values that drives Agility and the most difficult things to be able to do to help individuals, teams and organisations understand the benefits and allowing them to make the decision to accept whether that new way of working is better for them or not. I did not want to run the risk of turning heads away by starting the post with these but don’t underestimate the absolute importance of these as the bedrock for the techniques mentioned above to thrive and flourish.

Back to my earlier paragraph when I said we’ll cover “Systemic Change” and “Learning Environments” later in the post, well here we go.

This is just as difficult to achieve as any other Agile practice or framework because it is all about mindset as much as it is about techniques and technical know-how!

You need buy in from management, product management team/department (if you have one), DevOps team. In simple terms, it’s across organisation. You can’t expect your Agile teams practicing this without alignment across organisation. If you are doing this without alignment I would like to hear about it because I’d suspect you are achieving it with some serious cost. And by cost, I’m not only referring to monetary cost. By cost I’m also referring to the overhead of barriers and push backs internally to the organisation, long working hours to provide endless support headaches when software is released. These are only a few other non-monetary costs but these are costs that inversely have much longer detrimental consequences but yet often fall down the way side as “organisational culture problems”.

Remember, every environment is a learning environment so inspect and adapt.

Back to the “fluffy stuff” which will help act as meat to the bone of emergent design in your organisation;

Vision

The lack of organisational Vision in any organisation causes teams to feel missing and directionless. There are two types of vision; personal and organisational. I’m referring to organisational vision in this post. A well-defined organisational vision will tie strongly to things like Product Roadmap which will in turn reflect into Story Mapping walls and end up into Prioritised Backlogs. You will have teams aligned to the organisation and once nurtured, teams can start thinking about evolving architecture and design because they can see the direction of the organisation and the customers.

One appropriate manifesto principle here;

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. – Principles behind the Agile Manifesto.

This principle leads us nicely into the next set of “fluffy stuff” – Autonomy, Mastery and Purpose!

Autonomy

Allow the team the level of autonomy needed to be able to make design/architectural decisions so they are not bottle-necked by a team or someone outside of the team. This will empower them to continually evolve your architecture/design and take ownership to build the product right.

Mastery

Equip your teams with all the skills needed to be the best at what they do. Spend on training, coaching, mentoring etc and maybe even a 1hr hackathon for everyone every Friday afternoons which equates to half day hackathons each month.

Purpose

Oxford dictionary defines Purpose as; “noun. The reason for which something is done or created or for which something exists.”

With a sense of belonging and alignment of individuals’ personal purpose and organisational purpose, you will have very motivated teams driven to think differently to deliver whatever is in-front of them.

One might say, how does Autonomy, Mastery and Purpose contribute to emergent architecture/design? My answer is Mindset and Motivation!

Conclusion

In conclusion, remember Emergent design is just about mindset shift as any other Agile technique to deliver great software. Help your teams and organisations to understand emergent design/architecture without forcing it onto them. Coach, train, mentor and equip then support the teams implement what works best for them.

Story mapping, prioritised backlogs, product roadmap, refactoring, test doubles and visions are all very closely linked to enable an organisation and teams to embrace and practice emergent architecture/design. A very good post written by Mike Cohn on emergent design can also be read here.

Autonomy, Mastery and Purpose are the hidden connections to dot the lines in my opinion.

I will like to hear your thoughts on this. Please comment below.