Each of the 14 points in this series is grouped into 3 broad categories, the first one being Modern Development. This for me is the category I feel encompasses the items that people like Jim McCarthy and Fred Brooks did not cover because they were not important at the time. The software development world has changed since their work, hell, it changed since I started working.
When I began as a developer, the very first paying gig I got was in 1998 where I was asked to build a record management system. All I knew at the time was Turbo Pascal, so I built an amazing CLI tool with its own “database” (binary record types) to capture the data. It took me weeks of work, but it was feature-complete and amazing… except in 1998, who wanted a DOS CLI tool? A smart friend at IBM then used this fancy Microsoft Access to build out all the forms and use a “real database” in a few days. That met the need even better than I could. In both cases though, we shipped a file on disk (literally, we burnt a CD to copy the files since flash drives were not a thing) and handed it over. Deployment was copy/paste and updates… what were those again?
Not only did the tech and the ways of shipping change but so did who I worked with. I didn’t work with a developer who was not a white male until almost a decade later. Since then, I have worked on massively diverse teams and what has become clear is there is no perfect model for a developer. Gender, age, education, work experience, sexual orientation, financial situation… none of it has been shown to have any benefit to the success of a developer on a project - rather, it is the team as a whole which matters more.
I wish I could tell you an awesome story about how I learnt this, or give data that validates it, but I can’t… not because I do not know them, but because the amazing Claire Wood did just that in her talk Pink Hardhats and other Anomalies, which like with the Jim McCarthy talks, is one I watch yearly. It is amazing how powerful diverse teams truly are and she can tell the story, and give the data better than I could ever do.
While I was languishing in monocultures in the early 90s, a movement which would be called Scrum was starting to take shape with it becoming a professional standard in 2009. Scrum was not a revolutionary idea, in fact, it the revolutionary idea came about in 1986 when two professors in Japan wrote a paper based on case studies about a new way of working that improved product development speed and flexibility.
Just a small aside, the fact that Scrum and later Kanban, both come out of ways of working in Japanese business, with automotive businesses as a key part of it, just blows my mind. Maybe the next big way of working is happening there now just waiting for you to go and write it up!
But back to Scrum, following that paper multiple people were doing very similar things at the same time. I mentioned Jim McCarthy in the previous post, but also Ken Schwaber, Jeff Sutherland, John Scumniotales, Babatunde Ogunnaike, and Jeff McKenna all were doing similar things (a case of Multiple Discovery) but it was not until it was formalised in 2009 that it took off… and now 15 years later a lot of what Scrum said is still correct.
For me this is about complexity, Scrum probably doesn’t matter if you are building a DOS CLI record management system with a team of YOU, but when you have 150 developers building an eCommerce platform… you can’t run that like one team. You have to break it down into small focused teams (8 to 10 people seems right, but smaller is better). That focus is vital, the more you ask them to do, the more (I’ve found) likely they will slow, and ultimately fail. This does not mean locking that team in a room away from everyone else, they need a broad context and to know how they fit into the grand plan… but their goal should be as tight as possible. I have seen teams of 3 developers running 1 service, outperform a team of 9 running 3 services - even when those services overlap.
Now that you have this small team with a solid focus, GET OUT OF THEIR WAY! You have to trust them to ship code, and so you need to let them figure out what is the best way to organise themselves to do that… and that may mean trying different methodologies, or having different ways of working across different teams as their goals are different. All you can do, is to empower that team with the right support, and authority to do what is needed. What I have found helpful in this regard, and again I steal from Scrum, is just drop titles.
Titles are what consultants use to charge more for someone or to help one’s CV look more impressive than it is. Titles do not help ship software and just cause hierarchies and the ability to hide behind the title, rather than dealing with issues. Everyone is a team member and the team succeeds or fails… not individuals.
This also me to the final factor in the team, that the team who builds the software also owns the software… this includes shipping and fixing it. This is not a new idea, in fact Amazon was talking about “You build it, you run it” in 2006. When I worked at AWS, I saw first-hand the power of this. The teams I led all deeply cared about code quality and operational aspects… There was a huge focus not just on shipping but on keeping things working and delighting customers. These practices are so simple to do, and add major value… but they start with ownership.
When I gave this talk, I wanted to have a practical action for each point too… just one thing which may help someone in the audience. Obviously, this post has a lot of advice on what to do, but the practical action I gave in my talk was about interviewing; something I have not discussed yet. Changing jobs is a natural part of your career and one you will do multiple times, and to help you have success in being in diverse and empowered teams, during an interview ask to meet the team for a coffee before joining. This way you can see if they meet your bar for what a great team is.