Unless commitment is made, there are only promises and hopes

This is the third post on the theme, the five dysfunctions of a team.

The first two are available here:

With a natural or assigned Maverick on our team and a level of vulnerability and trust we reach the point where actual decisions can be made. Up until now we could consider the efforts to build the team to be the foundation, but now we have to put it in to practice.

This is also the point when it starts to hurt, this is where it really tests whether you truly have trust and are truly open to input and discussion and healthy conflict.  Many teams say they have built trust,  and many teams seem to have open discussion and healthy conflict, but this is where you test that.

Can you make a decision and follow through on it?

five-dysfunctions-pyramid

Consensus

Please do not confuse decision making with getting consensus. The goal of a team is not to please everyone on the team, it is to get things done, to make decisions that help us – for the team reach our team goals.  If we waste time trying to please everyone we end up either paralyzed, or with a watered down decision that accommodates everyone but satisfies no one.

“Consensus is horrible. I mean, if everyone really agrees on something and consensus comes about quickly and naturally, well that’s terrific. But that isn’t how it usually works, and so consensus becomes an attempt to please everyone.”

Patrick Lencioni

The funny thing is that most of us do not want consensus, nor do we always want to be agreed with.  Most of us are not unhappy when a decision is made just because we disagree with it, but we are very unhappy when our opinions and concerns are avoided; ignored; overlooked; or given only lip-service.

I want to feel valued

If I feel that my input is valued; listened to; if my concerns are discussed fairly and sensibly but the decision is made to proceed despite my concerns, then I can still buy in to that decision and crucially I can support it.

But if the decision gets made without me, or my input is so obviously not going to be given a fair hearing, then two things happen, first it won’t get my support, or my support will be shallow and half-hearted. Second, why would I speak up next time? We will just regress to a lack of healthy conflict.

It should be simple, if someone is on the team then their opinion counts, otherwise they should not be on the team.   If you cannot accept that, then perhaps you should not be on the team.  Being a part of a team has an implicit commitment to value each other.

Childrens-4

Unless commitment is made, there are only promises and hopes… but no plans.

Turn decisions in to plans

Getting to a decision is not enough, you need to turn those decisions in to plans and you need to turn those plans in to actions.

Plans are only good intentions unless they immediately degenerate into hard work.

Failing to commit to a decision is as bad as not making a decision – possibly worse. We should be clear what the decision is, and who and how it will be implemented.

Failing to follow through on a decision renders all the time and effort spent discussing and debating the right choice, null and void, it becomes waste. A waste of time and energy and will undermine a team as surely as the inability to have the conversation.

Be decisive and be clear

Whenever possible any decisions should be associated with a specific action, a date for it to be completed and a clear understanding of who will do it.

If we make the extra effort to identify who will perform the action and when it creates a foundation for the best chance of success, there is a clear and measurable outcome. Everyone knows what to expect and when. This is crucial for being able to hold each other accountable.

Wishy washy action items, that are for everyone with no expected date will generally get ignored, but something specific combined with the certainty that you will be held accountable and it will be followed up will likely mean it gets done.

Pointless conversations

If you find you get to the end of a discussion with sufficient healthy debate and the result is to take no action on a frequent basis, then this is cause for pause.  Could you avoid wasted conversations by injecting a Go/No go break a few minutes in to a discussion and ask the team: “If we reach a decision are we empowered to act?” or “If we reach a decsion would we be willing to act?”  if your answer is No to either of these, then save yourself some time and heart-ache, if there can be no action then the conversation is moot.

That is not to say all conversations must result in action, but all conversations should have that potential or they are waste.

 

 

 

dysfunctions

If I had to recommend one book that would help your team become the best Agile Software Development team, it would be The Five Dysfunctions of a Team by Patrick Lencioni, the book does not even mention agility.  But in my opinion the vast majority of questions I’m asked or problems I see can be traced back to something covered in this book.

 

 

 

 

 

 

 

 

 

 

Advertisements

Every team needs a maverick

Have you ever been on a team where the boss presents a new idea and looks around the team for a response and there is this one guy that breaks the silence by saying “What are you drinking boss? That idea is a bunch of crap” well maybe he was a little more polite but still the message was clear. Everyone else holds their breath waiting to see what happens.

Desire for harmony

For most people the desire to be liked and accepted leads us to have an overwhelming urge to conform with a leader (or the group majority) to maintain harmony, regardless of what we might think.  Sadly most people also have a very strong subconscious desire to be agreed with, especially leaders. When people agree it affirms their leadership and those that challenge are perceived as challenging them personally – rather than the idea itself.

perception

