Wednesday, April 29, 2020

Discombobulation in Covidland

Discombobulated. My new favourite mot du jour since it seems to perfectly capture what many people, myself included, are going through with this Covid-19 crisis and associated lockdown and limitations. From the OED:



Does this sound familiar? That general feeling of disconnection, discomfort, even confusion caused by the sudden changes in the world recently. Perhaps an inability to concentrate, or the opposite, wanting to zone out deeper than ever. Perhaps your sleep patterns have changed, or the way you eat (maybe more than usual, maybe less), or your caffeine or alcohol consumption. Feeling a little more grumpy/intolerant? Everyone will react differently. One thing is certain. Everyone's cheese has most definitely been moved, and with minimal warning.

Before I go further, I have one important piece of reassurance for everyone who is feeling the effects of this lockdown, whatever these effects may be.

You are OK. It's normal.

Here in the UK, Chris Witty, the UK Chief Medical Officer, and several others have now strongly hinted that social distancing measures could remain for the rest of the year, maybe beyond. Covid-19 has proved to be extremely difficult to pin down and eradicate, so we need to get used to a new normal, for the short- to mid-term at least. But first, we all need to recognise that change is stressful.

So what is going on? What is making many of us so, well, discombobulated?

Maslow and Covid-19


Let's start by taking a quick look at Maslow's Hierarchy of Needs, and how it might have been affected.

