Try treating programming as a socialising* activity that throws off running code as a byproduct.
Try treating programming as a socialising* activity that throws off running code as a byproduct.
The march of time seems to have judged “psychological safety” as a passing fad. Not that it’s an irrelevant idea – far from it.
I suspect psychological safety gained some acclaim because everybody wanted it for themselves. “Yes, please. I feel anxious, exposed and at risk when I speak out, so I’d really appreciate some psychological safety, thank you.”
We’ll skip over the unlikely prospect of any managers being interested in providing an environment of psychological safety (why would they need to do that?) and get straight to the irony.
I’ve spoken with some number of colleagues who all attest to feelings of anxiety, being exposed and being at risk of judgement by peers in the software community when they speak out about certain, possibly contentious or unpopular issues.
Aside : I suspect it’s more often fear of the consequences of speaking out that’s at the root of these anxieties, rather that fear of being judged per se.
The irony being, of course, that whereas individuals are fine with accepting psychology safety provided by others, they’re far less interested in extending psychological safety in turn.
What are you doing on a daily basis to extend psychological safety to others?
http://www.psychologytoday.com. (1 June 2015). Tired of Being Judged? Try This. | Psychology Today. [online] Available at: https://www.psychologytoday.com/us/blog/longing-nostalgia/201506/tired-being-judged-try [Accessed 13 Sep. 2021].
NOTHING we do with team topologies negates the fact that we’re still mired in another local optimum.
Taking on a new role, working with new people. It’s a situation we’ve all experienced, maybe multiple times. And as careers progress, these new roles come with more responsibilities, more scope. Especially in connection with people. We might call these “command” roles. Or at least, “leadership” roles.
And we’ve all experienced, or will experience, the nervousness consequent on preparing to face new colleagues who are almost bound to be sceptical about having a new incumbent as their leader or commander. How to win over these folks? Flattery, favour or folksy friendliness isn’t likely to cut the mustard.
How about showing people that we know what to do with their abilities, expertise and enthusiasm? So they have some confidence that when the chips are down, their efforts won’t be wasted in some doomed enterprise? Here’s a little speech that might play well at the get-go of that new role:
I will never lead you into an action unless I know we can succeed at it. Your job is to become such a brilliant team that there is no action I can’t lead you in to!
We’re not in this for glory, ego-stroking or self-gratification. We are in this to meet the needs of all the folks that matter – any way we can.
Do sports teams “work” together or “play” together?
And, incidentally, what’s so interesting about team performance when it’s the whole system that’s the kicker?
“The greatest determinant of organisational performance is the way we think about the design and management of work.”
~ John Seddon
And, therefore, the greatest determinant of the performance of self-organising software development teams is the way those teams think about the design and management of their work.
Aside: For teams and individuals that are not self-organising, the original quotation pertains.
I suspect many developers and development teams might see “Memeology” (my new book) as irrelevant to them. As a book that lists memes of little interest, and as a book that surfaces assumptions and beliefs more relevant to senior management – which, to be fair, is the books primary audience.
And yet, as organisational psychotherapy speaks to an organisation’s collective psyche, “Memeology” invites addressing of the collective assumptions and beliefs of everyone in the organisation. So, as far as involving people in the discussions around “Memeology”, I’d suggest encouraging everyone to become involved.
In most organisations, however, local rules apply. Different groups may well be interested in memes specific to their own specialisms. For example: Finance, Operations, Logistics, HR, and yes, Product and Software Development.
I’m chary of promoting local optimisations – for example, the improvement of software development practices in isolation from the rest of the organisation. But developers in Analytic-minded organisations outnumber by far those in Synergistic-minded organisations (the latter being more prone to taking system-wide issues into consideration). Are we to deny a self-help book such as “Memeology for Developers” on the grounds that discussing development-specific memes in isolation might perpetuate specialisms and concomitant local optimisations confined to the “development silo”?
Here’s just a few of the many memes that “Memeology for Developers” might cover:
I have a long list of such memes. I’m sure you can suggest memes for such a list, too.
Does the idea of “Memeology for Developers” pique your interest? Would it be a useful book, promoting as it would not only the surfacing and reflection on the assumptions and beliefs developers hold in common, but also promoting experimentation to improve self-organising software teams and the way they work?
I’d love to hear your thoughts.
I’m a little prim and proper. In that I like to do things properly. And I find comfort and fellow-feeling in seeing others doing things properly, too. Some have suggested this looks a tad OCD-ish.
For me, “properly” means with intentionality, deliberateness, and a modicum of tidiness.
“We are what we repeatedly do. Excellence, then, is not an act, but a habit.”
As regards software development, some folks conflate “properly” with some specific approach (waterfall, Agile, software engineering, software craftsmanship, w.h.y.). As if there’s “One True Way” and all other approaches are the work of the devil.
I choose to eschew faith and dogma, and focus on what works. Where “works” means “meets the aggregate and individual needs of the Folks That Matter™”.
“What works” can vary – depending on a multitude of more or less regularly changing variables. (Implication: the approach must be as flexible as the dynamics of these variables).
And then there’s all those folks for whom “doing things properly” offers zero attraction. Pirsig guesstimated that these folks number around 85% of the species (Cf. Classical vs Romantic understanding).
How do you feel about doing things properly? And the folks around you?
Pirsig, R.M. (1980). Zen and the Art of Motorcycle Maintenance: An Inquiry Into Values. Bantam Books.
I’ve recently been writing a post on building high-performance teams (I’ve spent most of my career either building high performance teams myself, being part of a high performance team under construction, or helping others build high-performance teams). The post in question is rather getting away from me, in terms of length, and I might choose to convert it into a small book instead.
But I did want to post something on the topic, not least because during my research for the post I’ve come across so many instances of advice contrary to my own experience, advice which I believe if followed would undermine any such effort, and result in mediocre, under-performing teams, at best. Compared to what’s possible.
So, skipping over the definitions of “teams” and “high performance”, the rationale for teams, and the detailed ins and outs and how-to’s, in this post I’ll just cut to the nub of the challenge, as I see it: whole-part thinking.
Most teams I’ve seen being built exist as a part of a larger whole (team, development organisation or silo, company).
That larger whole usually holds all the aces when it comes to stipulating what is and is not permissible. Hiring practices; compensation practices; incentives and motivational practices; working practices; internal and external communications practices; management structures, doctrines and practices; ways in which folks can relate to each other a.k.a. social norms; influence over the workplace, tools and equipment; remote vs on-premise working; working hours and locations; and so on. All these and more are generally under the control of the wider organisation (sometimes explicitly, more often, implicitly).
So, the constraints on our team building efforts are legion. And these constraints are generally antithetical to our achieving high performance. For successful builders of high performance teams, the biggest challenge they have overcome is the challenge of circumventing these constraints, without alienating the larger whole (and the powers that be) to the extent that they lose their credibility and influence. And sustaining their circumventions, credibility and influence, over the long haul.
I’ve written at greater length about these challenges in my 2012 posts “OrgCogDiss” and “French Letters” (the latter specifically about Agile teams, but equally relevant for all kinds of high-performance team).
In a nutshell, then: whole-part thinking leads organisations to believe that a development team or silo is a more or less independent entity, masters of their own performance, and can be held accountable as such. In reality, the constraints of being a part of the larger whole impact teams to such an extent that they have little to no independent control over their own performance.
Organisations that truly value performance over rules change the rules (constraints) to enable high performance across the whole organisation. Many prefer to stick with their existing assumptions, beliefs and rules.
I guess most people, when they start a new job or client engagement, have in mind the things they want to do and see happen. Most likely, things they’ve seen or made happen in previous jobs or engagements. Along with, maybe, some things they’ve read or heard about and are minded to try out, given the opportunity. (And what better opportunity than the honeymoon period of a new job or client?)
We might choose to call this an agenda.
I’m no different, excepting perhaps the items that feature on my agenda:
Note: I’ve not included on my agenda anything about specific actions that I myself might want to do and see happen, beyond the items listed. Specifically, although I’ve written often about strategies such as Flowchain, Prod•gnosis, Rightshifting, the Marshall Model, self-organising/managing teams, the quality of interpersonal relationships and interactions, etc., I don’t bring these into my agenda. If folks discover these strategies for themselves, they’re much more likely to understand their fundamentals, and maybe come up with even more effective strategies.
The Antimatter Principle is the only strategy I’ve regularly written about that recognisably features on my prospective agenda, and then only by extending invitations to participate in that strategy. (Note: Attentive readers may just notice the tip of the Organisational Psychotherapy iceberg peeking out from the above agenda).
I’ve reached a point in my journey where, keen as my ego is to see all my ideas (strategies) made manifest, my experience tells me that’s not the way to go for the best outcomes for the community as a whole.
As for the Marshall Plan, I believe it’s best, in the longer run, to have the folks involved (in particular, the people that matter) do their own discovery and learning. Discovering for themselves, over time – through means they also discover for themselves – effective strategies for attending to folks’ needs (often including the principles underlying those strategies). I see my role in this Plan as supporting – in whichever ways folks request, or say they need – this collective endeavour. Such support quite possibly to include actively helping the discovery and learning, whenever there’s an explicit (albeit refusable) request for me to do so.
As I mentioned in my previous post, I’m just back from presenting an interactive session on Organisational Psychotherapy at Testbash Dublin. Some folks seemed confused as to the relevance of Organisational Psychotherapy to testers and the world of testing, so I’m happy to explain the connection as I see it. (And please note that many of my previous posts on Organisational Psychotherapy may also help to illuminate this connection.)
I’ll start by riffing on something Rob Meaney said during his presentation:
“Significant quality improvements [aren’t] driven by testing. They [are] driven by building relationships and influencing the right people at the right time.” ~ @RobMeaney #TestBash
Quality (and other) improvements come from improved relationships. This has been a theme on this blog for some years now. For example see: The Power of Humane Relationships.
I asked a key (for me) question during my session (several times):
“If we accept that (as per the Marshall Model) it’s the collective mindset of the organisation that determines its relative effectiveness, how do we propose to support the organisation if and when it choses to do something about its mindset?”
Unsurprisingly perhaps, I heard no answers, excepting my own proposal for a means to that end: Organisational Psychotherapy.
I wonder how many folks involved with testing ask themselves and their peers the question “How can our organisation become more effective at testing?”. Or, using the #NoTesting frame, “How can our organisation become more effective at delivering quality products and services?”
Organisational Psychotherapy is not just about improving product quality, however. Through improved relationships, and a shift in how the organisation relates to its people (i.e. from Theory-X to Theory-Y), the quality of life at work also improves. Put another way, we all have more fun, more job satisfaction, and get to realise more of our potential at work. Further, for all the folks that matter, their several needs get better met. And, as a bonus for the organisation itself, it gets to see its people more productive and engaged. What’s not to like?
I’ve also written elsewhere about using the Antimatter Principle in practical ways during software development. For example, during development we eschew requirements gathering in favour of incrementally elaborating hypotheses about the needs of all the folks that matter, and then conducting experiments to explore those needs. I can envisage teams that still need testers adopting a needs-focused approach to driving testing. For example, putting into place various means by which to answer the question “how well does our product meet the needs of the people that matter to us?”.
On a related note, some folks asked me about practical applications of Organisational Psychotherapy in their day-to-day work as testers. Here’s just a few applications which immediately come to mind:
I’d love to hear if this post has helped put my recent Testbash session in context.
I’m feeling discombobulated. Other emotions, too, of course. Both positive and negative. But for the time being, discombobulation predominates. I’m guessing some of you fellows might be experiencing some of the same sensations. Bruce Tuckman described this as common for groups in the “forming” stage – stage one – of his model.
Knowing it’s common, and even being ready for it, doesn’t seem to lessen its impact much, if at all. I just wanted to share, in case you felt it was just you. You’re not alone.
I’ve been trying to process and arrange folks’ recent comments, and form some responses. Many things are still in motion in my head, and my heart, but here’s the first clutch of thoughts:
I have little inkling as yet as to the kind of mental models fellows have about organising for collaboration. Do those models follow the Rightshifting distribution, or do we have a preponderance of more synergistic thinkers? I don’t know – but I’m looking forward to finding out. I’m assuming at least some folks will be coming from more traditional (Analytic-minded) backgrounds. In which case I guess it’s only natural to think in terms of “who’s in charge”.
Who do you want to be in charge? What does “in charge” mean? And what are the merits and demerits – a.k.a. consequences – of the idea of having one or more people “in charge” in any case?
Personally, the sooner we get to some effective, functioning self-organisation, the happier I’ll be. I have ideas, sure, but I’m betting everyone does. I have some notions of what we could be doing first (priorities). Again, I’m sure everyone does. Can I act on that? Discombobulation.
Who do you go convince that you have a good idea worth consideration? Who will give the green light to your suggestion and put things in motion?
And, above all perhaps, how does this question of “who’s in charge?” play into the bigger picture of Organisational Psychotherapy? For example, how might the answer impact our relationships with clients (I’m using Carl Rogers’ term here). Who’s in charge of that?
And further, who’s in charge of the various stakeholders, and the emerging “business” itself?
Aside: I use the term “business” loosely, as it could emerge that we can best serve the needs of our various stakeholders as a charity, foundation, loose or tight network of affiliates, or any number of other forms of association. And although our emergent “association” might be essentially commercial, I’d like to explore all our options about how we might feed and water our association.
Enough for now. Looking forward to your responses. More next time.
Reinventing Organizations ~ Frederic Laloux
You are now the owner of a genuine, pedigreed PET TEAM®
IMPORTANT: DO NOT REMOVE YOUR PET TEAM® FROM ITS SHIPPING CONTAINER BEFORE READING ITEM 1 IN THIS BOOKLET
Team Bottom® Productions
Your new team is a very sensitive pet and may be slightly traumatized from all the handling and shipping required in bringing you all together. While you may look in on your new pet from time to time, it is essential that you leave your team in its shipping container for a few days. It is advised that you set the container in an area of your office that is to become your PET TEAM’s “special place”. Some PET TEAM owners have found that the rasp of an old dot-matrix printer operating near the shipping container has a soothing effect; especially at night. It takes most PET TEAMS exactly two weeks days to acclimate themselves to their new surroundings. After ten working days have passed you may remove the team from its shipping container and begin enjoying your new pet.
If, when you remove the team from its shipping container, its members appears to be excited, place them on some old newspapers. The team will know what the paper is for and will require no further instruction. They will remain on the paper until you remove them.
Your PET TEAM will be a devoted friend and companion for many years to come. Teams enjoy a rather long life span so the two of you will never have to part – at least not on your PET TEAM’s account. Once you have transcended the awkward training stage your team will mature into a faithful, obedient, loving pet with but one purpose in life – to be at your side when you want, and to go lie down when you don’t. A PET TEAM is perfect for people who hate animals, are allergic to animals, or who are not allowed to keep animals. When you own a PET TEAM you never have problems with leash law violations, you’ll never have to clean up nasty messes, and your pet will never keep you and the management awake at night. PET TEAMS are welcome everywhere.
Your PET TEAM didn’t come out of any old Team factory, you know. There is nothing common about genuine, pedigreed PET TEAMS. They descend from a long line of famous teams. Their ancestors can be found amongst the workers of the pyramids; the slaves of Ancient Rome; and the plantations of the Caribbean and Southern States. PET TEAMS descend in one unbroken line that can be traced back to the beginning of time and even farther. PET TEAMS are found with the aid of a specially-trained Team Hound. They are then examined for congenital defects prior to intelligence evaluations. Only teams that have demonstrated a strong capacity for learning and obedience are allowed to wear the name PET TEAM. Upon passing initial tests they are prepared for shipping, packed into their cartons and sent throughout the world to anxious owners.
Your team is a one of a kind.
Of the hundreds of breeds of teams known to Man, only a few show the necessary aptitude required of a PET TEAM. The more important traits associated with genuine PET TEAMS are gentle disposition, eagerness to please, and a profound sense of responsibility.
Nobody, but nobody likes a surly, misbehaving team. Therefore, it is most important that you begin training immediately. Your PET TEAM should be made to know who is the boss, and that you will demand certain good manners and impeccable behavior if you are to all have a happy, well adjusted relationship.
Limit your training sessions to fifteen minutes, twice each day. One half-hour session is not recommended as a team’s attention span is rather short. Remember; a bored team is an unhappy team. The first section of this training manual will address itself to simple obedience—COME, SIT, STAY, etc. Amusing tricks will be covered in Section Two. No special equipment is required in training your new PET TEAM. Amazingly, a team is one of the few pets that will respond to training without the aid of leash or choke chain. First, select a special training area. Use the same area for all training sessions until your team is showing good progress.
It is essential that your PET TEAM learn this command. A team that doesn’t come when it’s called will cause its owner endless embarrassment.
Command gently but firmly.
It is assumed that you have given your PET TEAM a name by now. If you have not, do so before proceeding with obedience training. To teach the command COME, place your team on the floor or carpet and take a few steps backward. Next, bending over from the waist, place your hands upon your knees and face your team. Now, with firm authority, say, COME CODESTARS. (If you have not named your team CodeStars you may wish to say something else.) Repeat the command, COME CODESTARS. Assuming your team is normal it will probably not respond. Start again. Bending over from the waist, face your team, clap your hands, and let your face light up as you say, COME CODESTARS, C’MON GUYS, OVER HERE, and stuff like that. Now, start walking slowly toward your team. Incredibly, as you walk toward your team you will notice that it actually is coming closer. This means your PET TEAM is learning the command, COME. Praise your team and give them pats of approval.
Many PET TEAMS have tremendous difficulty learning the command, COME. PET TEAM owners have complained that their teams were stupid, dimwitted and slow because of it. Well, this is ridiculous. To be sure, training a team to come when it’s called requires extraordinary patience. It is a rare team indeed that will leap into its master’s arms the first time it hears the command. And, while it takes quite a while to train a team to come when its name is called, the problem lies not in the team’s inability to learn commands; the problem lies in the fact that a team has an extremely hard time learning its name. Be patient, calm and gentle.
The next command to teach your team is STAY. It is very important that your PET TEAM learn this command as it is disconcerting to have a team that will wander around while you are in a meeting or having a massage. Return to your training area and set your team upon the floor or ground. Look at your team intently, like you really mean business, and give the command, STAY. Surprisingly, most teams have no difficulty learning this command and respond quite obediently the first time they hear it. Repeat the command, STAY, and slowly back away from your team. If your team should move, and this is highly unlikely, shout the command while gesturing dramatically with the palm of your outstretched hand. In no time at all your PET TEAM will be responding to this obedience command each and every time. With further patience you can train your team to STAY by using only the hand signal.
This is not a difficult command to teach a PET TEAM as most teams spend the bulk of their time sitting around anyway. However, a refresher course is certainly in order since you will want your team to sit when you want them to, not when they want to. Place your team in its training area and give the command, SIT. Many teams will attempt to deceive you by lying down, thinking that you won’t know the difference. This should not be encouraged If you say, SIT, then your team PET TEAM should sit and that’s all there is to it. Here is a simple method to ensure your PET TEAM always obeys your commands: Repeat the order, SIT, and slowly walk away from your team. Now, hide in another office and, from time to time, peek in on your team to make sure they haven’t moved. If they lie down, when they should be sitting, storm into the room and shout, BAD TEAM, BAD TEAM Your PET TEAM will know it has displeased you and will return to the sitting position. It will also know who’s the boss.
Once your PET TEAM learns the command, SIT, add the command, STAY. Your team will now remain sitting until further notice.
It would be cruel to leave your team in the sitting position forever. Therefore, it is necessary that you teach it the command, DOWN. After sitting for a long period of time your team will appreciate the chance to relax. It is also nice, when you have e.g. visiting clients, to own a PET TEAM that will lie, unobtrusively and lovingly, at your feet. Teaching the command, DOWN, is best accomplished in conjunction with the command, SIT. After your PET team has been in the sitting position for a while, give it the command, DOWN. If you’ve made a big fuss about your team sitting properly they may be reluctant to move. Place your foot upon your team and push each on in turn firmly into the carpet or dirt. It won’t take long before your team understands what you want them to do. DOWN is another of the training commands that most teams respond to with a minimum of teaching.
It is in a PET TEAM’s nature that it learns to get down so easily. Praise your team and give them all a gentle, reassuring hug.
You’re a little confused if you think a PET TEAM can be taught to STAND. There is no f-e-e-t in t-e-a-m.
It is extremely unusual to see a team strolling around unaccompanied – there’s a very good reason for this. Most PET TEAM owners have had the patience and good judgment to teach the command, HEEL
To teach your PET TEAM to HEEL, simply follow these easy steps. First, place your PET TEAM on the floor or carpet directly behind your right heel. Next, give the command, HEEL, and stand absolutely still. Slowly, without moving your feet, turn and look down at your team. You will be both pleased and amazed to see they are still there, right where you want them be, directly behind your right heel. Your PET TEAM has learned the command. Praise your team.
Few pets are more anxious to please their masters than are PET TEAMS. It is surprisingly easy to teach your team cute tricks that will entertain you and your peers for hours.
Your PET TEAM will learn this trick the very first time you give them a lesson. That statement may be hard to believe but it is, nevertheless, quite true. The best place to teach your PET TEAM to ROLL OVER is on a relatively steep slope, or failing that, your office. Place your team on the floor at the top of the slope and, still holding on to them, give the command, ROLL OVER. Now, let go of your team. It’s that simple!
Your team will roll end-over-end and will not stop until they tire of the game. PET TEAMS usually get tired of the game when they reach the bottom of the slope. Follow your team to the bottom of the slope and praise them profusely. This praise will make your PET TEAM very happy and they will repeat the trick as soon as you return them to the top of the slope. You will tire of this trick long before your PET TEAM does.
Your PET TEAM will take to this trick like a duck takes to water. It is one of the most entertaining tricks a team can learn, and a trick that is sure to get many affectionate laughs and approving glances from you and your peers. Take your PET TEAM to its training area and, when you have their undivided attention, give the command, PLAY DEAD. If your team is like most teams it will not have to be told more than once. Immediately, it will go completely limp as though shot through the head, and will remain in this posture until you give a different command. Teams enjoy this trick so much that often, when you’re not even looking, they’ll actually practice it on their own. It’s not unusual to walk into a room and see a PET TEAM playing dead.
Don’t be ridiculous. You can’t teach a team to shake hands.
PET TEAMS really enjoy their food and drink, but, as nearly everyone knows, they are atrocious nutritionists. Therefore, teaching your team to eat well and drink plenty of water is very important. To do this, first find e.g. a pizzeria or company canteen. DO NOT ATTEMPT THIS TRICK IN AN EXPENSIVE RESTAURANT. Hold your team firmly in hand, give the command, EAT, and stand well back. More often than not, and depending upon your nimbleness, your PET TEAM will eat happily until they’re stuffed. If your Team does not make it happily through all the items of the menu, it may be terminally ill. If that happens, you’ll be needing a new one. Too bad.
To teach your PET TEAM to FETCH, declare a challenging BHAG or stretch goal. Next, send your PET TEAM after it. Rarely, if ever, will your PET TEAM return with the goal completed, but that’s the way it goes.
A PET TEAM is a loyal, devoted pet that can easily be trained to protect you and your company. Woe be to the competitor or other teams who venture into the offices guarded by a PET TEAM – or the client or supplier who attempts to cross a PET TEAM’s master. There are two basic attack methods to teach your PET TEAM.
1) Long Distance Attacks
2) Close Range Attacks
In those instances when your adversary is at a distance (such as when another manager finagles your budget and keeps laughing about it from their own offices), your PET TEAM will respond to the challenge instantly and effectively in assuring that it never happens again. First, clear the rage form your brow. Next, pick up your PET TEAM. Shout the command, ATTACK , and send your team to the swine’s office with all speed. This method of protection is sure-fire and results are guaranteed, although you may want to practice your plausible denial abilities before attempting this manoeuvre.
If you are threatened at close range always use the Close Range Attack Method; it is the ultimate form of personal protection. The element of surprise enters into this attack method, thereby making it doubly effective.
When the adversary approaches within arm’s length and demands all your staff, budgets and other valuables, follow these easy steps: Reach for your laptop or mobile phone as though you were going to comply with your adversary’s demands. Summon your PET TEAM. Shout the command, ATTACK. And together bash your adversary’s head in. PET TEAMS really seem to enjoy this exercise and, in most cases, come away from the attack little the worse for wear.
Owners of Attack Trained PET TEAMS have a responsibility to society to use their dangerous pets for protection only, and not for instigating trouble of any kind.
A healthy team is a happy team, everybody knows that It is, therefore, extremely important that you learn health care and emergency first aid techniques as they regard your PET TEAM. PET TEAMS are, to be sure, quite hardy. However, an occasional accident or disease may befall your team and you should know how to care for it. Also, visits to the company nurse’s station can be very time-consuming. Here are some of the more serious problems that can befall a PET TEAM, along with instructions for their cures.
If your PET TEAM appears nervous and fidgety, it’s a better than even chance it’s suffering from dreaded Rock Bottom. No other disease is as debilitating to PET TEAM as Rock Bottom. The first symptoms are manifested in an almost unbelievable forgetfulness. Your PET TEAM will not remember a single command or trick. All the hours of training will be forgotten. It will be the saddest day of your life. From simple loss of memory it gets worse. So bad in fact, that we won’t go into it here. Suffice to say that, should your PET TEAM contract Rock Bottom, get a new PET TEAM immediately. There is no known cure.
Perhaps you have seen a particular team in the wild and thought it would make a nice pet. DO NOT APPROACH THAT TEAM. This is to be discouraged. Wild teams can give you nothing but headaches. They can be surly, vicious, and unpredictable. They are nearly impossible to domesticate and show practically no learning abilities whatsoever. There’s an old saying in team circles, “Once a wild team, always a wild team.” A genuine, pedigreed PET TEAM will make a much more suitable companion.
As the owner of a PET TEAM you have assumed a responsibility to love and care for this new addition to your family. If your team should misbehave, be patient. If it should cause you problems, be forgiving. Under no circumstances should you turn your PET TEAM loose. The world is already overcrowded with discarded, unwanted teams, and millions must be destroyed each year. These poor, unfortunate teams meet brutal ends in death marches, financial and government organisations, or as land fill. Don’t allow your PET TEAM to meet an untimely demise at the bottom of an obscure pile of ordure. Remember; if you take care of your PET TEAM, your PET TEAM will take care of you.
Team Bottom® Productions
“The curious paradox is that when I accept myself just as I am, then I can change.”
~ Carl R. Rogers
My key focus as a therapist is providing the wherewithal through which folks can conduct their own inner dialogues. That’s to say, providing an opportunity, a time, a space, for folks to each have a conversation with their own self. And in a group setting – my more common scenario – for the folks in a group or team to have conversations with and amongst themselves.
I find that many groups and teams – and I hear this applies to individuals too – rarely have any kind of meaningful, purposeful or skilful internal dialogue. So, rarely does a group explore its needs, or the needs of its members. And even more rarely, in any kind of effective way.
When I’m working with a group, I’m looking for opportunities to open up their internal dialogue and allow it to flourish. Assuming that’s what they want, of course. I say working, but ideally it’s not work but rather play. Playfully looking for opportunities to support the group’s needs for effective internal reflection, play, sharing, connection and mindfulness.
I’m way less focussed on me understanding their needs, and way more focussed on helping them uncover, surface, explore and accept their feelings and needs, for and amongst themselves.
“The kind of caring that the client-centered therapist desires to achieve is a gullible caring, in which clients are accepted as they say they are, not with a lurking suspicion in the therapist’s mind that they may, in fact, be otherwise. This attitude is not stupidity on the therapist’s part; it is the kind of attitude that is most likely to lead to trust…”
~ Carl R. Rogers
And to myself, I generally ask: “How can I best provide a relationship through which the folks in this group or team may best connect with – and thereby attend to – their own personal and collective needs?”
Attending To The Needs Of Others ~ FlowChainSensei
On Becoming A Person: A Therapist’s View Of Psychotherapy ~ Carl R. Rogers
I love to see folks interacting compassionately with each other. Eschewing judgement. Looking for what’s alive in one another. Helping each other grow in spirit. It would be fair to describe that as something I need.
Most times when I’m with an established group of people however, I find that need not getting met. Most times, I feel sad at the subtle, unwitting violence implicit in folks’ interactions. Violence in terms of judgmentalism, not least.
Over the past two or three years I’ve been working on weaning myself off judgmentalism. I sense I have a long way to go still, but in my journey I note four stages I have passed through so far:
A blindness to the world of judgement in which we all live. An absence of awareness of the effects it’s having on our relationships and social cohesion. And an unwitting participation in continually passing moralistic judgments on just about anyone and everyone we encounter.
When awareness dawns, it can kindle a burning desire to do something about it. When I was in this stage I continually beat myself up (judged myself a failing person) for my lack of non-judgmentalism and my inability to produce non-judgmental thoughts and actions. This stage often also brings a burning passion to proselytise e.g. non-violence, and convert others to the non-judgmental path.
After a time, the flame dies, to be replaced with an an airy nonchalance. With sangfroid. With equanimity. But I found this stage a little forced. a little delusional. Yes, I was acutely aware of the times I was making moralistic judgements. And yes, I could interrupt that line of thought and not act on the judgment – by saying or doing something, for example. Yet my judgments of people still bothered me. Still triggered negative thoughts. Still caused me angst. And maybe folks sensed that, even as I tried to suppress it.
I guess I’m just turning the corner into this stage. Here I find I’m easier with others and their way of being. I find it much easier to just be present and list without judgement. I still find myself conscious of the judgments my mind is still making, but the resulting angst is lessening. I’m bothered less, about what people do and how they are. And interrupted responses are fewer, and weaker.
I suspect there are more stages yet to come (wry smile).
For all my progress, or maybe because of it, I find myself ill at ease in group situations where the dynamics and customs of the group reflect the “water” stage. It makes me feel uneasy to see folks doing casual violence to each other, and unwittingly alienating each other, often contrary to their declared purpose for being a group in the first place.
For example, I was a guest of a warmly welcoming local Toastmasters group last night. The stated aims of the group are to help people with public speaking in a safe and friendly environment. And yet the Toastmasters “rituals” – at least as interpreted by this group, and seen through the lens of nonviolence – seem to me to undermine those aims. Specifically:
Are there ways of being as a group that could avoid these undermining behaviours? That could bring more joy to folks’ interactions and building of relationships? I believe so. Maybe the rituals have to change. Or maybe just their interpretation. I would love to see some nonviolence principles come into play (sic):
I guess this would help get my needs met more effectively. And the needs of the folks in the group, too, perhaps.
How do you feel about the dynamics of the groups of which you choose to be a part? Could you imagine more joy, more joyful interactions, deeper and more human relationships? Would you be willing to consider what you could do, both yourself and in concert, to help that happen?
[Tl;Dr: Teams can be more effective by eschewing both Scrum Master and Product Owner – if they can count on getting the support they need when they need it.]
I’ve written before about Familiar and how we delighted both our customers and ourselves by the way we approached software development. And my recent observations on the role of Scrum Master seem to have struck a chord.
At Familiar, we had neither Scrum Masters – although using a Scrum-like approach to development – nor Product Owners. And we did just fine. Better than fine, actually. Our teams found their own ways of working, handled their own interfaces, and gained an effective understanding of customers and their needs, by themselves. With support from one or more extra-team specialists, when the team decided they needed it.
I have seen teams struggle when they have to go it alone in finding new and more effective ways of working, especially if they come from another place, like a batch-and-queue (a.k.a. waterfall), project managed, big-requirements-up-front past.
Yet teams of highly intelligent, reasonably motivated folks can exceed expectations when allowed to make their own choices, so long as they know how to call for help and can do so, quickly and often, whenever they feel they need to.
The idea that people have to be supervised is deeply ingrained in our view of work. The very notion of allowing teams their head without a Scrum Master or Product Owner to watch over them, keep them on track and generally boss them about seems highly risky. Despite all the evidence and advice, most organisations are still in no way ready to embrace self-organisation without the safety net of supervision. And with supervision, self-organsation offers hardly any advance at all.
By support, I mean someone – or some number of people – that can help the team find ways past the obstacles they will regularly encounter. Some shared context is useful, so the helper(s) may have some longer-term relationship with the team, rather that just being called in “cold”. Some of the skills useful in such helpers will include Amanuensarian, coach, and therapist. I wrote a fuller list some years ago.
Given the wide range of skills that might be needed, only the very largest organisations are likely to have such people on staff.
Another often quoted aspect of the Scrum Master role is the protection he or she can afford the team, from interruptions and other disruptions. I wouldn’t want to downplay the value of this, but I would be much happier to see teams themselves more aware of the value of flow and the need to minimise interruptions – including those self-generated. Can teams handle interruptions themselves? Yes – with adequate awareness and support.
Apart from the Universal Scrum Master Failure, the very nature of the relationship between many Scrum Masters and their teams tends to an unhealthy power dynamic. Many managers – unfairly or unreasonably, in my view – hold the Scrum Master accountable for the results of the team. Naturally, then, the Scrum Master feels under some form of pressure (such as duty, self-interest, or similar) to push the team to do “better”. And, human nature and learned behaviour being what is it, oftentimes this pushing can be coercive and violent. Few realise the significant damage that such a dynamic wreaks in collaborative knowledge-work.
Undoubtedly there are (a few) Scrum Masters that avoid this dynamic. These folks appreciate the need to create an environment where the team can find motivation (to the extent they so choose) and learn. By learning, they become more effective over time. Unfortunately, the few enlightened Scrum Masters rarely find themselves in organisations where cultivating this kind of environment for their team is anything but excruciatingly difficult and painful for themselves.
Both of these conditions together – “enlightened” Scrum Masters and “fertile” organisations soil – are necessary to allow the Scrum Master role to deliver value. It’s so rare for both these conditions to exist at the same time in the same place as to mean that maybe less than 10% of situations would derive value from having someone in the Scrum Master role.
The issue of power dynamics has less impact in the relationship between teams and their product owners. Although the nature of that relationship is very varied, more varied even than that of Scrum Master and team.
I reject the Product Owner role for different reasons. Specifically:
In summary, if I were on a development team, or responsible for one, i’d want neither a Scrum Master nor a Product Owner. I would instead take pains to ensure that the team had a wide range of skills and experience at its beck and call, and the know-how of how to pull such skills as it needed them. To reduce delays, this may mean having one or more such people on hand, close-by, at all times. This does not mean a Scrum Master.
I just got back from Agile By Example 2014 (Warsaw). One of the many questions folks asked me while I was there was
“What’s the ideal workspace for software development (teams)?”
Conventional wisdom, seeing software development as some kind of office work or even factory work, suggests that developers’ workspaces can simply look like the typical open-plan office. Or maybe the dreaded cube-farm.
More progressive organisations might choose to regard software development as more of a collaborative, creative endeavour, and arrange the workspace more like e.g. a design studio.
In my experience, both both of these, and other, assumptions are fundamentally flawed.
Software development does not benefit from just one kind of workspace. Any single style of workspace does not allow for the variety of different modes of work during a typical day of development working.
Software development ebbs and flows, more or less smoothly, and unpredictably, from mode to mode and back again, throughout each and every day.
Cave: Sometimes, one or two members of the team may wish to find a quiet, enclosed space to work on a particular issue where concentration, flow, and freedom from distractions are the predominant issues. A typical “cave” would be a small, private, soundproof office with space for a desk or two, a couple of chairs, and with a door that can be closed.
Bullpen: At other times, a subset of the whole team may wish to work together, either on the same thing (like Mob Programming), or on different, but vaguely-related things (like different User Stories of a given product). Here the predominant issues are explicit and incidental sharing of knowledge, status, and other information. A typical bullpen would be an enclosed space with a large desk – seating up to say eight people around its periphery – with room for chairs, desktops and laptop computers, information radiators, etc., and again with a door closing it off from corridors and other nearby spaces.
Lounge: At other times again, some number of the team may wish to relax, chat quietly, and socialise and work in a more informal space. Here, the space is purposed primarily to socialising and relationship-building. A typical lounge would be an enclosed space – again with a door – with sofas, bookshelves, information radiators, and maybe a place to get drinks (water cooler, fridge, coffee machine, kettle, etc.) and snacks.
In a typical working day, members of the team – and their guests – may migrate repeatedly from space to space, as the pattern and rhythm of their day changes and morphs in response to the nature of the work of the moment.
I’d suggest each team (circa eight people) have their own dedicated area comprising caves (two to three in number), bullpen (or two) and lounge.
In organisations with more than one development team, other needs (meetings, eating, play, etc.) can be catered to by shared facilities (meeting rooms, canteen or refectories, recreation rooms, sports facilities, showers, bathrooms, and so on).
And on larger product development endeavours, involving more than one team, I find some arguments in favour of enlarging the workspace and having all the teams share this enlarged space. For example, with three 8-person teams in the same space, we might look to have five or six caves, two or three bullpens, and a common – albeit larger – lounge a.k.a. common room. And intermittent remote working – such as working from home, or God forbid, a client site – can further reduce the floorspace requirements somewhat.
I hear some mutterings at the back about how much this might all cost. All I can say is, do you know the (hidden) costs – in terms of reduced productivity, less employee engagement, morale, etc.) – of your current workplace arrangements?
Until you discover and quantify those, how can you evaluate the cost/benefit of creating workspaces better suited to software development?
We all dread unproductive and ineffective conversations, discussions, and meetings. Stuck in a room, feeling one’s life force ebb away, frustrated beyond measure that we’re not accomplishing anything useful, and with a mountain of other more useful things we could be doing inexorably bearing down on us. We pray for it to end – and end swiftly – so we can get back to our lives.
But before feelings of angst and frustration set in, I often have high hopes. This prayer resonates:
“As we prepare to spend this time together, let us cherish and celebrate our shared humanness, our shared capacity for reason and compassion, our shared love for the people here to day, and for those who could not be here with us.
Grant us the wisdom, the patience and the skills to use our time here well, to find meaningful human connections, and to learn together, for the benefit of all.
In gratitude and in love, in reason and in compassion, let us work together for a better understanding, to know more, to find shared insights, and joy.”
When I was working with S.W.I.F.T. in Belgium some years ago, I came across Russ, a no-nonsense Australian. Amongst his many engaging attributes, I found his approach to meetings quite refreshing. If a meeting offered him nothing in the way of addressing his needs, he’d simply not attend. And if, during a meeting, it seemed unproductive or of little value, he’d get up and walk out. I often find myself wishing for the courage to do the same.
So, what do you do when you find yourself in a conversation, discussion, or meeting that’s fail to meet your needs? What actions do you take? Who do you blame?
As an organisational psychotherapist, I have a particular stance on group discussions. I choose to listen, to try to sense the group’s feelings, and to stand with the group in its discomfort and frustrations.
If, by some twist of fate, others expect me to facilitate their discussion, I state that I prefer to listen, rather than talk or direct. This can occasionally result in an impasse, for example where a group is unable or unwilling to “facilitate” its own discussions. This in itself can be a learning experience, albeit a disconcerting one.
Maybe the biggest source of folks’ frustration in e.g. unproductive discussions stems from our natural tendency to blame others for our own emotional responses, our responses to not getting our needs met. God knows, unsatisfactory discussions and meetings can be a huge trigger for negative emotional responses.
“One of the core milestones on the path of consciousness transformation is the moment when we can fully integrate the radical awareness that our emotional responses to the world and to things that happen to us are never caused by another person. This awareness stands in stark contrast to our habitual speech, which states that we feel what we feel because of what someone else did. Instead, we learn, if we apply ourselves deeply to this practice, that our emotions are only caused by the meaning we assign to what someone did, and that meaning is generated from within us, not by their actions.”
~ Miki Kashtan
Discussions can serve to meet our needs, though. Maybe that’s why we find unsatisfactory meetings so frustrating. As social animals, our discussions and meetings, if done well, can provide us with deeper and more meaningful personal connections, better understanding, useful new knowledge, shared insights, and joy.
Amen to that.
Blame, Responsibility And Care ~ Miki Kashtan
The formation of ingroups (and, thus, outgroups) is a natural human phenomenon. In the world of organisations, ingroups and outgroups abound.
One particular partitioning I see regularly is the division between “management” and “workers”. Members of each group self-identify, and in even the smallest organisations, members of the management ingroup can hold views widely at variance with the views of those who see themselves as “workers”.
Kent Beck is reported to have stated at Snowbird in 2001 that one goal of the Agile Manifesto was
“…to heal the divide between development and business.”
Presumably, then, this divide has some more or less pernicious consequences. Fundamentally, I suspect the most significant consequence is the impact of such division on the levels of trust between members of these two groups. And, absent trust, the working relationships between members of these two groups are bound to be fraught, to say the least.
Here’s the default management viewpoint (I feel qualified to express this, having self-identified with this group from time to time).
Here’s the default development viewpoint (I feel qualified to express this, too, having self-identified with this group from time to time).
I guess there’s a whole passle of other aspects to these groups’ respective viewpoints, too.
It’s not been my intent with this post to judge which group has the more useful viewpoint. Rather, to illuminate the often diametrically opposed aspects of these two groups’ ways of seeing the world of work. And the beliefs held by, and a part of the self-identity of, each respective ingroup.
Maybe such illumination can help in some small way to bridge the ingroup/outgroup boundary (a.k.a. divide, rift, gulf) between them.
In my work I get to see a lot of teams. Or, more accurately, I get to see a lot of groups of people who think they’re teams, or who other folks choose to call “teams”.
Nothing speaks to me quite so loudly or clearly about the teaminess of a group as their willingness to go to bat for each other. To commit their own individual time and effort on helping their teammates with their issues, and on advancing the progress and interests of the team, at the expense of their own egos, and synergising the needs and interests of the team with their own individual needs and personal interests.
Given the rarity of this phenomenon, small wonder then that the Amanuensarian is a role rarely seen in the wild.
In a recent blog post describing an effective group workshop, I introduced the term “Amanuensarian”. This is a portmanteau term derived from the conjunction of “Amanuensis” and Cybrarian“.
noun (pl) -ses
A person employed to take dictation or to copy manuscripts
Origin: C17: from Latin āmanuensis, from the phrase servus ā manū slave at hand (that is, handwriting)
In this context, the amanuensis’ role is focused on writing down or otherwise recording stuff to which he, she, or the team, believe they might need to refer later.
A librarian who uses computers and the Internet for their work; any person who works doing online research and information retrieval, esp. one who answers reference questions online; also called data surfers, super searchers
Origin: cyber- ‘cybernetics’ + (li)brarian
In this context, the cybrarian role is focused on understanding the team’s needs for information, on finding that information, and on bringing it back and sharing with the team, possibly recording it for future reference, too.
Key skills for the amanuensarian role include:
I find the presence of the role of amanuensarian a great bellwether for the teaminess of a group of people. Teams sharing common goals, and working together towards these goals.
“The purpose of a team is not goal attainment but goal alignment.”
~ Tom DeMarco, Peopleware
The amanuensarian role is all about attending to the (information and time-binding) needs of both the team as a whole and the individuals therein, and downplaying their own ambitions for the good of the fellowship of the team.
Any group of knowledge-work people will have a pressing and ongoing need for information on a host of topics. Finding such information, and moreover sharing it effectively, is a skill – and a task – in itself. People can undertake the task for themselves, and build their skills as they go, or the amanuensarian role can smooth the path and allow the rest of the team to focus on their own matters of import.
For a mental image, I think of Gandalf, galloping halfway across Middle Earth to seek out information concerning the One Ring – information vital to Frodo and subsequently to the mission of the Fellowship as a whole.
And where would any team be, without folks who seek out and hold their lore?