This all combines to create another horrible dysfunctional team, one where there is an absence of conflict. Well, apart from that one person stupid enough to speak their mind, and they’ll likely be fired soon, then we can all get back to agreeing with each other.
Now I am making light of it, but a leader that is able to understand conflict as healthy is rare, and one that can, in practice swallow pride and engage in healthy debate is rarer still.

The invisible threat

The problem though is that even with that rarest of leaders there is an invisible threat, the leader himself knows that he values conflict, that to be truly successful ideas need to be freely expressed and freely challenged, but everyone else can see the threat that is invisible to the leader, they know he still holds the power even if it is not overt, that invisible threat still causes teams to hold back and to create a false sense of harmony.

You may think that I am overstating the point but just think back over your career and how often does the yes-man or yes-woman get promoted over the more capable but outspoken. How many leaders surround themselves with people that will affirm their decisions rather than pushing for more. It is natural and normal to like those that agree with us far more than those that push us. But get over it! That behavior is limiting your team.

Solution

My solution to this problem is for every team to have an maverick, someone that is Not afraid, someone who will break the harmony spell and get the conversation started,  push ideas to be better, force plans to stand up to scrutiny, to trigger others into sharing their opinions. If you are lucky you have one already.  Turns out every team I’m on has one 🙂 but if your team doesn’t already have one (or more than one) then take turns, at the start of a meeting roll a dice, select one person to be devil’s advocate and it is their role to challenge ideas look for flaws or weaknesses, this will push the team to be better and can do so from the safety of an assigned role.

Devil’s Advocate:

The term a devil’s advocate describes someone who, takes a position he or she does not necessarily agree with (or simply an alternative position), for the sake of debate or to explore the thought further through discussion.

Try playing Devil’s advocate:

  • If you sense that some of the team are not buying in to a proposal but are not speaking up, make a challenging statement
  • If it is your proposal, invite disagreement by questioning your own proposal, by saying maybe I am wrong, or I think I missed something
  • Be clear on your motives, you must genuinely want healthy debate. If you invite disagreement but brush it off then it can further encourage artificial harmony

There is a difference between healthy debate and someone that is just obtuse, and conflict alone will not get you to results. But an maverick that is also a genuine team player is invaluable on a team. I’m not talking about jackasses here, but people who are not afraid to speak their mind, for whom honesty is more important than acceptance.

 

dysfunctions

If I had to recommend one book that would help your team become the best Agile Software Development team, it would be The Five Dysfunctions of a Team by Patrick Lencioni, the book does not even mention agility.  But in my opinion the vast majority of questions I’m asked or problems I see can be traced back to something covered in this book.

 

Once trust has been established the next step is to build on that trust with healthy conflict where ideas can be shared without fear, where opinions are heard and considered.

 

Is it safe to dance?

Have you ever found yourself alone listening to music and you take a look around wondering if it is safe to dance?  Safe because your dancing is so bad it is unfit for other eyes, in fact it is so bad you are not sure you should look.  Perhaps your car is a little safer, it is a capsule of invulnerability, so when you are alone you can sing at the top of your voice and no one can see, or not until you stop at the lights and notice the person in the car next to you looking at you.

Feeling safe enough to be vulnerable is not easy even when you are alone, but it gets progressively harder when there are other people around. Now I’d never sing or dance in front of others, but the other day I found myself at lunch with four of my closest friends at work – if asked I would say I trusted the four of them a lot, I consider them really great friends, so I felt able to be a little bit vulnerable and I told a slightly inappropriate joke.This may not seem a big deal but I immediately became embarrassed I glowed red and went quiet for a while, I found vulnerability is tough even among such good friends.

Vulnerability is tough even among close friends

We all want to be liked and accepted, to be included in a group, and so it can be hard to be vulnerable, and yet the irony is that taking the step to show vulnerability may well be the step needed to make those friendships and your team stronger.

maxresdefault

Trust in a team

In a team environment it is so important that you can feel enough trust with ALL of your team mates that you can truly feel able to say things like:

  • I need help
  • I don’t understand
  • I disagree
  • I made a mistake
  • I find those tasks difficult
  • Show me how to do that again
  • I feel uncomfortable when you do that
  • I wanted to do the task you took
  • I am unhappy with this decision

But if I struggle to trust even my best friends, how can I possibly trust co-workers that I know much less, after all the same rules apply. I want to be liked and accepted, I definitely don’t want to look stupid or uncooperative, I don’t want to discourage others or waste time, I have a burning need to feel valued and part of the team. I need to show my worth to my boss, etc.

Is it safe to dance?

Essentially when you are part of a team you are asking yourself “is it safe to dance?”
If you keep that in mind it gets easier, what would make it safe to dance for you. For me it would take a lot!

