A question I have been hearing a lot lately is how do you know whether an employee is putting in their hours, or not slacking off. This question seems to be particularly concerning for people in the context of working from home where the perception is that it is more prevalent.
The irony here of course is that being in the office is no measure of not slacking off, there have been many books written about different ways you can slack off whilst appearing to be busy.
I have heard tales of the productive worker that works hard all day long only later to discover they were working on a side project or even for a second employer. Long lunches, toilet breaks, extended coffee breaks, fake meetings, or just browsing the internet or discretely playing games on your mobile phone. Physical presence in an office is not an effective measure of whether you are slacking off.
The average American worker admits to wasting 2.09 hours a day, excluding lunch, according to 10,044 self-selected respondents in a survey released by America Online and Salary.com.
What does it mean to Pull your own weight?
Let’s take a little aside and explore the phrase “pulling your own weight” there are a few suggested origins of the phrase but the one I like best relates to the English Long-bowman, to be considered an ‘archer’ you had to be able to “pull your own weight” Longbows had a draw of up to 180 Lbs. You really did have to pull your own body weight. An experienced archer could fire 12 aimed shots in a minute at ranges of 200-300 yards, although in battle they were expected to fire at a slower ‘sustainable pace’ of 6 aimed shots per minute. For context a modern bow draws at around 40 Lbs for women and 60 Lb for men.
In a modern terms we usually mean contributing proportionate to your role. We tend to think in terms of productivity and output. Despite this we often tend to focus on hours spent – hence the rise of slacking off at work, even though we can easily slack off time without being noticed, but it is far harder to slack off output or deny outcomes.
So how do you know whether your employees are working?
Personally I think that is the wrong question. When you explore deeper you discover that the employee surveys on why people slack off are far more interesting than the ways which they slack off. Many described being bored as the primary reason, others felt that their job was easy. So it seems to be a question of engagement.
I suspect in other cases it is that you have hired the wrong people and better filtering at hiring would result in a more motivated workforce. Ironically when you have a motivated workforce getting them to take a break becomes more of a challenge.
So I guess what I am saying is that if you are a leader that is worried about whether your staff are working, then the issue is far more likely to be with you than it is with them.
Hire the right people. (Hungry Humble, Smart)*
Be clear what is expected of them.
Help them understand why it is important – and who benefits from their work.
Be interested in them as individuals.
Interestingly all of those actions fall to the leader rather than the employee.
If you follow these steps then I suspect that you won’t need to worry whether they are pulling their weight, you will be too busy trying to keep up with what they can achieve.
Where does the responsibility lay
If your employees are slacking off then it is a failure on the part of the leader not the employee. So when you hear someone ask how they can tell if an employee is doing their hours and not slacking off. Ask them if they have hired motivated people they can trust? Have they given clear objectives and set expectations? Do their employees understand the context and purpose of their role? Do you value them and do they know it?
If and when you do see someone slacking in a damaging way, take a look and see if the route cause is one of these 4 issues, you’d be surprised how often it is one of them.
What I am confident of though is that any efforts to monitor time in the office (or home) – such as time clocks, pressure sensors on seats, keystroke monitors, swipe cards on toilets, or a foreman to watch people – and of course a foreman for the foreman – obviously you need someone to watch the watchers. All will have minimal impact on people slacking but will have deeply damaging impact to productivity.
*Taken from The Ideal Team Player, by Patrick Lencioni
It may sound overly simplistic but in my experience products generally succeed or fail in correlation to the effectiveness of Product Ownership on the team. Mainly because we under-appreciate the importance and the difficulty of the Product Ownership aspects in the product creation process. In my opinion the choice of this role is far more important than the coach or other team members. The role is full spectrum, they go all the way from discovery to delivery and more.
Ironically, we tend to think of software applications as being primarily technical objectives, our focus is too often on the quality and ability of the engineers, the architecture and design. We will spend time on process and optimization and efficiency. All the while forgetting that the most common and most consistent failure of all software products is that no matter how good the quality, how optimized or efficient it is, or how good the engineers are that built it – if you build the wrong thing it is a failure. A perfectly designed but unused product is worthless.
History if full of great products that missed the mark, how many apps have you downloaded to your phone that are no longer used or were never used after the first 30 seconds. There are many many more products that fail to ever get in the hands of customers at all. Internal IT products are often culprits of this, the assumption seems to be that because the users are forced to use the product we don’t have to actually ask them what they want or how they will use it, we build great products that don’t fulfill the actual user need.
I think probably my favorite and most over used quote is:
There is surely nothing quite so useless as doing with great efficiency what should not be done at all.
Peter Drucker
I use the quote far too frequently but in 25 years developing software this remains the most frequent sight I see, more products fail for not meeting the most basic customer needs than for any other reason. And yet when I say this, it generally gets scoffed at, until you start asking how many people have worked on products that have been abandoned or shelved mid development. Teams rarely believe their product is at risk of being cancelled, or are too far removed from the customer to appreciate that the user liking and using the product is infinitely more important than whether they are efficiently re-using a section of code. We have created a mindset that ‘done’ is delivering code. A product/feature/story is only really done when the customer is using it.
Product Ownership does not need to be a single person in that role, but it should be a mindset within the team. Ideally I’d love for this to be a shared responsibility. Unfortunately in my experience a true appreciation of Product Ownership is as scarce as Hen’s Teeth, and generally unappreciated and vastly underpaid, those that do it well make it look easy and doing it badly or being indecisive can really destroy a product so it can be a risk to spread the responsibility beyond one person. I have heard people talk of teams where the teams do it well and they don’t need a PO, but I have yet to see this for myself. Because of this experience I think of the Product Owner as the most important ‘hire’ for the team, getting the right person in this role can be crucial to the success of the product.
A good PO these days is hard to find…
So why is a good Product Owner so hard to find and what makes the role so difficult?
1: Differentiating what is needed from what is wanted
A significant part of the role is identifying what is needed to solve your users problems or to fulfill their needs, to enable them to be better at their job, or to maximize their fun or relaxation. The role is about understanding the problem and creating a vision of how that could be solved – not the technical solution but discerning the true need or true problem.
Henry Ford stood next to his ‘Faster Horse’
If I had asked people what they wanted, they would have said faster horses.
Henry Ford
The reason this skill is so tough is that users rarely know what they need, typically a user’s vision is constrained by what they currently do. As a result many products become re-works of a paper system or re-engineering an old system. A poor product owner gives a customer what they want or what they ask for, a good product owner listens and watches and blends wants and needs to solve the customer’s problem and give them what they need.
I often seen backlogs that are full of stories that are unfiltered customer requests, it is lazy and it is easier to do what is asked. But to find what is needed typically requires experimentation, feedback, conversations and observation. It is far harder to build what is needed than it is to build what is asked for. Similarly this can manifest itself when department managers decide what their team needs or wants without involving them in the discussion, a good Product Owner will spend time with the users of the product and ideally see how they use it.
A Product Owner with the creativity, the initiative and the Vision to create a great Product is worth their weight in gold,
2: Understanding what is required to create a successful application
A second aspect of the role is the one I see most frequently overlooked. Perhaps because of the emphasis on 1, the need to understand the business, I see people choosing someone from the business to become the Product Owner, their knowledge of the business is seen as their primary qualification and in many cases their only qualification for the role. And worse they are often asked to do the role in addition to their normal job.
However, a great Product Owner understands not only what to build but is familiar with the development process, they understand the ebbs and flows, they understand the implications of technical debt, automation and testing. The understand how crucial it is to have working software in the hands of users as soon as possible. I am sorry to say that business POs often lack this knowledge and experience, they will mistakenly perceive a desire for a fully working product rather than appreciate the value of early feedback. Many are plagued with the last bus syndrome, trying to include every imaginable feature rather than working towards a minimum feature set to get feedback and derive value early.
Personally I’d invariably trade an experienced Product Owner with zero business knowledge for an expert in the business with zero software delivery experience. Business knowledge can be gleaned from effective conversation, observation and feedback. The understanding of a good Agile Software Development lifecycle is far harder to learn and there is no substitute for experience.
Typically the best products result from experiments, reviews and feedback, a willingness to be flexible and respond. The other disagreeable quality of a Product Owner taken from the business is that their knowledge is about how the work is done now, and they are often blinkered to the possibilities.
Remember that the Product Owner sets priorities and interprets the Vision, they have more influence on the product creation than anyone. Their choice of priorities can profoundly impact the value, and the quality of the product. If they lack the understanding of the importance of testing, feedback and good software principles it can lead to conflict and disharmony in a team.
3: Communicating effectively with both technical and business stakeholders
Finally there is a need for effective communication. We always talk about effective communication to the point that it becomes background noise. But the importance cannot be overstated.
A great Product Owner, listens, they observe, they probe and they reflect. The ask for feedback and they read between the lines, they watch body language, they see and hear what isn’t said as much as what is said. When it comes to understanding the user they have great attention to detail and they look intently for pain points and points of pleasure, they are looking for a way to serve their users in the best way they can. Most of us think of communication as speaking, but for a Product Owner watching and listening are so very important. Empathy with the user, the customer and the ability to communicate using their terms and understanding their domain and conversing with them in a meaningful way is crucial, and if you don’t understand the terms develop an attitude of attentive student ask questions and show you are interested and are learning.
A great Product Owner learns to say ‘No’ powerfully respectfully and does so in a way that conveys they understanding to the person asking, a great Product Owner should not be seen as an obstacle or a hurdle but a steward of good decisions. The word ‘No’ should be delivered in a way that leaves me feeling confident that the Product Owner will deliver the best product within the parameters and leaving me confident that this decision is right even if it is not what I initially wanted. The Product Owner should be able to convey the implications of saying ‘Yes’ so that I understand why I am being told No. A great Product Owner has any number of tools that can help people see this and yet we regularly see backlogs full of feature requests that will never see the light of day because the PO doesn’t feel capable or sufficiently empowered to say NO!
But the PO must also communicate with the development team, they must understand technical development terms, to have a grasp of the technical implementation, even if they do not have authority over the ‘How’ I’d expect them to have a vested interest in understanding it. They also need to be able to communicate the business needs and the business terms in a meaningful way to the development team, This requires a versatility in speech and communication that is unusual to say the least. Being respected and understood by both the business and the technical team is a major feat, and as we all know any cloistered group speaks in three letter acronyms that only they understand and the audible sign when they have to explain to an unlearned outsider can demoralize the best of us. Do not underestimate this ability.
But there is more, they need the creativity to communicate design ideas or if the ideas come from others the scope to understand that creativity, to imagine what could be and express that to the business and to the technical team. And then we get into the really tricky realm of the stakeholders as opposed to the users, this generally is the group that funds the product, they want to see progress, they want to see good stewardship of their investment, they may ask for forecasts and may even press for commitments.
We have now loaded our Product Owner with the need to communicate with senior people that make financial decisions, to express Risk and Forecasts in a manner that it concise but meaningful, we want to be transparent and informative, but confident. If we are using forecasts especially mathematical forecasts we had better understand them and be able to back them up with explanation and confidence. A Product Owner my stand their ground in the face of authority and speak truth to power. A Product Owner that makes unrealistic commitments or promises, will lose the confidence of her team and her stakeholders in a flash.
If a Product is to be sold it is likely that you will need to be involved in Sales and Marketing, which brings a whole host of other skills and communication issues to bear, understanding the implication to the market, and how you measure that and how you engage with that is a new realm of understanding and confusion.
A great Product Owner is a master communicator, they have an insatiable desire for knowledge, to understand and be understood.
Summary
As you can see the skill set of a great Product Owner is monumental, and yet the good ones make it look easy. If you have a mindset suited to Product Ownership it is likely you already have good communication skills and enjoy learning more domains.
It is likely you are the sort of person that thrives on the delivery of a product and revels in the feedback, enjoying the flexibility and change, is unmoved at the thought of redoing something twice or even more to get it right.
Solving problem is a thrill and being able to see beyond the obvious and draw out information from users and then present something back is a joy.
That doesn’t mean it isn’t incredibly difficult, overwhelming at times and sadly unappreciated, and very often underpaid.
At some point the industry dismissed all these skills as unimportant and we see a flurry of Product Owners that write stories exactly as dictated by users, that input data into forecasting tools without the vaguest notion of what the forecasts mean or how they are calculated.
As I said at the start a great Product Owner is the lynchpin of a great Product, we should be seeking them out and rewarding them appropriately, you will be amazed at what can be achieved with the right person in that role.
Over the years I have discovered that the more I learn on any subject the more I come to realize that I know very little, it doesn’t seem to matter how much I study or how much I learn, the awareness of scope of my ignorance grows far faster. Does that make me wise or just aware that I know very little? I suspect that I’m slowly fighting my way out of the valley of despair.
No need to improve
One of the most challenging aspects of being an Agile Coach and working with teams is that to improve you first need to accept that there is room to improve. There are a some teams and team members that believe there is nothing more that they need to learn, they are so supremely confident in their own capability and knowledge that they refuse to consider that there could be a better way to do things than the way they have always done things.
On the other-hand I can’t be confident that there is a better way, only that we won’t find a better way unless we look. I don’t like the notion there is a ‘best practice’ as this limits our thinking. But this puts unwavering certainty that this is the ‘best practice’ against encouragement to explore the possibility of a better way, certainty is very powerful.
Sometimes this ‘certainty’ is founded in fear, especially when dealing with transformations where former roles are called into question, I find this an understandable reaction, but the situations I struggle with most are the team members that become blinkered to opportunities, they have found one way that works (even poorly) and simply are unwilling to try anything different. Their Ego, prevents them considering anything else.
As a coach I have no desire to force processes or ideas on people, only to open their minds that there could be opportunities and alternatives. So it can be heartbreaking when people refuse to even consider alternatives, or worse impose their views on others through sheer force of will.
Perhaps I am mistaken and maybe the right answer is that if something isn’t broke don’t fix it, but that notion doesn’t sit well with me.
So how do we persuade people to open themselves up to learning new things?
I recently had an experiences that I found tough, there was a QA who refused to ‘leave his column’ on the board, he would not do anything that was not ‘testing’ and resisted anyone working with him in ‘his column‘ thankfully it is not often I see that level of obstinance. But this situation was further compounded by the rest of the team enabling his behavior. The developers were all too happy not to be involved with the QA aspect and were seemingly unmoved by his unwillingness to cross boundaries.
The QA column was regularly a bottleneck but rather than addressing this the team wanted to mask the issue by pushing cards through and raising new cards for rework. What was tough was that the team saw no need to experiment with alternative ways of working: suggestions included either helping the QA, or even getting the QA involved earlier, and despite raising QA as a bottleneck repeatedly in retrospectives the team didn’t want to change behavior even in the form of an experiment.
As a coach you can shine a light but not force a change. I felt the team was capable of far more but the team were getting things done and were seemingly content with the status quo. For me this is the dark side of coaching, where you must watch a team not reach their potential, out of respect for their independence. Ultimately it is a trust issue as things so often are.
Ownership of Columns
In general I dislike explicit roles when there is a shared responsibility, and I dislike the notion that a column on a board is in anyway related to a person or a specific role, the board should reflect the progress of the work (stories) not ownership of the work and when the two become muddled people become defensive and territorial.
When there becomes an association between a column and a person the focus moves from getting a story done as a team, to moving a story on to the next column, we switch our context of efficiency to a narrower view.
This is often seen as a subtle and unimportant distinction. But when the team loses a cohesive sense of ownership for getting to done and can hand off responsibility to another sub section of the team, bad habits emerge. At it’s worst I have seen teams (thankfully not one I coached) where at stand-up one part of the team will brag about how many stories they are ahead of an other part (be it front and back end or Dev and QA). In one extreme case I saw a team decouple testing from development by splitting stories and I overheard one standup where the developers were gleeful that they were now 3 sprints ahead of testing (the sprints were 3-week sprints). It is 9 weeks before they will see value from their work or even know if their work had value, and yet they were so proud.
Dunning Kruger Effect
Adjusting your mindset to one of learning rather than certainty can be tough, especially for those that grew up in a culture that rewards confidence and certainty, but accepting that you don’t know everything and being aware that there is always the potential to improve can enable you to become far more capable, the only thing stopping you is your ego.
The whole problem with the world is that fools and fanatics are always so certain of themselves, but wiser people so full of doubts.
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?
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.
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.
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.
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.
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.
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.
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.
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…
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.
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
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.
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.
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
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.
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.
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.
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.
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.
“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.
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.
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
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.
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)
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)
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.
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.
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 myideas, 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.
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.
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.
John Yorke 