Emergent Design/Architecture - Techniques to help emerge design/architecture by Kwasi Owusu-Asomaning

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.

   Image reference  -  User Story Mapping: our choice as feature listing method

Image referenceUser Story Mapping: our choice as feature listing method

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.

  Image reference  - Good Product Backlog Characteristics

Image reference - Good Product Backlog Characteristics

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.

  Image reference  - The GO product roadmap - an Agile product management tool

Image reference - The GO product roadmap - an Agile product management tool

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.

A very good article about refactoring and why it’s imperative in constantly changing environments by Mishkin Berteig can be found here. I strongly recommend reading this.

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.

 Image reference - Test Doubles – Fakes, Mocks and Stubs.

Image reference - Test Doubles – Fakes, Mocks and Stubs.

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.

Agility is Everywhere by Kwasi Owusu-Asomaning

I have had this article written for a while and haven’t gone round to publishing it so I thought, better late than never. I have also not changed my language and thoughts from 2016 and I can see how I would have re-written this article differently but I'll leave this as is, as I track my own improvement and experience.

To compensate for how late this article is to publish, picture yourself sat in your cozy sofa at home on your tablet or PC and it is 7th of January 2016…Here goes.


It was early January 2016 and I was sat listening to a sermon on New Year resolutions. I realised how familiar it all sounded and it got me thinking. New Year resolutions, aren’t these essentially retrospective actions from the previous year? How we lived the year and how we could have done better to improve ourselves. This got me thinking; is Agility actually all around us? Is the mind-set of continuous delivery and improvement happening without people paying too much attention to it? I believe the answer is yes! This stuff we call Agility is everywhere! 

Take an example of doing the laundry. To me this is a tedious chore and so my tendency is to leave the laundry basket overflowing – this has now become my Product Backlog - un-prioritised, un-sorted (whites, darks, easy-bleed colours etc). One Saturday morning, after a verbal kicking from my significant half, I decide to prioritise and do my whites first because I need a shirt for Monday morning. Take this as my sprint backlog, I am committing to doing all that is necessary to have a white shirt fully laundered by Monday.

So I take the dirty clothes into the sprint – putting them into the washing machine, adding softener and all manner of soaps I trust will make my clothes clean and smell scrumptious. We can call this my sprint cycle of 2 hours and 30 minutes wash and tumble dry. Within this period there is the occasional check to see if washing is done or anything has gone wrong with the wash etc. Call this my stand-ups. When this cycle is finished, I have potentially wearable whites and have delivered on my commitments/forecasts to have them ready for Monday. I can then show off to my significant half that I have done the laundry and I haven’t turned all the whites into flamingo pink shirts – call that my sprint review and celebrating success. Closing the loop I will most likely be answering questions from my partner as to which soap I used? How much load did I put in? Couldn’t I have added more? Or did you really put all that load into the machine? And I would have agreed with her and learnt from it. Call that “The wife-retrospective ceremony”.

 Image reference

Image reference

Another illustration we can use is cooking. Take for example making a spaghetti Bolognese – call that your Product Vision. You wouldn’t put all your ingredients including the spaghetti into one bowl and expect a deliciously made meal now would you?

You’ll make the Bolognese sauce – Iteration 1. Taste it and add more salt and other tweaks to make it your own. Whilst doing that, hot water will be heating to make the spaghetti – Iteration 2. The water boils, you add spaghetti and allow to cook. Then drain the spaghetti from the water – Iteration 3.

It all comes together when you combine the sauce and the pasta to produce your Product Vision – in this case Spaghetti Bolognese. We can argue about my cooking skills later. This dictates some degree of Kanban to me; Visualise the work – spaghetti Bolognese as end goal with all ingredients laid out on work surface. Limit Work in progress – Bolognese sauce first, spaghetti next. Focus on Flow – depends on how hungry you are and how quick you want it ready. If you are like me, you probably have everything on high heat and burn it all. Finally, Continuous Improvement – tasting as you go along, adding seasoning to make it better, checking spaghetti to make it al dente if that is the customer’s requirement. There is an argument for having multiple hobs to cook items simultaneously but you get the drift.

 Image reference

Image reference

The point I am making is that Agility is everywhere and the different frameworks under the Agile umbrella are used in different environments and you choose it based on the value add that needs to be delivered.

Scrum is by far the most popular of the Agile frameworks and widely practised. Agile ideals are more of a common sense approach to the old 20th century methods of working that was non-collaborative and non-engaging. Nowadays we see a vast need for cognitive ability to produce anything innovative and of value to customers. One approach is to adopt Agile values and principles. I am a true believer in the Stacey Matrix and in knowing what framework to use for your domain and requirements.

As a coach and trainer, my aim is to continually serve my teams, individuals and organisations, teach, learn, lead by example and take pride in helping them reach their potential.