I’d need others to dance first, probably all the others, but certainly the leaders, the people the others respect. I’d need to see that some were as bad as me, I’d need to see that no one was laughing at them (only laughing with them) and that everyone was encouraging and supportive, then and only then might I feel able to be vulnerable and join in, and frankly it would take a few repeats before I would truly feel comfortable.

We can dance if we want to, we can leave your friends behind
Cause your friends don’t dance and if they don’t dance
Well they’re no friends of mine…

dance

 

How does that relate to work?

You may think that dancing is not like working in a team and that the humiliation of dancing is far worse that simply doing your day job, but I think this is one of the reasons teams suffer from an absence of trust so often.  We dismiss both the importance and underestimate the difficulty of building trust in a team.

In a team environment you are sharing your ideas which are deeply personal, your knowledge and judgment which may be closely associated with your sense of self. Doing something wrong could affect your job, maybe even your career. Sure you may not look and feel like a buffoon but the stakes are much higher. And even if you get past the work related barriers you still have to contend with our inherent desire to be socially accepted, to be liked and valued.

So how do you build trust on a team?

Actually this is not that complicated it is not really any different to building friendships.

  • Spend time to get to know each other, take a few minutes during meetings to get to know each other, this is not waste, a few minutes spent building relationships could well be the most productive aspect of the meeting in the long term.
  • Chat over coffee and as you work – about personal stuff
  • Have lunch together as a team – this works best if the whole team is together.
  • Play games! One of the best ways to build relationships is to play a game something simple like a card game is great, it is inclusive and leveling, the most junior member of a team can challenge the most senior in the safe confines of the rules of a game this makes it much easier to discuss work ideas on a level playing field later.
  • Time, trust and relationships take time, do not underestimate it.

For all of these it works best if everyone is there to avoid creating pockets of trust which could undermine the team later.

trust-stones_480-300x200

The last one was time, and warrants an extra note. Building relationships is a slow process you can’t simply flick a switch, allow teams the time and space to grow the relationships will build and grow stronger and stronger, and once the team is stable changes can be made so long as a core remains to keep the identity and trust that has formed.

Trust takes time

dysfunctions

If I had to recommend one book that would help your team become the best Agile Software Development team, it would be The Five Dysfunctions of a Team by Patrick Lencioni, the book does not even mention agility.  But in my opinion the vast majority of questions I’m asked or problems I see can be traced back to something covered in this book.

You cannot uncover better ways to deliver software without first uncovering better ways to work as a team. And the basis for an effective team is Trust.

Building trust should be your top priority, spend the time, make the time, it is an investment in the future of the team. Without trust anything else you do will suffer.

Without trust anything else you do will suffer.

Take the time to build trust on your team, make it safe to dance.

 

 

Is learning an expense or an investment?

The capacity to learn is a gift;
The ability to learn is a skill;
The willingness to learn is a choice.

Brian Herbert

It is pretty safe to say that most learning involves some kind of cost, whether it be that you are slower as you learn or have to explicitly take time to learn something new. There is a time aspect, an effort aspect and sometimes even an overt outlay of cost for a training course a book or a subscription. But all are a cost to you or our employer. But the question is: Is that cost simply a necessary expense or is it a worthwhile investment for the future?
Is that cost simply a necessary expense or is it a worthwhile investment for the future?
This is a tough question and I am sure many employers and employees wrestle with on a regular basis.  For the employer there are concerns that time spent learning is time that is not productive (or not as productive)  the time could be better spent generating income.  In the case of formal training or qualifications there may be an opportunity cost of the time spent AND the cost of the training which can be significant, and perhaps more concerning the employee becomes more employable and more valuable as a result so there may be a consequential increase in turnover or a necessity to pay the employee more as a result.  In essence it is easy to become focused on the expenses and forget the benefits that come from a better trained and more fulfilled workforce.

As an individual/employee it often is expected that you do your learning on your own time, you are motivated for self-improvement and your employer may focus on the benefit the employee gains rather than the benefit to the employer. The difficulty with this is that learning time tends to be when you are least energetic, or at times when you are sacrificing other activities.

now-vs-later

Short vs Long-term thinking

In the simplest form the choice may often come down to the type of work and whether an investment in people will benefit the organisation. My initial thinking is that if you expect to have a high turnover of staff or the type of work you do is low skill, then investment in people may be perceived as an expense rather than an investment but even then I wonder if an investment in learning may reduce turnover and increase skill.  But in the field of software where the world changes almost daily, with new techniques and new approaches appearing regularly, then an investment in learning is not just beneficial it is almost essential just to keep up. To not invest in learning could be very detrimental to the long-term prospects of your organisation.

