People Power
Reflections From Lean Agile Exchange 2021
As both an agilist and software engineer, I enjoy attending a mixture of conferences. Yet in discussion with developers I sometimes am asked what kinds of topics are normally covered. Or even hear jokes about which methodology won in the battle of Scrum vs Kanban (sigh). Or even asking about the soft skills covered with derision, thinking that the lack of super technical content makes them less interesting.
The reality is that Agile conferences cover a myriad of content encompassing various domains, including but not limited to psychology, sociology, agile theory, leadership, testing, software engineering and others. While some may consider technical knowledge to be specific to programming and computer science concepts, I would suggest knowledge in these other domains shows technical expertise. Here I reflect on some of the amazing sessions I watched and presented this year, and what I learned.
Uncertainty Still Prevails in our Work and Personal Lives
The events of the global pandemic over the past 18 months were very much a theme in many sessions at the conference, including in the opening keynote by Sam Conniff, titled Uncertainty Experts. The reality is that uncertainly also impacts us within our day to day work and home more generally. Sam tells the story about how in the face of difficult personal circumstances he interviewed individuals who had faced significantly challenging times to discover how they handle uncertainty. This is an interesting concept as humans are not really wired to handle uncertainty very well. It’s not just me!
If you are curious, KPIs are business metrics that reflect the performance of the department or organisation. However, OKRs are goals you set yourself to improve you performance and drive the change you want to see. This piece summarises it well that KPIs measure performance and OKRs help you decide what to change or improve.
The people he interviewed have been through far more significant challenges than most of us have in our lifetime, including but not limited to prison time, abduction, undergoing gender transition and gang membership. Through these interviews and collaboration and a group of scientists, he discovered the 3 primary factors that affect our ability to handle uncertainty:
- Through fear we default to automatic responses that have worked for us in the past. These are known as safety behaviours. This interesting fact sheet gives some very relatable examples of safety behaviours that I’m sure all of us have exhibited.
- A fog comes over us which stops us from reacting, known as uncertainty tolerance. As a very risk averse person I definitely see myself as having an intolerance to uncertainty.
- Conviction Narrative Theory enforces a level of stasis in us which leaves us struggling to adapt to the current situation.
Sam has since collaborated with scientists to produce an interactive documentary to help participants build resiliency when facing uncertain events. I’m definitely interested to see the impact as building resiliency following a bad case of burnout in 2020 has been a focus for me in 2021.
Our Bad Questions Impact the Response We Receive
Collaboration and communication are required elements for working in software development teams today. From some coaching training I’ve attended in the past I know that we need to embrace open questions to give people the space to speak their mind. However, through Priya Sinha and Ragan McGill’s session I discovered there are other types of questions that could be impacting the responses we get.
In Seven Sins of Questioning, they cover 7 other question types that we should avoid in our communications:
- Question Stacking where we ask all the questions at once in a large brain dump. I see many people, including myself, resorting to this tactic.
- Leading questions that you ask assuming the other person is wrong. These can come across as arrogant or annoying.
- Why questions that put people into a defensive mode. I see these are commonly asked when things go wrong, and thinking to Mehmet Baha’s session on Psychological Safety, could impact the ability of a team to perform intelligent and improvable mistakes that we can grow from together.
- Dirty questions that carry a subtle bias, but don’t carry the message that the other person is wrong. A good example is where your question implies an action.
- Binary questions where responders can only answer yes or no. There are many shared of grey in this world, meaning that most of the time the answer isn’t simply yes or no.
- Self-affirming questions. These are often binary, but carry a special motivation to coerce agreement.
- Aggressive questions that provoke people to make assessment about the future before they are ready. The speakers recommend using the Present, Past, Future framework as an alternative to this approach.
We are all guilty of asking these types of questions. What’s important is to be mindful of these questioning antipatterns, and avoid them where we can to ensure respectful communications with colleagues.
We Should Embrace Being Blocked
Handling blocked work items is not specific to software development practices, but it does cause us all pain. Perhaps it’s down to the impact of interruptions on flow state, which is a rather unique construct of programming. I found an old article that suggests it takes an average of 40 minutes to resolve a blocker. This does overlap slightly with a recent talk given at Devoxx UK on the developer experience, which I’ll share my thoughts on soon.
The importance of being blocked by Nick Brown rightly points out that we become blocked for a variety of reasons. While I assume the aforementioned 40 minutes concerns factors within our control, such as breaks to search an error message, or perhaps struggling with our tooling, organisational dependencies are also a factor. Particularly for those working at larger enterprises where we can perceive particular procedures and bureaucracy to be unnecessarily hindering our productivity. I’ve been there!
I agree with Nick that most teams do not have a consensus on what blocked means or how to handle blocked work. This observation mirrors my own experience of using obstacle boards a few years ago, which I presented at LAX 2020. We found that by using an obstacle board for data integrity impediments that team members therefore only considered those types of impediment to be suitable for capturing, and failed to adapt it to include other elements that blocked their work.
We’re naturally conditioned that if we get blocked on something, we keep busy and move on to something else, which can be a bad idea. I was reminded of this only this morning, where I logged in to see 1 column on our Kanban board was breaching the item limit. Even a glaring red state can be ignored in our pursuit to be productive. It’s important to enforce limits, and focus on clearing these states together.
Technical Debt Is Difficult to Define
Einar Host’s session Technical debt isn’t technical was a session at the top of my watch list when I pulled together my initial list of talks I wanted to attend ahead of the conference. I find we struggle to agree a common definition as to what technical debt is. Discussions and debates with colleagues over the years show it is a wide ranging term, where we consider troublesome parts of the code, potential refactoring(s), infrastructure upgrades, architectural transformations and even regular library upgrades to be potential technical debt. Even at conferences I have similar discussions with individuals working at other technology firms, so no organisation is immune to this debate.
Einar interestingly refers to the term technical debt as a meme of sorts. Rather than an amusing picture and text combination like this, he is referring to a term that we have unconsciously picked up without realising it. In 1999, the Los Angeles Times likened these ideas as a kind of virus that is propagated through the population irrespective of it’s truthfulness or adherence to logical principles. I do agree that technical debt has become such a term, leaving us unable to determine it’s true meaning or origin. I’ve also found many terms in my time from both the technology and finance domains that people know and rhyme off without knowing the true definition. A key one from my first week as a graduate engineer was Defined Liquidity Group, which people used without thinking. Anyone who is curious about what a DLG is can check out this overview from the FCA.
Einar summarises that the definition of technical debt is that horrible spaghetti code containing many logical branches. His story from his own employer, a Norwegian TV company, definitely proved feed for thought for me. The different types of TV shows and their varying consumption methods, such as the news compared with a series compared with a docu-series, reminded me of similar issues I’ve seen in my time. Not only will you struggle with these as the system grows, but it will be a nightmare for those looking after your system in 10+ years time. I’ve been on the receiving end of both of these scenarios and neither are pleasant!
The Different Between KPIs and OKRs is Often Confused
I’ve struggled with the difference between KPIs and OKRs myself. Cansel Sorgens had a great talk on this, using her own experience of building her own OKR coaching and training function to explain the difference. The session was very interactive, with some polls to show the differing understanding in the room.
If you are curious, KPIs are business metrics that reflect the performance of the department or organisation. However, OKRs are goals you set yourself to improve you performance and drive the change you want to see. This piece summarises it well that KPIs measure performance and OKRs help you decide what to change or improve.
The Spotify Model Exists But Is Often Implemented With Antipatterns
I was really interested to see the keynote So you copied the Spotify model — here’s what you got wrong as a variant of the Spotify model was the transformation technique used by my current employer. Joakim Sunden was an Agile Coach at Spotify for many years, so I felt these insights would come from someone who had been there, done that, got the t-shirt. That was indeed the case.
In my own experience I already knew that we had adapted the model. I was also not surprised to hear his sentiment that many organisations exhibit many antipatterns in their adoption of the model. I’ve definitely seen many of them applied in practice, most notably using chapters to represent reporting lines. In my personal experience, organisations use this to mirror their existing structure over more radical change. It also leads them to struggle to reflect the technical disciplines that it should represent, leading to confusing jargon that tries to cover both bases.
While I’ve not used SAFe, this was also discussed as having some questionable adoption. Speaking to colleagues and family I’ve seen SAFe applied without much thought, leading to teething problems. I find putting scaling frameworks directly on top of an organisation without attempting to foster the collaborative and psychologically safe culture leads to much distress and frustration for people. His advice to identify pockets in your organisation that are adhering to the target ideals, and considering SAFe as a toolbox of techniques that don’t all have to be applied resonated strongly with me.
Loneliness and Bonding Affects Our Performance at Work
Emily Webber’s keynote The Magic of human Connections focused on just what the title states, which reflecting on how the pandemic has negatively impacted our ability to establish those connections. I was rather surprised to find out that loneliness impacts our performance at work. Thinking of my own experiences over the last year I do see that aspect in my performance, where as 2020 rolled on and I felt more isolated, I struggled more at work. She also highlights the are 4 key elements of modern teams that can increase loneliness:
- Moving people in and out of teams
- Encouraging segregation of duties which can leave people feeling interchangeable
- Moving people to temporary secondments, or splitting their time between teams
- Establishing short-lived teams to work on temporary projects
I hate to say that I’ve seen all of these antipatterns applied. Not only applied to myself in contributor roles from managers, but I’ve also performed the same sins as a prior manager as well. I definitely intend to avoid such patterns in the future as best I can.
Bonding within teams was also highlighted as a contributor to performance. People who feel connected to their colleagues feel less lonely and therefore perform. It has definitely been my experience that bonding is important for establishing and resetting teams, as I outlined in my own talk Confessions of a Sprint 0. People need to feel they belong to a community of sorts. I loved Emily’s story about setting up random coffee matches within her Agile In the Ether community as it shows a great way to expose people to serendipitous connections.
Final Reflections
Yet again I felt that I left LAX with more insights than I entered. There were so many other lessons that I learned at the conference, to the extent this blog could probably be double the length. So instead I encourage you to search for the videos when they are available on Vimeo in a month or so. Until then, consider a question we were all left with at the discussion session Shifting ways of working- what have the last 18 months taught us?. I am still asking myself How do we look out for those struggling who are not raising concerns in our organisations? I leave that for you, dear reader, as some food for thought.
Thanks for reading! Looking forward to (hopefully) attending LAX again next year.
Originally published at http://carlyrichmond.com on November 5, 2021.
