Saturday, 15 August 2015

Domain-Driven Architecture Diagrams

Domain-Driven Design is about creating shared understanding of the problem space that is reinforced ubiquitously via conversations, code and diagrams. DDD’s Shared understanding enhances synergy and alignment, increasing the ability to deliver value sustainably - ideally over the lifetime of a product.

As I most recently attempted to justify at the London Women Who Code Intro to DDD Architecture workshop, the architecture of a system, expressed via diagrams, is a profitable avenue for reinforcing DDD’s shared model.

Highlighted in red: where architecture diagrams can be advantageous using a domain-driven approach.
Diagram modified and borrowed from Patterns, Principles and Practices of Domain-Driven Design published by Wrox

Saturday, 25 July 2015

Trying to be a Good Code Teacher

It's a privilege to be responsible for the education of others. But it's also tiring, relentless and a tough lesson in modulating your emotions. Undoubtedly, teaching programming is hard, especially on-the-job training where you are under pressure to produce deliverables.

Thankfully, playing the role of teacher also confers enlightening personal growth. Guiding a learner's progress is rewarding; dynamically tailoring their learning plan in real time is a vigorous lesson in empathy; and trying to inspire the persistent desire to learn in others is a marathon of emotional intelligence training.

The opportunity to teach others is an opportunity for immense self-growth and self-exploration. By writing this blog post, I hope to solidify my learnings as a teacher and contemplate how I can improve on my many weaknesses.....

Sunday, 14 June 2015

What I Learned from the Business Model Canvas Workshop

How can you make developers happier, more engaged, and poised for innovation? If you relied on developers to achieve your goals, how would you foment these potent productivity multipliers?

My feelings, as a developer, are that freedom and responsibility are the key - explain the problem, and then let me and my team pursue your goals with frequent collaboration and minimal constraints. I say this because when I am not being pressured, and I feel important, that’s when I feel at my absolute best. My developer friends express this preference, too.

Freedom and responsibility are extremely dangerous, though. Not only can they unlock peak potential, but they also risk catastrophe. Instead of helping our organisations to steam past competitors, we can can get too focused on clean code or microservices, forgetting we are supposed to be making someone's life better.

If we want the freedom and responsibility, we need to have a deep situational awareness. This is why I think the Business Model Canvas is a marvellous tool for improving alignment between developers, executives, and just about anyone else in an organisation.

Having experienced the alignment benefits of the Business Model Canvas, I wanted to get the opinions of others who have operated within a variety of different organisational structures and cultures. So I ran a Business Model Canvas workshop for the London Agile Leadership Community.

In this post I will tell you will what I learned at the workshop and where I am focusing on improving my understanding in the future.

Wednesday, 27 May 2015

Starting a Tech Team Transformation

A horrifying revelation that shocks many companies is the realisation of how ineffective their development teams are. Excessive time spent fixing bugs, inability to support business growth, and being out-iterated by more agile competitors are often the distressing trigger symptoms.

One common reaction is to follow the “we must be agile” hype and bring in an agile consultant expecting a quick fix. As good as a select few consultants may be, for 99% of companies there is no quick fix. Culture, practices and personnel often require radical change.

I’ve had this conversation about improving lagging tech teams what feels like a millions times over the past year. The latest one triggered me to put my thoughts in writing and clarify my thinking - this post is as much for me as it is for you.

In summary, my general recommendation is to create a shared vision of change based on the mission and purpose of the organisation, and then gradually implement it. Without doubt, though, individual circumstances will play a huge factor in any change initiative. In this post I will outline my thinking along with some key details and an example implementation roadmap.

Be prepared for a long journey

Saturday, 11 April 2015

Win a Copy of Patterns, Principles, and Practices of Domain-Driven Design

To celebrate the launch of our book, Scott Millet and I will be donating a few free copies. Just email your name or twitter handle to by Friday 17th April.

If you are selected as a winner, a hard copy of the book will be posted to an address of your choice. The book comes completely unconditionally - I would love to hear your feedback though.

Wednesday, 25 March 2015

Proposing the Emotional Intelligence Retrospective

Every decision we make is guided by our emotions - often even dominated by them. The more we are aware of our emotions, though, the more we can control them and make more logical decisions. This is the challenging skill of emotional intelligence.

As software developers, we do not dedicate enough of our focus to being more emotionally intelligent. For personal, team, and organisational benefits we absolutely should, in my opinion.

My suggestion for increasing emotional awareness is to conduct emotional intelligence retrospectives. In this post, I will outline one potential format for such a retrospective. But I encourage you to apply your own ideas as well.

Monday, 16 March 2015

Empathetic Software Development Guided by the Business Model Canvas

Empathy is what makes software development teams effective. Applying their technical expertise, passion and collaborative skills to understand the needs of the business and maximise value creation. Developers are problem solvers - not just programmers.

A development team’s effectiveness is inhibited by a lack of business awareness. Most developers are too technology focused, and most management teams drip-feed their developers partially-solutionized problems based on their poor technical knowledge and gut feelings.

We need both sides to come together and realise the value in aligning everyone with a shared organisational vision. We can do this using the Business Model Canvas to create empathy between business and technical colleagues; in the process creating efficient organisations that innovate from the ground-up.

Whether you are a leader by job title or by nature, I encourage you to bring the benefits of the Business Model Canvas to your company.