Choosing NOT to invest in learning could be very detrimental to the long-term prospects of your organisation.  

In ‘software fields’ good people are hard to find, and even harder to keep. Many organizations now operate flat structures with little or no hierarchy, promotion in the conventional sense is no longer the main form of advancement. Individuals grow through learning new skills and becoming experienced in new techniques, and not simply hands-on learning and experience.   We rely on intrinsic motivation – Autonomy, Mastery and Purpose, to keep employees engaged, happy and productive.

A key element to both Autonomy, Mastery and even Purpose is time for learning and reflection.  People that are not supported in this are likely to be less fulfilled, less happy and more likely to look for work elsewhere. Entropy sets in, and in software that can be fast and devastating for both individuals and organizations, individuals with outdated skills can find it difficult to find work and become demoralized and trapped, organizations can find that motivated individuals want to be working on new technologies and embracing new techniques.

What is our goal?

An organisation is generally interested in making money and growing either in size or in effectiveness, understanding this we can attempt to visualize how individual learning can support that goal.  Learning and personal development leads to a sense of Mastery, empowering the employees by giving freedom to use the time as they see fit provides autonomy, and sharing your company vision and how they can be a part of that provides the purpose.  Employees that feel these motivations will be happier and will be far less likely to leave, turnover is hugely costly to an organisation especially when it is the better employees that are more likely to leave.  The reduction in turnover alone may be enough to justify significant effort.  But improving employees will use those new skills in their work, they will encourage others and it is highly likely that productivity and creativity will improve.  In short providing opportunities for learning supports the goals of most organizations.

How much time should be assigned to learning?

At a previous company they set aside 2 hours a week for each employee to dedicate to personal development, this was in addition to any formal training. This is close to a 5% increase in overhead per employee, which is significant but set aside a reduction in turnover may be immediately beneficial.   In practice however it was not always observed, pressures from projects would often squeeze this time as it was seen as secondary to business objectives. The frequency in which it was observed undermined the policy.

In environments where time is billed to clients it becomes even harder for a company to see the value of learning, it becomes un-billed time which is even more costly but that doesn’t reduce the importance or value in the learning time.  I’d like to see organizations regularly set aside 1/2 a day each week for personal development, and provide the tools necessary to make this effective – pluralsight subscriptions, purchasing books for employees even if they are not directly relevant to their work – remember the goal is to motivate and create an environment for improvement.   At 10% of employee cost this is a significant ask, but I would hope that if introduced in the right way with enthusiasm and support, employees will embrace the way you are valuing them and their personal development and this investment will pay dividends.

Our danger is not too few, but too many options … to be puzzled by innumerable alternatives.

Richard Livingstone

Can you have too much autonomy and too much choice?

One final observation is that when presented with boundless autonomy we generally become lost and confused.  Most people will respond to this with confusion and more limited actions than when provided with a framework.  Imagine a restaurant with no menu, you could order anything you like. Most people would be conservative in their responses, they will not challenge themselves or their boundaries instead choosing something they already have confidence in and confidence that it is easy for you to provide – some will challenge but most are cautious. Also most people don’t like this, they want a restaurant to have a menu. They may grumble that something isn’t on the menu, and may ask to switch X for Y on their order or for the cooking to be modified, but the framework of a menu provide scaffolding and enables choice, the lack of the scaffolding stifles it.

It is the provision of boundaries that enables us the pleasure of pushing them, and having some guidance of what our options are for learning enables us and empowers us far more than a blank slate.  With some ideas of what is available we are able to ask for more or suggest alternatives.

Summary

  1. Make Time: In my opinion an organisation that is in the software field needs to make learning a pre-requisite, this is the most important task of the week.  Learning time is very important, so set aside time for it, and make the time such that it doesn’t conflict with the team or other business activities, Maybe set aside Tuesday morning as personal development time and challenge anyone not using it.  Teams where there are pressures or pairing may feel that this time impacts on their peers or their project this message needs to be challenged regularly.  This is for the long-term health of the business which outweighs any temporary short-term pain.
  2. Scaffolding: Create a framework where it will be used and is not just a hollow gesture, have a menu of options, and people who’s role is to support and guide, set development goals, provide subscriptions to online training, a budget for formal training, encourage in house peer training in this time. Encourage people to present their learning, acknowledge them for their efforts and especially for sharing it with colleagues.
  3. Broaden Scope: Don’t limit this to technical skills, or to skills your organisation currently uses, this is about personal development, so team building, soft skills, and even time to reflect on learning or their career/interests all help with that.
  4. Support: Some people will need more encouragement and support than others and so a group that is dedicated to professional and personal development could be invaluable to get the best out of this initiative.  All of us can benefit from someone to help us identify our goals and a plan, and to encourage us stick to it.
  5. Persist: Finally this will take time to become habit, starting the initiative is not enough, for a while it will require reminders and reinforcement to get the best from it, but if you are able to provide your team with the opportunity to grow as they want, I believe they will become far more engaged, enthusiastic and energetic.

 

 

