Wednesday, 24 August 2016

Learning, Teaching & Selling DDD With The Infographic

Since making the mistake of writing a DDD book, I now get lots of people asking me how they can sell the benefits of DDD to management, how they can teach it to their teams, and even how they can make sense of it themselves.

I know that feeling too well. The first time I read Eric Evans big blue book, I felt like I'd learned a huge amount, but my brain was stuck thinking: "Ok, I've read the book. What on earth do I do now?".

But I'm pleased to announce that there is now an easy way to sell, teach and explain DDD - with "The Anatomy of Domain-Driven Design" Infographic. You can grab as many digital copies as you like, free on Leanpub.

Wednesday, 17 August 2016

Getting Programmers To Agree

Programmers are on-par with politicians when it comes to fiercely debating and rarely reaching agreement - we argue about everything. Getting programmers to agree and be productive together is probably the hardest problem in software development.

Which programming language shall we use? Is SQL or NoSQL best? What is the one true version control strategy we must use? Should the name of this class be a noun or verb? Or should that class actually be 3 smaller classes?!

Two developers politely discussing whether to use MongoDB or Postgres

Debate is fine. A range of opinions is healthy. Even a bit of friction now and then can be productive. But, too often, for developers, decision making brings out the worst in us. We refuse to accept that our opinion is not the right one, and we won’t let it go.

With each of us having a diverse wealth of experiences, preferences and opinions on the subjective art of software development, is it even realistic to expect healthy debate and unanimously-accepted decision making in a team?

Yes it is. It is possible to have a passionate team of developers, with a diverse range of strongly-held opinions, and absolutely it is possible for them to work harmoniously and productively. But how?

Wednesday, 27 July 2016

Digital Transformation.... The Hard Parts

Tech is overflowing with organisations wildly proclaiming how much more digital they will become, how much more agile they will become and how much more customer-driven they will become. But beyond the hype and sensationalism, many transformations fail. And for some strange reason, people are less keen to talk and blog about their embarrassing failures.

Transformation requires a strategic long-term vision, based on an understanding of continuous delivery and matched with an unrelenting commitment to organisational change. And that is hard. Changing people’s beliefs and how they work is hard.

What I see and hear, over and over and over, is organisations doing what they always have but giving things funky agile names and making cosmetic changes. Project managers? They’re called Scrum Masters now. We don’t do waterfall anymore, but we’ve planned out the next 27 sprints in minute detail. Empowering our teams? Of course we let them put sticky notes on the wall!

But the mistakes I see. Always the same. The same fundamental problems that aren’t easy to solve, but do have tried and tested solutions.

Do any of these sound like your transformation?

Sunday, 19 June 2016

Designing For Team Autonomy: Tools For Business & Technical Architecture Alignment

Most software developers thrive in environments where they have freedom and flexibility to put their creative minds to work and solve challenging business problems. The organisations they work for benefit too, through a motivated workforce, and a reduction in people management.

Freedom necessitates judicious boundaries, though. Team boundaries and technical boundaries. If teams are constantly relying on each other, or constantly having to coordinate themselves around shared resources such as code or databases, freedom diminishes and the overheads of people management increase.

Unquestionably, the top organisations in tech love team autonomy and freedom. The very best of organisations, including Amazon, Netflix and Spotify, frequently proclaim the overwhelming benefits of their empowered two pizza teams or their tribes, squads and guilds.

But what tools do we have for carving out these judicious boundaries for productivity, autonomy and freedom? Are microservices the answer? What about bounded contexts? Or should we be understanding more about our problem domain first?

Friday, 27 May 2016

Random Thoughts on Hiring

With a flurry of passionate blog posts on the blogosphere recently and a bit of on-the-job action, the topic of hiring has been filling my shallow, little mind with many deep thoughts of late.

So In this post, I’m going to throw lots of random thoughts at you. I’m not saying they’re good. I’m not even suggesting you should try them. And I certainly take no responsibility if you borrow my ideas and hurt yourself.

I wanted to put these thoughts in writing to gain clarity and headspace back. And I decided to blog them so that you wonderful people of the internet can all tell me how incredibly wrong, naive and foolish I am. Thank you all very much in advance.

Interviews should be stressful and uncomfortable... shouldn't they?

Tuesday, 19 April 2016

Agile Retrospectives: Ceremony or Sensation?

You put your left leg in, your left leg out. In, out, in, out, you shake it all about. You do the Hokey Cokey and you….. and then two weeks later you have another retrospective.

Just like the Hokey Cokey, many cynics view retrospectives as a bit of a ritual joke dance. Stand ups, retrospectives and kanban boards - “we must be doing it right”, those agile cynics sarcastically grumble.

Yet other people I've worked with are completely besotted with retrospectives. Their feet start to twitch as the minutes tick down to retrospective o'clock and they’re like excited little children dosed to the eyeballs on exploding candy and fizzy drinks.

So retrospectives… ceremony or sensation?

Are your retrospectives a cringeworthy, and mind-numbing ritual or an exciting opportunity to become a better team?

Monday, 28 March 2016

Optimising Team Boundaries For Iteration Is Fundamental To Agile

Nowadays, agile is a hugely ambiguous term. I still cringe when I see or hear the word and I have an agile jar at home where I must deposit a small sum of money each time I say it. However, I think we can all agree that agile’s heartbeats are it’s iterations. Doing things in short cycles to gather feedback and act with insight.

Accordingly, the structure of teams within your organisation and their responsibility has to be conducive to iteration. In my experience it is a fundamental necessity for truly benefiting from agile and continuous delivery.

But many never reach this depth of understanding. They stall at the scrums, the stand ups and the superficial, without realising that the core of the organisation must be optimised for iteration as well.

Self-contained teams with ownership of complete vertical strips of business functionality is the new normal. Teams unburdened from dependencies on other teams with a clear path ahead for relentless iteration.