I normally avoid posting on controversial things but this is a topic that shouldn’t even be controversial.
The world is full of a marvellous variety of people and they come in all shapes and sizes, with a staggering range of ways of thinking. People are different due to things like gender, race, ability, sexual orientation, cognitive difference and all sorts of other things that affect identity. Importantly people are never just one of these things, real people exist at and between all of the intersections.
In the software industry we often rally behind people based statements such as “Individuals and interactions over processes and tools” and yet discrimination and unfairness are rife in the technology industry with “brogrammer culture”, sexist pay situations and the infamous glass ceiling. And yet we talk about being open and inclusive in how we do software in teams? And wonder why there aren’t more women taking technology courses at universities?
Feminism is a collection of movements and ideologies that share a common goal: to define, establish, and achieve equal political, economic, cultural, personal, and social rights for women. This includes seeking to establish equal opportunities for women in education and employment.
Women aren’t less than men. Men aren’t better than women. Instead people are just people, and each individual isn’t just a woman or man, they will be different in many other ways, expressing their identity, individualism and indeed diversity in each of them. There is value in diversity, and as people that can understand recursion we should be able to grasp that concept. The more ways we have of looking at a problem the better our solutions will be.
I believe that everyone should be treated fairly, that equal opportunities should exist for individuals, that if we need to differentiate between people (e.g. in terms of who to hire) that we should do it on merit, on skill, attitude and behaviours not on what makes a person different. I guess that makes me a feminist.
I’m a feminist because I believe in equality. Gender is one axis of difference that is used to discriminate against people and women are generally treated less fairly in the tech industry than men and so that’s why I’m a feminist not an “equallist”. I realise that this is an unpopular stance to take amongst some groups, especially those who are uncomfortable with a man using the word “feminist” but I think those people should take a good long hard look a themselves. If you’re not a feminist, you should probably go and explain why to your mother rather than argue with me about it.
Men, and women, and in-betweens and neithers, all need to stand up for equality, need to challenge unfairness when it raises it’s ugly guise. The amount of times I’ve seen sexist treatment, casual racist and homophobic language in the tech and gaming industry is shocking and it needs to change. Otherwise we can hardly call ourselves civilised. Of course, there are always weird situations where it’s not clear whether something is discriminatory or friendly banter – exploring those situations in an open and honest way, discovering if behaviour, language or tone has crossed a line helps us all understand each other better. Conflict is best avoided through clarity of understanding between people. Ultimately though the meaning of any communication is that which is received, regardless of the intentions. If you accidentally offend someone it’s still you who are offensive, not the victim who needs to grow thicker skin.
As men, we are morally bankrupt if we leave standing up for equality to those who are marginalised and discriminated against. Equality requires us to collectively act.
I was reading some course material recently that was trying to teach people something to do with software development and it was using the same old tired “ATM machine” example. I’ve worked with hundreds of projects, many in the finance sector and none of them are anything like an ATM machine. One of the reasons that example is soooo tired is that it’s describing commoditised software development, it’s something I’d expect to buy off a shelf or go to a specialised vendor for. It’s not something I’d put my team of uber |33t haxorz on.
Developing software products is a balance between a creative and scientific pursuit, so it’s a little hard to describe, especially when that software can range from a tiny smartphone app, to a website, to router firmware, to an enterprise hr system (urgh!), to a big data processing system of systems etc. You get the gist.
The things these types of system have in common with each other is how different they are. And yet the traditional approach to managing these diverse kinds of work has been classical project management with a one size fits all process (I’m looking at Prince2, RUP, Iterative, Agile etc.) or worse hiring a large company full of body-shop project managers. For me this is one of the root causes behind large scale IT disasters.
I once had a discussion with the leader of a PMO in a large organisation of thousands of people about the nature of Project Management for software and he assured me that “someone who knows how to manage a bit of work can manage software, it’s just a different type of work” and indeed I should “stop thinking of software as special”. I’ve seen this attitude resonate in many organisations and is to me best summed up by the same Head of PMOs statement “from a project management point of view building software is the same as building a bridge”.
Now then. I know a little about software development, but not that much about bridge building (if you exclude my illustrious Lego engineer career when I was 7). If I managed the building of a bridge next door to one build by someone with a track record of bridge building who’s bridge would you drive your family on? Not mine if you’ve got any sense.
There are so many problems in the software development industry caused by people not understanding it and applying bad metaphors. When people who do understand it start to get the point across (e.g. the early agile movement) they often get misunderstood by the old guard who dress up their normal ways of working in new language.
Many of our “best” metaphors come from manufacturing lines where the same thing is made over and over again. That’s nothing like software.
To me a software project is more similar to making a movie than anything else:
- It’s a unique one off product (or a remake of a previous version) with new parts working together in new ways
- Once made we’ll often duplicate and digitally distribute
- It can cost a lot of money because it can be very complex and needs lots of specialist skills
- You need a high level plan for how you’re going to make it
- There’s no guarantee on return
- What’s written down originally bares little resemblance to the finished product
- We know when it’s good or bad but it’s hard to objectively quantify
- There’s lots of different types that need different collections of specialist skills
- Both involve people and time and so are subject to change, they have to be adaptive
- You can tell when the people making it had fun
- It’s not feasible that any team member can fit in any role
- There’s almost always going to be some quality problems
- You wouldn’t get a movie maker to build your bridge
- You wouldn’t get a bridge builder to make your movie
- You don’t make a movie faster by telling the actors to act faster
So, I don’t want a Project Managers that know how to work a gannt chart. I want movie producers that know how to work with a team holistically to get the best out of them both technically and artistically.
When I started doing software I was a simple developer interested in elegant code and shiny things. I worked in a small software house that taught me many bad practices in terms of configuration management, change control, estimation, management etc. It was an incredibly valuable experience for me in learning how not to do things and led me to strive for something better even though at the time I didn’t really know what it might be.
That led me through a path of process definition and documentation (RUP) and a rather limited following of an iterative lifecycle. I remember a conversation I once had with one of my project managers (when I was an architect) asking if we were going to do “Use Case Analysis” on a particular project or just skip straight into “Use Case Design”. The question puzzled me then because it felt like a trap and I didn’t really understand what I was being asked.
It puzzles me even more now as I know understand “analysis” to be a stop-and-think-for-a-moment activity and I’d always do a bit of analysis of my requirements, however these days it’s extremely unlikely that it’d be an analysis UML model, instead it might be a sketch, a conversation and a bit of thinking before another conversation.
So I moved from process prescription to process understanding, applying the spirit of doing things well rather than the letter of whatever current process law was in fashion. Following on from that I’m not really interested now in the details of what a book says someone’s role should be or how people should interact instead I think the real challenges in software development are social, not collections of technical practices (although there is value in evolving better practices and tooling).
A colleague of mine commented recently that 20 years ago when he was doing software it was possible to understand everything from the metal all the way to the blinking lights on his bit of hardware. Software development in just 20 years has progressed incredibly and it’s just not that simple any more. We can understand the basics all the way through the stack but not all of the details. There are so many bits interacting that it’s just too complex. As a result the problems, technology and team working are all abstracting away from the tangible mechanistic past.
Developers are on a path from technical skill to mastery, as they begin to understand the kung fu of software engineering they can apply experience and deep understanding to solving the technical problems, doing away with formal process and just using the practices that they intuitively need, happily breaking the “rules” to get the job done in an efficient high quality way. I’m not entirely sure where brogrammers are on this evolutionary path, I’ll leave that up to you.
The problem, if it even is a problem, is that each person in an organisation is somewhere different along this path and even if they’re at the same point in the same dimension they might not be aligned in their interests and motivations. This makes team working amongst inherently complex social creatures a tricky proposition. The sweet spot is a team of fully enlightened software kung fu masters but that’s a really hard target to meet for a number of reasons. Consider the flower of team working evolution weirdness, which area is your team in?
One reason that this sweet spot is difficult to hit is because in any organisation half of the developers are below average in technical and social skills. Sounds horrible but is obviously true and the larger the organisation the more likely it is to be the industry average, not the organisational average.
This means that the centre of skill gravity for any team is unlikely to be on the w00t side of the scale.
In most large organisations the teams are more likely to be flattened pancakes across this bell curve taking in a reasonable representation of the organisation as a whole (especially as the highest skilled are often distributed amongst an organisation to attempt to bring up other teams.
This isn’t necessarily a problem though as there is value in diversity and individuals will each have different ways of thinking about things that can bring value to teams and organisations.
I’m beginning to think that the purpose of classic software process, and classic software process improvement is to try and move people along this scale from basic developer to software ninja, helping them to gain mastery through experience and feeding in the experience of others. When a team moves along this scale they begin to not need their process mentors any more and will seize their autonomy.
Technology is increasingly commoditised by innovation, as is software development and software process. I used to spend a lot of time teaching people Object Orientation but these days everyone just seems to know it, it’s nothing special or new, it’s just what people do. Similarly people are increasingly aware of the value of iteration, limiting work in progress, continuous integration and delivery. They need less process and less instruction as this stuff is becoming business as usual at least in more mature organisations.
As these problems are being solved I think that bigger problems are coming to the fore as they’re less hidden by low level development issues. The questions I see a lot of clients wrestling with are things like:
- How can we foster the right kind of organisational culture?
- How do we deal with requirements, architecture, releases, resources etc. in a complex system of systems environment?
- How do we bring together multiple divergent interpretations of “agile”?
- How do we manage outsourcing contracts in high speed agile projects?
- How do we motivate and engage the business and technical communities?
- etc. etc.
Solving these problems is less about technical skills and technical process content and more about social skills, psychology and understanding. Both from a coaching and business perspective.
So what’s my point?
My point is that software process improvement needs to focus less on individuals and more on teams, and teams of teams. That we should avoid ideology and take the best bits of knowledge and experience wherever we find them, growing our teams and individuals.
Also that we should apply more psychology to software process and business change finding socially resonant patterns for how we do things. True mastery involves not worrying about “breaking the rules” and from the outside can easily be confused with ineptitude.
The purpose of a daily standup is to bring the team together to answer some questions (What did I do yesterday? What am I going to do today? Are there any blockers/impediments?). One of the client teams I work with has a daily standup every day in the business change team I’m part of. I’ve always found the first two questions rather pointless as basically the team would get together and read out their diaries for yesterday and today. It just wasn’t helpful and so in the past I’ve argued against the Daily Standup in it’s normal form in business change teams. It was too long and boring, especially the team is mostly comprised of mentors who’d spend the day working on their own patch of the organisation rather than with each other.
Recently I wasn’t working for the client on a Monday and my son was doing a school play on Tuesday morning so I arranged to go into work a bit late and missed the standup. And at this point I had an epiphany, I was at my desk and didn’t know how the team were feeling. I still wasn’t particularly interested in their diary commitments but I was interested in their mood and if anything of team level significance had happened since I’d last been in.
So it hit me, the value of the daily standup, as described in my first sentence, is the more about the former than the latter.
The purpose of a daily standup is to bring the team together to answer some questions…
Being able to look around the team and see who’s around, what their mood is and make the human connection is the important point. Even the metaphorical bringing of the team together physically (if possible) reinforces the team identity.
So now we’ve improved our standup process. The value of bringing the team together is paramount, the questions reworked for our team and it’s context. We examine new incoming work, how to resource it and raise impediments. So we’ve dropped the creeping death of diary exposition and just kept the value 🙂
What do you get out of standups?