When does coaching end and doing start?

“Coaching is unlocking people’s potential to maximize their own performance. It is helping them to learn rather than teaching them.” ― John Whitmore

Coaching is an interesting and confusing notion, as an Agile coach in my current role we must be explicitly invited by a team or an individual to coach, usually this is driven by an awareness of a specific problem or a general desire to improve in some area.  The goal of the coaching is to enable an individual or team to solve the problem or to provide structure and support to enable the learning.  The goal is not for the coach to solve the problem.

The goal is not for the coach to solve the problem, the goal is to coach you so that you can solve the problem.

I have reiterated that because it is so critical and so confusing. A team has asked for help with a problem and you are not going to solve it?   In fact you may actually let them fail and watch them flounder – how is that helping?

This essentially gets wrapped up in the whole “Give a man a fish” thought process, a coach wants to equip the team or individual with the skills to solve – not just this problem but the next problem and the one after that. A coach may very well know an answer to the problem described, but the agenda of a coach is to grow the team into being able to solve the problem, or at the very least to understand why a particular solution may be appropriate.  This can lead to confusion and frustration especially if the problem is causing pain or costing money. The team often want the problem solved far more than they want to learn.

A coach may ask questions that guide thought processes or sow seeds of ideas, they may point out smells or examples of behaviours that may be dysfunctional and warrant further thought, all this is intended to focus attention where it can have the most impact, but all without without explicitly solving the problem.  But when the team doesn’t understand this relationship it may appear that the coach is not helping, after all the coach may appear to only identify problems and doesn’t offer solutions.  This a common failing of coaches and of me in particular. There is a certain irony that one of the most common coaching guidance I give is around getting to understanding the why of a situation but I sometimes miss explaining this vital information when it relates to my coaching.   But when you coach multiple teams it is very easy to assume that everyone understand the coach relationship and this can lead to confusion and frustration.

file-21-09-2016-15-57-29

Coaching example

A very useful example is a situation where two people on a team are having interpersonal issues, Wendy continually leaves a mess at a pairing workstation and this drives Paul crazy, he gets frustrated and seeks out a coach and asks the coach to help. The coach will very likely ask if Paul has discussed this with Wendy and if not why not. Paul may ask the coach to speak on his behalf or to mediate, but again the coach may suggest that Paul should act alone. The coach may offer guidance on how to have difficult conversations (There is a great book on this subject: Crucial Conversations) but it is not the Coaches’ role to be mediator or to engage in conflict resolution.  If the matter is more serious they may refer the issue to HR just as any one else might but it is not the Coaches role to solve the problem or to get involved, merely to equip the person with the tools necessary to solve their own problem.

Levels of Coaching

If you consider the coaching on a one-to-one level it may be easier to see how the different levels of coaching are applied and when or why different techniques are applied.

If we take writing a first draft of a user story as an example.

  1. At one end of the spectrum the coach could ‘teach’ or talk about general story writing techniques and practices and give examples.  (Teaching) abstract ideas – blogging, courses, lectures, presentations etc
  2. Or it might be useful for the person being coached to work through a generic example with the aid of a coach (Training). Workshops or interactive activities such as games.
  3. Or it might be useful for the person being coached to work through a real example with the coach available to ask questions or the coach asking questions and offering encouraging ideas (Coaching/Consulting/Advice)
  4. In some cases the coach may sit with the person being coached as a partner sharing thoughts and ideas in a balanced way sharing the work (player coaching/mentoring)
  5. At the other end of the spectrum it may be that the coach actively participates in a pairing situation and shows the person being coached what is being done and explaining why.  – At this point the line between coaching and doing is a line in the sand and depending on the engagement level of the person being coached the level of learning and improvement may be negligible.
  6. And finally the coach does the work on behalf of the team/individual even though the team could do it for themselves. At this point there is no coaching value at all.

coaching

Of these five levels most Agile Coaches operate at levels 2 and especially 3, occasionally in 1 and 4, but 5 is unusual, certainly in my current role we explicitly say that we shouldn’t ‘do’ and if we stray we should be aware that we are no longer coaching.  In contrast a Scrum Master spends more time at 3 and 4 and often at 5  or even 6 – resolving impediments, producing metrics etc. But the overlap between the roles is subtle and there is no hard line. It is more a question of the intended outcome, rather than how it is achieved.

