Saturday 15th July - The "Failing" Team


Do you have or know of a 'failing team'? How is this characterised? Is it:

  • Too slow to deliver features
  • Always distracted by production problems
  • High turnover of staff – particularly domain experts or leads or anyone who has been there “too long”
  • Unable to refactor or redesign due to continuous firefighting

I've recently experienced a team that was seen to be failing and had the pleasure of being part of it to try and see what we could do to "fix it". The problems ran outside of the scope of the team across the whole organisation where there was:

  • A firefighting culture (being busy fixing symptoms rather than addressing the fundamental disease)
  • Too little attention being paid to quality, especially low coverage of unit tests at the domain model level
  • Poor OO techniques in coding leading to code that was hard to test
  • Long and unwieldy CI and deployment process characterised by infrequent and highly manual deployments.

Any of this sound familiar? What would you do to start fixing things first? Is it a failing team or a wider problem?

Here is how I think about it:

If your team is failing, then you are failing the team.

If you can make this judgement, you are part of the problem. I wrote about this in more depth.


Modern Software Leadership

This week I announced more details of the first edition of my new course, Modern Software Leadership. This course will take place coming September on three consecutive Fridays. It will be led by myself and include the following modules, with course notes, a Slack/Discord community and group exercises to increase your knowledge and confidence around modern software delivery and leadership. The modules will be broken down as follows:

Module 1 - Our Enterprise Landscape

  • Building vs buying
  • What does a modern architecture look like?
  • The challenges of the enterprise landscape
  • Why estimations are always wrong
  • Solution architecture vs enterprise architecture
  • A confusion of best practices (Agile and Development)
  • Why is security so hard?
  • Why does Digital Transformation fail?

Module 2 - How We Experience Software Delivery

  • What is developer culture?
  • Overcoming design by committee
  • The importance of tooling
  • Building trust across the organization
  • Remote or office? What's the real impact?
  • How we slow ourselves down (Pull requests, reviews)

Module 3 - Building The Modern Software Delivery Organization

  • Organisational design for resilience and flow (Team Topologies, Conway's Law, Theory of constraints)
  • Scaffolding For DevOps, Continuous Deployment First
  • Measuring with DORA metrics
  • Emergent design techniques (TDD, DDD, OOP)
  • Staying secure and getting faster
  • I'd love for you to join me! If you are interested, you can find out more details on the course page or reply to this email.

    ​Have a great weekend!

    -- Richard


    When Speed and Quality are the Same Thing

    Published on July 11, 2023

    I’ve been working on a project where I provide support to help increase the speed and quality of delivery in one specific development team. The architecture is microservices in .NET. There is an established change process which is PR based, with a single long pipeline to production. Initially, I was there to provide advice and… Read More »When Speed and Quality are the Same Thing

    Read more...

    The Human Software

    Software systems rule our world. My regular newsletter explores the human factors that make software engineering so unique, so difficult, so important and all consuming.

    Read more from The Human Software
    Human Software 272 - Impatient, Needy Writers

    Writers are terribly impatient. We are so fragile, we crave attention all the time. So, for us, writing into a vacuum and not getting anything back is the worst. We will happily take anything including "wow, it really sucked" or "how could you be so old and so feeble at writing?" At this point in the journey of Human Software, I'm so desperate for feedback, I'm even willing to pay for it! So that's what I did. In January, I hired an editor, and he's been great. He helped me with the...

    Human Software 271 - Drawing Inspiration from History

    Over the last week, I drew a map of Kent reimagined as if the 1286/7 floods hadn't happened. According to the history books, those large storms and tidal events significantly changed the coastline of eastern England. The former Wantsum Channel became blocked with alluvial mud and sand, turning the once important seaport of Sandwich into a landlocked town too far away from the sea to accept large boats. Further afield Dunwich in Suffolk suffered a similar fate: In the Anglo-Saxon period,...

    Human Software 270 - Finding Something to Say

    Three years ago, I started a podcast without much idea of its future. Before that, I'd started writing, wandering through automation, programming techniques, infrastructure, DevOps, and thoughts about management, leadership, and how companies are organised. Where was I going? While I'd read a few books, it was clear that I was searching for something. Was I just talking for the sake of it? It sometimes certainly seemed that way. And then, about eighteen months ago, I started writing a novel....