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.
The idea of a self-organising team is pretty established in agile software development, as a (post-)agile coach/mentor I sometimes find myself working with teams who are trying to self-organise. Here’s my approach for transitioning a team from being externally organised to becoming autonomous and self-organising.
The first thing to point out is that I believe that the result of a self-organising team practice is an organisation. I don’t know what the the organisation will be ahead of time, that’s what the team work out. What I do (and I think others should do) as an agile mentor/coach is:
- Bring to the team methods and techniques they can use to self-organise
- Information of self-organising and how to interact with other teams in an organisation
- Experience of different structures and behaviours
- Facilitation and support of the organisation
It’s not my job to organise a team, it’s my job to help them organise themselves.
Being an architect/designer at heart I take a simple approach to this kind of thing and think about it in terms of mission, structure and behaviour.
Team’s need to have a purpose. I believe in team’s seizing autonomy and declaring their purpose, even in a complex bureaucratic organisation. So long as senior management are willing to let people they employ to do a complex technical job actually do a complex technical job then there tends not to be a problem. Unfortunately it sometimes takes enlightened leaders to do this but I’ve seen more and more of them in both the private and public sector. A team needs to know it’s purpose and agree on it.
Structurally there are some nice ways of working out who should be in a team and what their role is. I recommend using competencies rather than roles. Competencies are a description of the skills required to deliver the mission of the team and come in levels ranging from the most basic to the most advanced form of e.g. Tester. Either grab some from a suitable process.
Get the team together and get them to score themselves on the range of competencies required. This achieves a couple of things:
- Builds mutual understanding between team members of where the various skills lie and what level they’re at leading to mutual respect and avoiding misunderstandings around what people are “meant” to do
- Establishes whether the team has enough coverage of the required skills for the job, without this knowledge how can a team commit to anything?
Team’s need to know how they’re going to work so they need to understand their functions. As a starter I’d suggest that software development teams have the following functions:
- Production (delivery of working product)
- Communication (both internally with customers and with external stakeholders)
- Decision making
- Way of Working
- Buy-in to the mission and direction
- High level scope
- Changes to agreed scope
A true agile team does all of these things as it includes all of the people and skills necessary (from devs, testers, users, customers, ops people etc.) to achieve them. The team is the vehicle for doing these things.
Each of these things is the tip of a fairly large iceberg. But the team need to work on understanding their Way of Working to do the production job. The team need to agree how they’ll communicate with each other and externally. Both of these are Ways of Working decisions. All function in a team comes down to decision making. Ways of working, communication techniques, scope management etc. need to be constantly refined which means you need constant decision making within a team.
Even buy-in to the team mission and direction (planning and/or technical) is a decision making process. It often happens implicitly with someone charismatic selling a vision and everyone kind-of nodding but that’s not the only way of doing it.
Different decision types deserve different methods
Just because a team is groovy and agile doesn’t mean that every decision should be fully democratic. For example when doing a customer demo to see if the product is on track it’s not normally open to a general vote on whether the product meets the customer’s needs or not. Usually the customer tells you and you have to put up with it.
– identify the different categories of decisions the team needs to make
– identify (using a variation of the Vroom-Jago model) the mechanisms the team will use to make each decision type
– facilitate the decison making process reminding the team of their chosen mechanisms
The output of a self-organising practice is an organisation. Since I believe in honesty and transparency I think that the best way to define and communicate this stuff is in a Team Charter. A Team Charter can simply be:
Some blurb about what the team does – Mission statement
Assertion of rights the team assumes – Autonomy
Who the team is
Who’s in the team, what’s their ability, how do they contribute to the required competencies – Structure
How the team works
A little bit about the practices the team uses. Such as using a continuous flow model, an iterative approach etc. Including the decisions the team makes and how they make them – Decision Making
If you’d like me to help your team self-organise get in touch. Do you have any other ideas on self-organising? Do you use a different approach?