Reality

Of course the ideal and the reality can be quite different, I have been giving some product owner coaching recently and this is a double edged sword, the product owner aspect of software delivery is one of my favourites and I get enthusiastic. So I have been helping write story maps, and identifying personas and writing stories but every once in a while I’ll start doing, throwing out my ideas, making corrections without discussion and my biggest sin, taking over at the keyboard!  Thankfully usually one of us will spot it quickly and non-verbal cues will put me back in my coaching box.

My summary is really that not understanding the goal of the coaching leads to all sorts of problems, the teams facing a particular problem may feel they are not getting the assistance they need. It may be difficult to measure whether a coach is effective when they go out of their way not to ‘do’ something. The role is both very broad and very misunderstood.

But when the role is understood and when those being coached understand the relationship and the value of it, the situation changes drastically. It is a hugely rewarding role and the relationships can be fun and fruitful. When you accept that you are expected to solve your own problems (with guidance) it can be very empowering, a coach becomes someone that can help YOU expand YOUR understanding and ability, but credit belongs to you, not to the coach, they just point the way – you have to do the work.

Will Agile lead to the end of gender bias in IT?

pairing
This is a touchy subject and one where I realise I am treading on thin ice by making sweeping generalisations on an emotive topic, however it is a topic that needs addressing.

Surveys show that while the professional workforce in the USA is composed of 57% women – yes that’s right men are a minority.  In computing fields, the numbers are very different where only 25% of the computing related workforce are women – anecdotally the number of programmers is closer to 1 in 10 but there is a lack of data on this – one recruitment agency quoted around 10% of programmers placed were women.

So why the big disparity?

It may not be what you think, whilst discrimination may occur in the workplace, it’s impact is not statistically evident. If you look back to university only 25% of computing related degrees are awarded to women but again women account for approximately 55% of all graduates. So the workforce statistics almost exactly match the university statistics. This suggests that the impact of any discrimination or negative presentation has occurred (mostly) prior to university. My female friends and co-workers tell me that subtle discrimination is prevalent throughout their lives and this can lead to life choices being swayed by that, but that discrimination direct and indirect still regularly occurs.

Exclusion from computing and software is a choice.

Women have effectively self-selected to avoid the profession, so the real question is not why are women excluded, but why do women feel excluded or are simply not interested? Do social pressures on both women AND men dictate their career choices. Men statistically are drawn to the higher paying professions, so perhaps they too feel the social pressure of a different kind and are possibly selecting careers based on potential financial reward. Women seem to be drawn to careers that are perceived as more rewarding (vocational) but less financially rewarding, so it could be considered that in some respects women have greater freedom of choice (lack of social pressure to earn). 

However, the choice to enter software careers may well be the accumulation of negative influences discouraging women, or the lack of female role models, or male dominated media presentation of the industry. We need to understand what happened in their early lives that discourages women from entering what is generally a rewarding career path.

I have heard people suggest that it is a boys club and they don’t feel welcome, but the same could have been said about medicine a few years ago, in the UK in the 1960s only 10% of doctors were women, by 2017 it is expected that there will be more women than men and in the under 30s women outnumber men 61%-39%.  The USA is a little slower but women account for more than 1 in 3 and this number is growing. The latest figures show 48% of medical students are women.

The one hypothesis I have heard that resonates with me (and beware the man that uses generalisations) – Is that there is a tendency for women to measure their self-identify in the context of their relationships, their cliques, teams, peer groups or family. They find pleasure, reward and satisfaction from working in groups or choose professions that are rewarding.  Whereas men more often see their concept of self as measured by career status or in their work and select a career based on earning potential.  So women generally prefer work that involves people, whereas this may not be a priority for men.
Please do not see any implication that one of these outlooks is better than another or that it is a rule to be applied, I see them as different choices and priorities neither is right or wrong or better or worse. I offer them as generalizations that may help understanding. In effect both genders behaviour may be the result of social conditioning.

Whilst this is likely just one factor in a complicated decision I feel it is a reasonable hypothesis to explore. We are coloured by our experiences and this reflects what I have observed in the workplace, and in my opinion mixed teams are so much better: they are generally happier more productive and better at interacting with 3rd parties – compared with single gender groups.

So how could Agile help?

Education and the media present software and computing as being a solo activity, and worse as anti-social.  Images of men surrounded by energy drinks working all night on their own.  For socially stimulated people that is an unpleasant and negative impression.