FireflySixtySeven / CC BY-SA (https://creativecommons.org/licenses/by-sa/4.0)

What Abraham Maslow suggested in his 1943 paper "A Theory of Human Motivation" and other publications was that everyone has a series of needs, from the most basic (food, water, shelter, health, sleep and security) to more esoteric (status, friendship, learning, mastery). The lower needs tend to take precedence and dominate behaviours over the higher needs.

Despite all of the trials and tribulations of life, the universe and everything, most of us are used to existing fairly high on the pyramid - most of us have somewhere warm to sleep, enough to eat, feel that we belong, are not about to be eaten by wild animals and so on.

What has happened is the Covid-19 pandemic has just completely undermined the previously-satisfied need for safety. This virus is life threatening. Also, the lockdown will have likely damaged the need for love/belonging since suddenly we are socially distancing, and not necessarily able to see loved ones, family, friends and so on. Your experiences might mean other layers are being messed with as well - for example, shortages at the supermarkets, or reduced salary. This would be seen as a potential threat to the physiological need (shelter, food).

Remember, we are hard-wired so that the lower needs tend to take precedence over higher needs. Also remember we are used to living with many of our higher needs met. Suddenly we have a massive shock to a system that has been languishing in a fairly comfortable equilibrium, and the cognitive dissonance is immense. "I need to work hard...but rebuilding my safety is higher priority". "I have a really comfortable life...but I need to put food on the table". And so on.  That is enough to affect anyone!

What next?


The Hierarchy of Needs is one model that helps us understand what might be causing so many people to feel quite so upset by recent events. Another useful model is Virginia Satir's Change Model, which helps us understand how we will go through different phases until we reach a "new normal".

Satir's model was originally developed for family therapy, but has also been immensely useful in understanding how people cope with organisational change. I would go a step further and suggest it helps us understand how people cope with any major change. And the Covid-19 pandemic is certainly one such major change.


Let's start from the beginning. We are living in a state of relative equilibrium, the status quo. Some days are a little better, some a little worse (hence the jagged line), but no great change. Our world and behaviours are defined, our Maslow Pyramid of Needs is stable, and we are happily going about life.

Then something happens that requires a response. A foreign element hits our nice, familiar equilibrium. In this case, Covid-19 and lockdown, so a pretty large knock. Often this event triggers a period of resistance as we try to ignore, fight or negotiate with what has happened so we don't need to change - we have all seen the reports of groups of people having barbecues, so called "coronavirus parties" and so on. As it turns out, this virus is somewhat difficult to fight, hard to ignore, and does not negotiate, so mostly this resistance phase has been short lived. So....

...we enter the unknown. Chaos. Many old reactions, old behaviours, old expectations have become irrelevant almost overnight. Maslow's Pyramid has been shaken to its core. Your sense of belonging and identity is likely to have taken a severe knock as a result, as has your feeling of safety. This will trigger all kinds of stress responses such as those listed at the start of the article - sleeplessness, excessive eating/drinking etc etc. Behaviour can become erratic, and some may revert to childhood survival responses because that its all they have left to fall back on (bullying, withdrawal and so on). Day to day performance will become erratic, with major swings. It is important to accept that the uncertainty makes this period incredibly frightening, especially for those of us who have not experienced a major change for possibly years or even decades. Our cheese has most definitely been moved, and we are not happy!

The chaotic phase carries on until we find our transforming idea. Something that we can use to help make the most of the current situation, and stabilise our inherent needs. This will be different for each of us, but will rebuild our sense of belonging and safety. Some examples I have seen/heard about are regular videoconferences with distant loved ones, settling into that long-promised but never started regular exercise routine, training courses (work related, and personal interest) and so on. I know of quite a few people who have formed virtual pubs, coffee 'shops' and cocktail hours online! For others, the transforming idea might be stabilising income by finding temporary work stacking shelves, or making much needed grocery deliveries for supermarkets or local shops. 

Gradually the chaotic uncertainty reduces until a new, stable status quo is reached. The much talked about "new reality". This might not be where you want to be ultimately, but it will be a solid base where you feel safe, stable and can regroup. From here, you might want to make more major changes, but these will be in a more controlled way, to your own timescales. The fact that subsequent change will be on your own terms will reduce the disruptive effect of these phases. They will still be there to a degree, but more manageable.

Summary  


There we have it. Two models that some people might find useful to understand what they, and others, are feeling, and also may help them come to terms with the current situation with the Covid-19 pandemic. 

The main take-home points from this are:
  • It is perfectly normal to be confused and disoriented when confronted by a life changing event, no matter how tough you think you should be.
  • Look for your transforming idea. How can you make use of the situation better?
  • People will behave in uncharacteristic and unexpected ways. They might be more upset than you think. BE KIND.
  • Discombobulate is a fun, cool, underused word.

Finally, some questions to ask yourself: 
  • Where are you on the Change Model journey? 
  • Have you found your transforming idea? 
  • Have you managed to repair your Pyramid of Needs? How? Are there still Needs that need addressing?

If anyone feels that they would benefit from talking this through, please do get in touch for a confidential, no obligation coaching chat - PM me on LinkedIn, Twitter, or use the Contact Us form.


Monday, January 20, 2020

What is "Coaching"?

Anyone who knows me, or follows my posts on social media, will know that I have been studying for a Post Graduate Certificate in Personal and Business Coaching with Chester University. It is a fantastic journey, and has most definitely helped me understand myself in greater depth, as well as has helping my coachees!

But the term "coaching" seems to be creating some confusion. Which is somewhat unsurprising as someone who has marketed themselves as an “Agile Coach” since 2005, it would be perfectly reasonable to assume the “coaching” training I am doing has something to do with agile processes and teams. Except nothing could be further from the truth…

So if it’s not related to "agile coaching", what on earth is this "personal/business coaching" thing?

Let us start by describing what I do when “coaching” a software team in agility. “Agile”1 has a well defined set of values, practices and principles that define it2,3. Stray from these, and you are no longer “agile”.  Most of my work as an agile coach is actually teaching these principles and practices, then mentoring (or guiding) the team in how best to apply them to their own, specific circumstances. In other words, I have been invited to guide the team to a known destination.

Now, consider a situation when you have no idea of that destination. For example, someone is trying to decide whether to take a new opportunity, or stay with their current employer. Or they are feeling totally overwhelmed with work. Or are having trouble maintaining a healthy work-life balance. Or starting their own business, but don't know what to do next. In these cases, you need to unlock the intrinsic potential, but without allowing influence from your own opinions. You have to be comfortable in not knowing. You need the tools and techniques that will help the person clarify their own thoughts, and enable them to decide where they want to go without polluting it with your own biases. This is what I mean by personal/business coaching. It is “the unlocking of a person’s potential to maximise their own performance. It is helping them to learn rather than teaching them4

The difference is obvious. In the first case, I am providing the answers. In the second, I am clearing the way to allow the individual(s) to find their own answers. This diagram from Barry O'Reilly and Kate Leto sums it up nicely. Agile Coaching is a mixture of Consulting and Mentoring. Personal Coaching is...well...coaching!



There we have it. Agile Coaching is not really coaching (in my opinion!) - but we are at the mercy of recruitment company search terms, so I'm afraid we still need to carry on using the term!


If this article has piqued your interest in coaching of either sort(!) then do get in touch for a no-obligation chat. I can be reached on Twitter (@thirstybear) and Linked In, or via email on coaching@<my company domain>




1 Agile and all its related cousins - lean etc. It's just faster to type "agile"!
2 Manifesto for Agile Software Development
3 Extreme Programming
John Whitmore, Coaching for Performance

Monday, November 18, 2019

Could Rethinking the 6th Principle Save the Planet?

Phillip Perry / Traffic Jam at J4 on the M4 - geograph.org.uk - 954561


 “The most efficient and effective method of conveying information to and within a development  team is face-to-face conversation.”


The Agile Manifesto’s 6th Principle.  Obvious, isn’t it? The fastest, easiest, best way to exchange information is to actually talk to people. From this simple premise comes the recommendation of “collocated teams” - so that people can communicate with minimal friction.

I shall put my hand up and admit that I have fully supported this idea for years, and have regularly encouraged teams to adopt it, usually with fantastic results. There can be no doubt that the approach works extremely well. Not working together in the same physical space forces compromise since it  reduces collaboration unless people actively work to come together. Information flow happens more slowly, and becomes more ‘clunky’. Also people lose the subtle cues from body language, half-heard discussions, and instant team timeouts to discuss important issues or design decisions. So teams would be insane to not work collocated without a very good business reason, right?

But times change. 

Here in the UK there have been step changes in internet infrastructure and speeds. As a very junior developer back in the 90s, when I was first developing my ways of working, I was occasionally working from home using a state of the art 56k (!) modem. That increased to just under 2 Mb/s when ADSL finally reached where I was living, opening up the possibility of using a remote desktop, or low res video conferencing. I now have VDSL, with download speeds of around 30 Mb/s - not bad for a fairly rural area in the UK - so I now have enough bandwidth (usually!)  for video links, shared desktop, and streaming services, plus a landline, all with little/no visible lag.

This increase in bandwidth to the home has enabled people to develop new tools - we now have the likes of Skype, Zoom and Slack to name but three. These have in turn allowed people to experiment with new ways of working. I have spoken with teams and individuals who now have well defined teamworking norms that allow them to mitigate the compromise of losing face to face interaction. It is now possible to be effective while working remotely far more often than just the occasional day waiting in for that elusive delivery. I can highly recommend Rachel Davies’ closing keynote “Sustaining Remote First Teams” from Agile on the Beach 2019 for anyone interested in some suggestions. 

The overall effect of this increased bandwidth has been to significantly reduce the extra effort needed for remote collaboration since 2001.Yet, for me this has not been enough. Just because you  can do something does not mean you should. Regular remote working still requires some extra effort for it to work, so why add unnecessary complexity? KISS: "Keep It Simple, Stupid"; collocate if at all possible. But, as I mentioned earlier, times change.  There is now an incredibly important imperative that has to drive changes about how we think about collaboration and teamwork.

One aspect is overcrowded cities. Over the years, here in the UK the public transport infrastructure is starting to creak and groan under the weight of use compounded by lack of investment. Trains and buses tend to be overcrowded, especially during London rush hour, as everyone tries to reach the offices they share with their colleagues. It is the same with the roads - they are clogged with traffic in the major cities. Congestion and parking now make it pointless to drive into most of the major UK cities, yet people still do in order to collocate with colleagues. 

All these commutes and overcrowding issues create unwanted side effects. Increased stress, increased sick days and so on. But one of the most important is pollution. Levels in London and other cities are reaching unprecedented, damaging levels. Also, climate change is now an undeniable effect of  burning fossil fuels - at least in part caused by the sheer number of people trying to get from A to B to work, and back home again.

It is an uncomfortable truth that collocating teams is contributing to choking the planet. So where does this leave us regarding the 6th Principle?

I am beginning to think that we have to seriously rethink how we work as teams, and invest in understanding how to consistently build successful remote-first teams that operate at least as well as collocated teams. The 6th Principle only states “face-to-face conversation”. It does not specify how this happens. To coin a phrase, “We can rebuild teamwork; we have the technology” (with apologies to Steve Austen & co).  And we might just help save the planet in the process.

Thursday, November 07, 2019

New Services Available!

Exciting news!

Folks may have noticed that I have been quiet of late. Well, I have been expanding the range of skills that Thirsty Bear Software can offer.

I am pleased to announce that we can now offer Personal and Business Coaching services.

I am now a trained Barefoot Coach. It is worth pointing out that this coaching service is completely different from what folks call "Agile Coaching" - this kind of coaching is aimed fairly and squarely at helping individuals, teams and businesses unlock their potential and maximise their own performance. Not a Scrum, unit test or continuous integration in sight (although I can still help with that tech stuff if needed - that is a service we still provide). No doubt I will be publishing an article soon on the difference between the two, but for now I hope that definition is enough. If you would like to know more, then please do get in touch.

However, this is just the first step on a longer journey, leading to both a Postgraduate Certificate with Chester University, and also to accreditation with the International Coach Federation. Both of these qualifications have a significant hands-on element - actually walking the walk and doing it. And so I am excited to offer a limited number of free* coaching places on a first come-first served basis.

I'll say that again in case anyone missed it:
FREE* COACHING PLACES!
Get in touch for more information. Briefly, I am based in the UK southern counties. Face to face is always best, but I am happy to use a high quality video link if you are further away.


* 6 hours' worth of "free" (as in "beer") coaching sessions. All I ask is for honest feedback, and if you find the sessions useful then a recommendation that I can use.


Tuesday, May 08, 2018

More Thoughts on Feature Branching vs Trunk Based Development

Confusion-dark
Recent posts by Dave Farley and Jim Kinsey, and the release of the Accelerate book by Forsgren et al appear to be bringing dysfunctional development practices firmly into the spotlight once again, most specifically the practice of combining feature branching and automated builds, while calling it “continuous integration". I have already written my own opinion piece on the practice. In summary, I hate it - in a modern, collocated team it is wasteful, suppresses fast feedback, and completely undermines the advantages of powerful teamwork enabled by continuous integration. It harks back to a software dark age that I honestly thought our industry had finally left behind. It really is Continuing Isolation.

But perhaps the most damning piece of research about Feature Branching that has come out in recent years is best summarised by Dave Farley:
If you are not merging your changes to Trunk at least daily, [the research] predicts that your outcomes are more closely aligned with “Lower Performing Teams”.
So that’s it. Some limited edge cases aside, if you are not continually integrating to a common trunk at least daily, you are choosing to be a low performer. It is now a conscious choice based on hard data. Who actually wants to be a low performer?

Well, it would appear a significant number of companies and teams do. From my experience, heavyweight feature branching practices are rife, even when totally inappropriate.

Which, for me, raises the much deeper question. Why would otherwise perfectly sane, competent, conscientious people deliberately choose to be "lower performing”? And perhaps more telling, why would they choose to be lower performing and passionately defend the practices shown to be causing it? I believe Jez Humble (co-author of ‘Accelerate’) hits the nail squarely on the head here:


(The whole Twitter thread is worth a read, with some interesting insights)

In short (and kind of inevitably, in my not very humble opinion), it’s culture. That amorphous, difficult to define, "emergent property of interactions over time” (thanks due to Dave Snowden for the definition). So basically your team/company/personal decisions have been shaped by valuing certain narratives and interactions over others - perceived convention, fitting in & peer pressure, pressure from performance reviews, painful failures, habit, and so on. I cannot emphasise enough that culture is THE most pervasive, entrenched barrier to team improvement. Hence the apparent conflict between a declared wish to improve, yet defending dysfunctional practices. Yet it is also the most difficult to change precisely because it is emergent, and because going against local cultural norms is damned scary.

Jez correctly points out a key difference between feature branch development, and trunk based development. Feature branch based flows are optimised for individual developers. They can shut themselves away, with minimal collaboration, and eventually, magically conjure something at the end that may or may not work. It actively encourages solo, "hero programmer" behaviours and hence culture. Adding automated integration patterns to this (note, this is categorically not "continuous integration") will not help performance much because of the integrate-late, test-late nature of the flow.

"Trunk Based Development", with an entire team working on a single branch, encourages an entirely different kind of approach and behaviour; it is about team collaboration and communication. It has to - without these skills, quite simply, it will not work. Period. It requires a team. A real, functioning team, and not just a group of individuals.

As such, feature branching tends to be symptomatic of a company culture of broken teamwork, and as a result, low performance.

So, given the difficulty in changing an embedded culture, and how scary this kind of change is, how can a team move from feature branching approaches like GitFlow, and successfully change to Trunk Based Development and continuous integration? Well, the good news is you have already taken an enormous step forward by recognising a need to change. Unsurprisingly, the next step is to carry out a health-check on the team.

How do you recognise a healthy team? A useful starting point for assessing team health is the excellent Lencioni’s 5 Dysfunctions of a Team, which suggests that a healthy, functioning team has these traits. Each relies on the previous.
  • Trust. A willingness to be vulnerable within the team.
  • Constructive conflict. It’s OK to disagree and discuss. It is OK to have “constructive, passionate debate”.
  • Commitment. All team members buy-in to joint decisions.
  • Accountability. Team members call others out on counterproductive behaviour.
  • Attention to results. Team success first, over and above personal success and ego.
Having successfully installed Trunk Based Development and Continuous Integration practices into many teams (and with my fair share of failures over the years as well!), I can safely say that these provide a good guideline for success. At very least TBD/CI development needs teams aspiring to this baseline, with a little help from an experienced agile technical coach.

That’s it for now. In the second instalment, I will go through some of the practices and tricks that make TBD/CI work for a team, and link them back to how the 5 Dysfunctions undermine the chances of success.

Friday, February 09, 2018

How not to be an Igor

I recently wrote a somewhat tongue in cheek piece with a serious message. For agile - well, actually, any software development project - to succeed, business needs to be fully and intelligently engaged. Iterative delivery processes appear particularly sensitive to this (arguably, they just show it up sooner, but that’s another discussion).

So, how do you make sure that your software team(s) successfully deliver what’s needed? A very good question - and one with no definitive answer. But here are a few hints that should give you a better than average chance of success.

Firstly, and perhaps most importantly, is to recognise that “The Business” generally does not really understand the engineering discipine of software development. They might have an appreciation of it (at least, I hope they do!), but they don’t have skin in that particular game. They don’t cut code daily, so they don’t experience the trials and tribulations of producing the end product. So they don’t generally care about how many tests you have, or that you are using the latest whizzy ReacgularEmberAshSproutCabbageCarrotCore framework, nor do they care whether you are using continuous integration, containers, microservices or Tupperware. The business is usually only interested in one thing - the end game. Working, reliable software in front of the customer. And if they cannot see that, then they will be tempted to fall back on illusion of progress antipatterns as a proxy measure of progress, performance and value. For example, Number of Stories Delivered, Velocity Points Delivered, Accuracy of Estimates measures and so on (Hint: This is a Bad Thing(tm). None of these are productive. Quite the opposite, they are illusory).

Equally, “The Dev Team" don’t always understand the business. Since software development is a skilled, complex, creative endeavour, their focus needs to be on programming tools, techniques, patterns and paradigms. As a result, in the same way as business is disconnected from development pressures, they can miss important factors unrelated to their immediate engineering discipline. For example, time-to-market pressures, customer needs, visibility of real progress and so on.

I believe this situation is fine and good. It is rare to find teams that are so cross-skilled that developers and business representatives are interchangeable. Both disciplines require significant specialist personal investment of time and energy. But as a result, neither side can exist in isolation. Neither side is better than the other. Effective product delivery is a joint responsiblity. It has to be a symbiotic collaboration of the two sides, which requires communication and mutual respect. Frequent, effective, two-way, respectful communication. If this breaks down, then trust is lost, the illusory control mechanisms begin to appear, and both sides start an unproductive game of "blame whack-a-mole”. Business demands a meaningless progress metric, eg velocity points delivered. Dev team get metaphorically beaten up for “not delivering enough points”. Dev team learns how to game the metric to avoid pain. Software still doesn’t get delivered. Business demands another meaningless progress metric, which gets gamed…. and so the proverbial blame-moles get whacked.

So the first, most important rule of “Not being an Igor” is for Business and Development to communicate with each other openly, honestly, and with respect for each others’ needs and skillset. The rest follows on from here.

Once there is a meaningful, respectful dialogue between Business and Development, then both can openly and honestly discuss, challenge and align goals. For example, if the Business genuinely needs something working in time for, say, a key conference, then the thorny subject of how it can be delivered can be discussed. The Development team knows their subject, so they are the best people to ask. Equally if there is budgetary consideration, then perhaps Business are the best people to ask. Both sides have valuable input. However, both sides need to be alert for imagined terms. The needs of both side can be challenged (respectfully!) and discussed to see if they are real or based on flawed information or opinion. Eg. "What happens if we miss that date? Does the company go bankrupt?”, “Do we want this product so badly that budget isn’t really an issue? When does cost become a real issue?”.

There are facilitation techniques that can be used to ensure these discussions are effective and productive rather than damaging. This is a rich seam of material for other articles at some indeterminate time in the future - do get in touch if you need help with this.

Now the goals are aligned, actual development of software to satisfy them can start. More importantly, an ongoing, meaningful discussion of progress can begin. To be meaningful, progress needs to be directly measurable, and not abstract (story point burn is definitely out). The only measure is demonstrably working software. That is, software that you can give to the business and say “This is what it does now, compared to what it did last time”. No smoke, no mirrors, no voodoo SQL statements showing magic has happened. Plain old warts’n'all User Experience.
From visible progress, more meaningful discussion can take place. Does the software work? Does it look like we can deliver within budget/time? What are the unforeseen (unforeseeable!) problems stopping us? Are we likely to succeed? Is it worth continuing for another week/fortnight/month? The odds are, by making small, mutually agreed corrections early and frequently during delivery, the product becomes much more likely to succeed, and if not, significant budget, effort and stress saved by recognising this early.

Following these simple pieces of advice do not guarantee success. The supermarkets are sold out of silver bullets, and the world supply of magic project beans has had an unfortunate run-in with some weed killer. However, I do guarantee that by simply appreciating the skills others bring to the project, and having honest, sensible discussions with each other, you will be less Igor-like, and your project will stand a far better chance of succeeding.

Wednesday, November 08, 2017

Careful with that brain, Igor!


So - you have invested in transforming to an agile development process. Your teams have honed their processes until it runs like clockwork, and are resilient to changing needs. Software is being produced cleanly and efficiently with minimal fuss.

But there is still something missing. The software simply doesn’t do what you expect. The customers don’t like it, and won’t use it. It has annoying quirks and foibles that put people off. It simply isn’t right. What’s going on?

Congratulations! You have discovered the Achilles Heel of all software development. It has to have an undamaged brain. A well disciplined agile team will deliver whatever its business brain asks of it. The team is only as good as its inputs and subsequent feedback on its deliveries.



Or to put it another way, so-called ‘agile’, and all other software delivery processes for that matter, rely on sound business thinking. Make Abby Normal your customer/Product Owner, and you will be in serious trouble.

At its heart, agility is about delivering a product iteratively, delivering a small slice of value for validation, and getting feedback whether it is right, allowing corrective action as needed as lessons are learned. This means that for software delivery to succeed, business - however you define it; customer/product owner/whatever - must engage fully. This includes providing a definitive product vision to the team, prioritising what needs to be delivered next, and making decisions based on the results of each iteration. Throwing away work is perfectly valid, and can be beneficial. Break this feedback control loop and it will not work, no matter how good the team is.

By treating projects as a series of small, iterative gambles, the business becomes far more likely to succeed in delivering what it intends. The business, as well as the team providing the raw development talent, needs to be agile in its thinking. If it’s not, then you run the risk of putting an abnormal brain into a seven and a half foot long, fifty four inch wide gorilla....

Don’t be an Igor.