Agile accelerates product delivery, improves collaboration between teams and with customers (both internal and external) and employee motivation. It increases productivity because the team is engaged and involved sprint to sprint. There is a sense of purpose and being part of a bigger thing. Customers and organisations become confident of delivery. Agile concepts allow the team and the organization to respond effectively to customer and industry priority changes. The beauty of continuous improvement in an Agile environment is identifying opportunities to streamline work and reduce waste, ultimately delivering value to our customers faster without compromising quality.

Remember when you had a really liked someone special to you, flirted a lot, had wonderful times together, then you both agreed to call it a ‘relationship’. Most often when it begins to become a ‘thing’ you start to make extra effort. The human mind is a wonderful thing. As soon as we put a name to something, we begin to over think it. We over complicate it and in doing so make this simple, common sense thing of Agility a very difficult thing to achieve.

Agile transformation is about a mind-set paradigm shift. A completely different way of thinking. The processes and ceremonies around any Agile framework are just enablers.

This is just my day to day observations of how Agility is all around us without people realising. Next time you are on the chores, politely asked by the wife or girlfriend, think how you may be invoking your inner Agile mindset without even realising it.

A Retrospective Idea - Formula 1 Pit Stop by Kwasi Owusu-Asomaning

Edited image reference: Car and Driver

Excitement has set in for Formula One fans around the globe with the 2017/18 championship kicking off over the weekend and as an avid F1 fan myself, I am excited too.

So much so that I had developed a retrospective game around the sport a while back and I'll like to share it with you. In case you might find it valuable.

The key part of Formula One this retro idea leverages is the Pit Stop; One of the most effective, efficient and highly collaborative teamwork display you will ever see.

When we talk about the ultimate team, a Formula One Pit Stop crew is second to none. If you think of an F1 car stopping and changing all 4 tires to put it back out on the road, takes the best part of 2 seconds. It takes some serious teamwork and synchronisation to achieve this.

For those who don't follow or understand the F1 sport, here are few links to a mini preamble for you.

Formula 1 Preamble

Overview of the retro:

This retrospective format uses the structure of facilitating great retrospectives laid out by Esther Derby, Diana Larsen & Ken Schwaber in their Agile Retrospectives: Making Good Teams Great book.

The retro covers the Set the Stage, Gather Data, Generate Insights, Decide What to Do and Close the Retrospective structure but the focus of two stages of the structure are not in the order advised by Esther and Diana. This is not because Esther and Diana’s structure is not effective. On the the contrary. I experimented here to get targeted and early focus on discussions when identical items start to appear throughout the Gather Data stage. As Agile teams focus on moving quick feedback loop through early discovery, I thought to introduce this slight tweak to Esther and Diana’s structure. What will this give you? Quick feedback loop on any identical items is instantly acquired as the team holds discussions and identify potential actions out of these items. It is human nature to start problem solving when a problem presents itself. By talking through it right there and then without waiting for the end of the Gather Data stage time box, I feel you get an even richer, more meaningful, targeted discussion and potential action items to tackle. One might say “but the Gather Data stage is probably only time boxed to 20-30mins. Can you not wait?” Again, Esther and Diana’s structure is spot on but I’ve also found this permutation effective. Plus it gives a slight variation to the retro structure itself.

See diagram below

 

Timing:  

90 minutes (or adjust to the size of your team)

Materials:

  • Post its
  • Sharpies/whiteboard markers
  • Magic charts/whiteboards/wall charts

Instructions:

Make sure you have enough room for the team to have a whiteboard/magic chart to huddle around for pit stops.

Image reference: The Sam Barnes