The reality with agile teams is so radically different from this.  The coding element of software creation is actually much less than people realise, and even then it is generally not a solo activity, pairing is now prevalent which means you are rarely if ever working alone.  Software is very much a team activity with group discussions dominating the working day. Scheduled short meetings or impromptu discussions intersperse the day and rooms are rarely quiet. Software is not just coding, Agile encourages cross-functional teams and your typical team member may be doing analysis, design, development and QA, likely also support and customer interaction. And I may have mentioned this already – rarely alone. All of these activities are team activities.

Software development is a team activity.

For a group that measures self-identity based on their relationships I am hard to pressed to think of a more social activity than an agile software team. It is one of the most social structures I know, to the point where it can be difficult to disassociate the individual from the group. It is very difficult to measure individual performance. The true measure often comes down to how well you integrate with the team, and how well you can communicate.

As for unsociable hours, that is a thing of the past. Agile promotes sustainable pace, that means that teams set a pace that can be achieved week after-week, after-week, no more death marches, no late nights. In fact most agile software groups tend to have very flexible hours, with the weight put on to team contribution. Some teams choose to work early mornings and leave early, others later in the day.  And with pair-switching happening frequently and effort put in to knowledge sharing – avoiding single dependencies and silos it is actually pretty easy to have part time people that are effective and active members of the team with little if any detriment.

Diversity

And then of course there are huge benefits of having diverse teams. Teams of mixed genders are more effective, a lot more effective.

So if we accept the hypothesis that women have the wrong impression about software development and that the software industry post-Agile is more inclusive, more social, more compatible with part-time work and flexible working.  And that the industry could benefit hugely from a more balanced and diverse workforce.  How do we get that message out?

How can we fix the negative perception?

How do you persuade education – both university level and earlier, to teach that software is a team sport, that the most important skills for success are the ability to work well with others to be team players, cooperators and collaborators.  And how do you educate the media to stop presenting IT professionals using negative stereotypes? 

Software development is fun, a typical agile team environment has a buzz: talking, laughing, sharing ideas, collaboration and caring for each other. Not that they are not professional, most of the buzz comes from the desire to do the right thing for the customer and the users of the software. The buzz comes from the thrill of creating something new and amazing with a group of people you respect and admire and enjoy their company.

Taking the game to the students

I’d like that to be taken to the classroom, get the message out that in real life you don’t work alone you contribute to a group, that in software development especially you succeed because you are a team and the better you work together the more we can achieve.

As part of our Agile training we play a variety of team learning games that simulate iterative development and learning. They promote team thinking and team retrospectives how working together you can be more effective and how by reflecting you can improve.

I’d like to take a cut down version of that activity to some schools and see if on a small level we can change young people’s perceptions of IT.

Of course the media could help with some better role models and presenting software development in a more positive light, but that may be too much to hope for.

 

Self-Organisation vs Human Nature

I love the notion of self-organising teams, the belief that if left alone the team will pull together and solve the problem at hand. I also love the notion that a team doesn’t need named roles and that a team should be multi-skilled and can and will do any and all tasks necessary to deliver the work.  As a model this does work, I have seen some great teams that can and do achieve this. But I don’t think this is the norm. There are certain foundations necessary for this model to work and for far too many teams they don’t have the necessary pre-requisites.

The team must have (or have readily available access to) all the skills.

The first is to have ALL the necessary skills on the team. Which may sound obvious, but when arranging and staffing teams we will generally ensure that a couple of the core skills are present and overlook or underestimate the importance of other skills. Or some of the other necessary skills are a lot less tangible and quantifiable, ‘softer’ skills, so we trivialise or undervalue them, when actually those less defined skills are likely to be the ones that mean the difference between getting by and excelling.

I doubt many question the claim that a software developer is a specialist skill, many people can have a go at coding but most serious products require a deeper level of understanding of the code than a casual understanding. I personally believe that the role of QA is similar, many can do the basics and run test cases, but a QA is a specialist skill and those gifted at it possess a perception that few developers even grasp let alone can mimic, they see a problem differently, a Dev tends to see a solution, a QA will see how it might fail.

Similarly with design, few Devs could design their way our of a paper bag, interfaces designed by engineers must give designers nightmares. I have seen engineer designs where every function of the system is displayed on one page giving a casual software tool the appearance of a complex flight control interface. That’s not to say that some Devs don’t have design skills, but generally they are lacking. And then there is Product Ownership – the term for a collection of tasks and skills that I feel is generally drastically underestimated and a skill set that is rare in your typical Dev. In my opinion it is potentially more specialized than that of a developer or QA, and is rarer to find on a typical team composed of Devs and QAs. (Named roles or otherwise)