If your team is distributed, you will have the added complexity of choosing a good collaboration tool that works for the team. I would recommend not experimenting this retro with a new collaboration tool because this is a retro fully facilitated by the team so everyone taking part is important.

  • Give the team a very quick context on Formula 1 (for the benefit of team members who don't follow it). Focus on the Pit Stop!
  • Team nominates a Team Principal. A Team Principal is the owner of prompting the team about potential action points to be noted for later discussion. She/he is also responsible for time boxing and helping the team focus the conversation without digressing.
  • Team nominates a Race Technical Director to call Pit Stop! when data generation identifies 2 or more identical groupings of data in the Gather Data stage.
  • Time box each of the stages below as appropriate for the team but for the Gather Data and Generate Insights, time box them together and give it a fairly large time box.

If the team is not mature enough, the Scrum Master can play the role of Team Principal and team members will observe for when they come to re-run this format again.

Running the Retro:

[Assumptions]: You've reviewed with the team last sprint retro actions taken into the sprint. Anything else you perform at the beginning of your retro including reiterating to the team the retro is not a blame exercise is done before kicking this off.

Set the Stage -

Start with setting the scene and introducing this retro and explaining the rules. Prepare a game to warm the team up and to disconnect them from work mode. [Team Principal activity]

Gather Data -

Team starts to discuss on how the sprint went and starts to add stickies to the whiteboard. Team with nominated Race Technical Director also keeping an eye on identical items in this data gathering phase. [Team activity]

Generate Insights -

As soon as there appears to be identical items raised by team members, Race Technical Director will call PIT STOP! When Pit Stop is called, the team will huddle round the post-it notes on the wall chart/whiteboard and discuss the identical grouped items to understand more i.e. how is this impacting the team (be it negative or positive)?. Discuss if there's a potential action item here. If there is a potential action, it doesn't mean you are to take it into the next sprint but you simply make a note of the actions which will then be prioritised by the team at the end of Retro (Decide What to Do stage). [Team activity]

Loop these two stages until time box is over. [Team Principal to keep an eye on time box]

Decide What to Do -

Team then huddles around the listed action items post-it notes and start prioritising the list and agree which one to take into the next sprint to work on to improve. Add the remaining actions not going into your sprint to be worked on to your team’s improvement backlog. [Team nudged by Team Principal as time box keeper]

Close the Retrospective -

End the retro with another game or something fun so the team ends on a high.

Just as I have adviced to end the retro on a high, let's cross the finish line in this article on a high. Here's a 'Director's cut video of the first race of the 2017/18 Championship in Melbourne. If you watch carefully, you'll see a bit of a pit stop in action.

 Formula1.com - Director's Cut: Australia 2017

Formula1.com - Director's Cut: Australia 2017

I was showed this video below by a coach and mentor of mine after this post went out and I really liked it so I wanted to share it for you all to enjoy. It shows the importance of optimising the System as a whole and not just a part of the system. If Pit stops were the only thing to have been optimised in F1 over the years, the sports (The whole System) will not be optimised as it is now. So remember to keep looking at the bigger picture and the system as a whole.

Observe how the art of the Pit Stop has evolved since 1950 Created by the channel CpatainCanuck. Footage used taken from https://www.youtube.com/watch?v=C0bg3ztLGfk and https://www.youtube.com/watch?v=aHSUp7msCIE Source Video used under the Fair Use Provision.

I hope this helps you mix up your retrospectives. I'll like to hear your feedback in the comments below. Please share any permutations you run also.

Back To Basics by Kwasi Owusu-Asomaning

I thought I'll launch my site with an article or two and I had a good conversation with a colleague of mine which inspired this article.

Question? What does the Agile manifesto say?

How many of you started responding to that question with any of the 4 values in the manifesto? i.e. "Individuals and Interactions..." etc etc etc
As opposed to the below from the manifesto.

"We are uncovering better ways of developing software by doing it and helping others do it." http://agilemanifesto.org/ 

That initial sentence in the manifesto runs through the very core of Agility and the mindset required when faced with either deciding to adopt Agile, coaching it, training it or if you already live and breath the dynamics of any of the practices under the Agile umbrella - Kaizen!

The need for continuous improvement and the fact that any organisation or team will go through phases of uncovering what Agility means to them is important. Their ShuHaRi! They will go through a phase of learning from trainers and coaching without deviating from what "textbook Agile" says or what they've been taught - Shu. Followed by a phase of the 'Aha' moment; where they've understood the principles of Agility and how that meets their customer needs - mindset (a.k.a Ha). Followed by an embodiment of Agility where teams are coming up with approaches and techniques based on their particular circumstances and adapting it to seek perfection whilst interacting with stakeholders, satisfying customer needs without over thinking it or feeling the need to over-state the "Oh yes we are Agile" statement - Ri.

Very often, Agile coaches, trainers, Evangelist (call it what you may), forget about this very key sentence at the beginning of the manifesto when they go into organisations to help improve things.

Agility adoption is no easy feat and that's one of the many reasons you've not seen a single Agile adoption that is the same from organisation to organisation.  
That is why each organisation need to pick the bits of the Agile framework to satisfy their customer needs with the help of good Agile coaches and the relevant training.

Take it all back to the basics; engage the teams and the organisation, listen, observe - Genchi Genbutsu, coach, train and stick with the basics with a solid foundation until the 'Aha' moment.
Explain to the organisation about the journey of discovery you are all about to go on, to uncover better ways of developing software.
 
My philosophy has always been to have the foundations in place. And by foundations, I mean Agility mindset (through coaching, training, finding patterns and anti-patterns), right culture (personal and organisational) and the right environment to foster the right mindset (attitude, desire, energy) and behaviour. 
It is very important to understand the organisation's customers' needs, the business' vision and how they operate, the challenges the business is facing and then work with them to uncover better ways of developing software by doing it and helping others do it.

Finally, I would like to hear from you with your thoughts on this post in the comments below.