Drawing the expected value out of a customer or stakeholder and verbalising it, is a skill, translating that into a story can be time consuming and painful, but when done right the Devs can fly and the stakeholders are happy. When done badly the developers churn and the stakeholders grow frustrated. Product Ownership is the vanguard of Agile software development. Being able to articulate a clear vision, and present unambiguous goals and priorities, to write stories that express the value of the work without imposing a solution on the Devs can mean the difference between a goo and a great product.

To do all this requires someone that can communicate effectively with the customer and stakeholders and then transfer that information clearly and effectively to the team, to ensure that the customer is clear on priorities and is happy with the progress requires soft skills that are not at all common. This is an extremely difficult set of skills to master. To simply assume that a team will inherently possess the skills necessary to fulfil this role amongst themselves is inviting disaster. To assume that the customer is clear on their intent or direction and can express that need to developers who may not possess the experience or will to probe and challenge to identify the true need is simply inviting disaster. Product ownership skills and experience is not an automatic side effect of being a Dev – far from it.

The team must be motivated to do any of the necessary tasks.

And secondly there is Human Nature.  This may be seen as a generalization and it is a generalization that I have been trying for years to break, and to be fair there are some team members that do manage to evolve beyond their labels and become more cross-functional team members. Many will take on tasks relating to DevOps or DBA or even some of the other core skills on a team such as Design and QA but, BUT…

What I find more often than not is that if people are left to their own devices: Devs want to code, QAs want to test, Designers want to design and NOBODY wants to do documentation, administration, or talk to stakeholders or to integrate other people’s code. Maybe an over generalisation, but not too far off the mark.

The result..

And of course the whole point of self-organising teams is that they ARE left to their own devices. So we have a bunch of self-organising teams that have a mix of being unable or unwilling to do all of the tasks necessary to deliver the product.  Obviously some do muddle through and when push comes to shove they will step up and get the job done. But many just don’t want to and will either leave it to others meaning that the more ‘Agile’ team members get all the crap jobs, or more commonly I seem teams finding ways to stay busy to avoid doing the tasks they don’t like or facing the problems the team would have if they actually confronted them.

In the book the Lord of the Flies, there is a goal – a signal fire, but the boys become busy and preoccupied with the more interesting tasks and having fun, thus neglecting the fire.

I see non-urgent (and not prioritized) features getting worked on, scope creeps all the time. The ‘build process’ becomes gold plated, and the team starts a whole bunch of ‘spikes’ that take far longer than should be expected. Everyone is ‘busy’ but no one is delivering value (nobody is tending the fire). All because the team is subtly, maybe subconsciously avoiding tasks they don’t like or don’t feel they are able to do. This may sound harsh, but I have seen this behaviour far more often that I would care to count.

So do I advocate self-organized teams? Do I advocate named roles in teams?

In my experience Product Ownership requires skill and dedication. Assuming a team possesses it simply as an after thought or assuming it is a secondary role is very damaging. For a newly formed team/project someone skilled in Product Ownership should be primarily focused on that.(Not necessarily in a named role, but certainly specifically assigned the responsibility). But that assumes there is someone on the team who possesses those skills.

It should be part of the responsibilities of that role to spread that knowledge and share those skills to avoid creating a silo – (why not pair? the way you would a Dev role?) Please note I am not saying this is essential, but I am saying that it can vastly increase the effectiveness of a team. and fears of a bottleneck are unfounded, a focal point and a single filter may actually be a benefit rather than a hinderance.

In a similar vein I think that in the early days of a team of a project a flow manager/coach/Scrum Master type role can help a team form and become effective far quicker. They encourage the team to be aware of the less desirable tasks and to emphasise the importance and value of getting them done rather than focusing on less important tasks. Helping the team understand the difference between the feeling of being busy and actually delivering value to the stakeholders/customer.

Understanding the difference between a necessity of having someone in a role and the benefit a team derives from having someone in a role are often confused and muddled and that is something I intend to return to in a future post.

Summary

I do believe teams can be self-organising and I do believe that named roles can sometimes lead to unnecessary siloing – but that is not a certainty and that goal should not dwarf the desire for an effective team. I don’t believe that throwing a team together and taking away titles will magically make a self-organising team. Self management is a learned skill like any other and takes time to learn and to perfect.

I also don’t believe that taking away named roles removes the need for specialist skills. Saying we don’t want a named QA or Dev or PO doesn’t mean you don’t need those skills on the team.

Understanding which skills are needed is vital for an effective team, whether it is self-organised or not.  But even with the necessary skills the team still needs to understand the direction (vision) and be motivated to reach it.