Get Off the Phone

A Year of Having No Work Access on My Personal Phone

For many, the end of 2021 and start of 2022 has been a time of reflection and comparing for many of us. It doesn’t help that this year social media sends us flashback reminders of prior years. Through the pandemic some of these has prompted feelings of hope for us, such as photos of holidays and family events. Nevertheless, reminders of 2020 events have shown times of great strife and regret that we would probably care to forget.


I also have similar experiences when flipping through prior blogs. They can help generate new thoughts and insights for me, which I always appreciate with a wry smile. A recent unpublished blog has got me thinking about back to January 2021, when I made the decision to remove all work applications from my phone. It was an easy decision to make at a time where I was burned out and our family were struggling with isolation after spending our first Christmas and Hogmanay, or New Years for those non-Scots reading, locked down in London away from friends in family in Scotland. I remember coming back from a two-week vacation with an uncomfortable static buzzing continually prickling through my brain, and black raccoon-like bags weighing down my eyes.


Dialer Phone

Phone are not just for chatting anymore!


It is now one year later. As I come back from a truly relaxing break with my family, embracing the joy and giggles of a happy toddler eagerly playing with his grandparents and cousins, I am glad I didn’t finish and hit send on that piece. Time and distance have helped me consider the decision in a more pragmatic way, and truly see the benefits this has given me for my work and home life separation. I did make other changes. Moving role, adding night off Thursdays to write or lounge in the bath, and ensuring I prioritise work items that I enjoy over the slog of the next item on the to do list were great aids to my mental health and wellbeing. But the most impactful one was definitely wiping all work apps, including email, from my phone.


In the midst of my return to work, I also had a conversation with a mentee who was considering installing works apps, including email on their phone. Over the years I’ve had many of these conversations with recent graduates, and each time they make me think about how keen we are to plug into the matrix of work before considering the consequences. Here I share the drivers that caused me to refute Bring Your Own Device, or BYOD, as a productivity driver, and share tips and tricks to help you decide whether unplugging from the work Matrix will work for you.


Why Do Fools Fall in Love?


The tale of how I came to be plugged in is probably an experience shared by many engineers in their initial rise through the ranks. I received my first dedicated work handset a few months after starting after a late night in the office monitoring report submissions. At this time, it made sense as it allowed me to monitor from home without needing to login from the office, or even connect remotely from home.


When the company adopted BYOD a few years later, it seemed like a natural thing to immediately adopt since I was used to having some connection to work. Despite discussion with a good friend about their decision to not adopt BYOD on returning their device, I decided to keep my access. At this point I had formed the bad habit of checking emails on my commute and at home in the evening, much like many others as discussed in this piece from 2015. I told myself it helped me see what I would face the next day and form a plan of what I needed to tackle when I made it to the office.


Mum Juggling Phone and Baby

In hindsight keeping an eye on work emails through maternity leave was probably not very healthy!


I even continued this pattern while on parental leave. I told myself at the time that it was a useful means of keeping connected to the project to which I would be returning. I listed it as a valid learning mechanism for keeping up to date. It also formed my opinions about email as a bad medium for software alerts, which I reflected on at the time, as I found test environment alerts flooded my inbox making it difficult to find useful content. In hindsight, I now consider it more to be a symptom of FOMO and fear of being forgotten by my team. Especially since I was moved project on return to work, the time does feel wasted.


When the pandemic hit, I added our chat app to my phone to ensure I was contactable at times where I was looking after my son. I’m sure any parents reading will remember the challenge of that time. I found this constant connection contributed to a rather nasty burnout in December 2020. I have vivid memories of one lunch time where my phone was buzzing off the table with messages from my team to try and action an urgent approval while I tried to feed a weaning baby. I also found that many of us as we adapted our work hours around personal circumstances defaulted to using chat apps for everything, leading to notifications late at night for non-urgent queries.


Stressed Man on Mobile Phone

Maintaining a work connection on my phone meant I was always on when working from home


It was clear to me I was no longer reaping that perceived benefit of preparing for the next day. Instead, it made it difficult to sleep as I thought of the next problem I would deal with in the morning. I had been giving advice to colleagues, graduates, mentees and team members at that time to think about if they should have this connection to work. Yet I never took my own advice through that time. It was this realisation that led me to pull the plug and uninstall all work apps from my phone.


Who’s Zoomin’ Who?


My story may resonate with you at this point. It may not quite have you convinced. If you fall into the latter camp, you may now be rhyming off the reasons you need to maintain your work connection after you log off. I’ve been there! I found that noting down when and what I did on my phone in a couple of days and compared them to my motivations for having the access, was helpful. I ended up with something a little like this:

It’s worth noting down your expectations versus your mobile work activity to assess if they align

I regularly told myself that I needed to be connected to help plan my working day on my commute, but also to ensure I could support my clients and cover support emergencies as they arose. I now see from the above listing that it had evolved to searching for issues that it became a problem. Or as an attempt to multi-task when I really should have been focusing on picking up the food Mini R was enjoying throwing around the floor. Part of the problem in that latter scenario is since you don’t really have context of the message, you don’t know if it’s ignorable or not. Meanwhile, now that I am only contactable via a phone call, I’ll only be contacted for true DEFCON 1 instances, leaving me time to focus on lunchtime.


The other opinion you may have, which many new developers and myself at one time have, is that you don’t have anything else to monopolize your time. Therefore, occasionally checking work while chilling with Netflix isn’t the biggest of deals, and not a major inconvenience on my time. While I do agree that I no longer fit in this position, and now that I have a family my time is more important, I do have some regret of the things I could have used that time for instead of working.


Bubble bath with wine glasses

Among other things, I wish I had taken more bubble baths instead of being on my phone


Perhaps I could have written more. Or took part in more spare time coding. Or taken many more relaxing baths, which I now wish I had the time to do. Or had more uninterrupted conversations with my partner instead of us both sitting glued to our phone while watching TV. Or even gotten through an extra book or two if I did want to ignore Mr R watching the football. Be more respectful of our time outside of work. Even if it works out at around 47 minutes a day.


Constructing the Connection


I know I won’t have convinced all of you. I may be lucky if those determined to maintain access to work on their personal devices have even read to this point. New features are available on our phones to help us manage application time more effectively, which either didn’t exist or I didn’t know about when I was a member of the BYOD club.


Broken Phone with ERROR 404

These days you will not find any reference to work on my phone, and I’ve never been happier


My viewpoint will definitely not resonate with everyone, so if you are in the pro-BYOD camp, I do have some tips to help you avoid some of the challenges I faced before I pulled the plug on BYOD:


  1. Think about your role and the potential reasons people may wish to contact you. This can help you triage messages and decide which are DEFCON-1 panic stations compared to the sleepy normality of DEFCON-5.
  2. Avoid blindly downloading all available applications or setting up all media on your phone. Take a moment to think about which applications you truly need to access based on the reasons you have previously identified.
  3. Block out your evenings on your calendar to protect your evenings from calls. This is particularly important for those working for global organisations outside the US.
  4. Set a limit of the amount of time you spend on these apps outside of work, both at evenings and weekends. Try setting usage limits or focus time settings for those applications to enforce your limits. Some apps allow you to do this within the software itself, but Android and iPhone have various wellbeing options that you can use to limit applications, and set do not disturb settings for overnight.
  5. When using these applications outside of this time, be mindful of your own usage of chat versus email for any messages that you send to avoid distracting others. Try to respect the decision of others.
  6. Preferably try to have access free days at the weekends to get a true break from work.
  7. Consider having your phone number available in the company directory or shared with relevant colleagues for true emergencies. This is one that I have kept as a compromise.


Irrespective of your choice, no way is right or wrong. I know that having that separation is definitely the right decision for me. I wish I hadn’t rushed into connecting to the matrix so quickly. Together we need to respect the decisions of those who are unplugged versus plugged into work all the time. What is more important that we take care of the wellbeing of colleagues in both groups and be on the lookout for burnout in ourselves and others.


Thanks for reading! Best of luck finding the work connectivity that works for you. Do reach out if you would like to share your experience or want to discuss which option may be right for you.

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!


Directional Arrows


We face uncertainty in our work and personal lives


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:


  1. 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.
  2. 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.
  3. 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:


  1. 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.
  2. Leading questions that you ask assuming the other person is wrong. These can come across as arrogant or annoying.
  3. 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.
  4. 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.
  5. 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.
  6. Self-affirming questions. These are often binary, but carry a special motivation to coerce agreement.
  7. 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!


Women With Hand Up


Embrace being blocked!


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.




Rather than an amusing picture and text combination like this, the original definition of meme, or memetic refers to a term that has become ingrained in the collective consciousness


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.


Dashboard Charts


Think carefully about the KPIs and OKRs that you track


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.


Comic Agile Spotify Model


A common antipattern of Spotify model role-out that I’ve seen is keeping the existing department structure but changing the names


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:


  1. Moving people in and out of teams
  2. Encouraging segregation of duties which can leave people feeling interchangeable
  3. Moving people to temporary secondments, or splitting their time between teams
  4. 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.


Hand on the window


Nobody wants to be lonely


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.

Coming to the Stage

Comparing In-Person and Online Meetup Lightning Talks

I hear the buzz of murmurs for an excited crowd. The sound of glasses and beer bottles clinking as strangers meet and introduce themselves hums behind excited conversations. Heat from the lights and projector hits my face. The smell of wood from the bar floor fills my nose. A strong feeling of fear resting in the pit of my stomach rises towards my throat.


Terrified Woman

Speaking in public is a terrifying prospect for many of us


This might sound like the confessionals of a stand-up comic or breathy saloon bar singer. However, dear reader, this is the memory burned into my brain as I took to the stage for my first ever in-person meetup talk. My symptoms sound rather like those of a fear of public speaker, just as Deborah Frances-White outlines in her amazing TEDx Talk on stage fright. Deborah shares a great theory that fear of public speaking stems from our survival instincts, and the need to avoid being lunch. You might think this is not the biggest deal. It was a ten-minute lightning talk. Hardly an escape from a pack of lions!


Yet for me it represents a major milestone in my continuing speaker journey. I started dabbling in technical speaking just over a year ago, through the global pandemic. With many meetups and conferences taking place online through that time, all my experience is based in the online world. Often, I would stand in my spare room, talking at an empty screen. That is vastly different to the in person experience I have just described.


In the hopes of dispelling some fear and myths of those others who, like me until recently, have only presented online, I regale the experience of my first in-person meetup. I will discuss the key differences between these two formats. Finally, I will give some useful tips to help you prepare to step out into the physical spotlight and give your first in-person talk.


Back Stage Pacin’


Despite having given a longer version of the same talk at a couple of online meetups, I still felt exceptionally nervous ahead of this first engagement. Part of the reason was down to going to a new meetup, with a lack of familiar faces in the audience. Poor Mr R was subjected to two practice runs in twenty-four hours as I tried to prepare and adjust to the altered talk flow.


Those same nerves did not disappear on the train. As you can tell from the below tweet. Instead, I tried to think of the advice I have heard from many fellow speakers that nerves never go away, and that it is simply a case of embracing them.

As you can see from my pre-event tweet, I was feeling pretty nervous!

I got chatting to a couple of people when I arrived, which was a welcome distraction. When the time came for the session to start, I grabbed a seat at the front to make it easier to step up to the stage at my slot without worrying about tripping over others, or indeed my own, feet.


Speaking to a new group of people when you are establishing yourself contributes to your nerves. While waiting your turn in a group of speakers can build up your fear, when new to a setting it can also help you get a feel for the audience, as well as being useful for picking up presenting tips. Thankfully, I was one of Five speakers that evening, and the last to go. This gave me the opportunity to see how chilled out and welcoming this group were.


Stage Fright


Taking to stage felt like a surprisingly natural thing. Most likely my brain telling me this is the same as all the online talks you have given to your laptop before. I could not employ the trick of speaking to the friendly face because, not to say that this audience were not friendly, but they were strangers to me. So, my focus point tended to float around the audience to prevent me uncomfortably staring at one person for the entire talk.


Woman on Stage with Microphone

It is far easier to gauge the interest of the audience as you speak when you’re in front of a live audience, compared to black boxes on Zoom


One of the key advantages to speaking in person if you gauge the interest of the audience as you speak. With online talks, there is a great disparity in the level of feedback you get as you are speaking. Depending on the audience and tooling of choice you can be speaking to boxes of nodding heads, black rectangles, or even a black void in the case of Webinars.


In person you can determine the reaction to segments of your talk. I discerned the nods and smiles as showing acknowledgement of a potentially insightful point. Laughs meant that joke I made landed well. Even the one about hurrying up so we could all get to the bar seemed to get a small chuckle! Thankfully I did not see anyone screw up their face in offence or derision, so no controversial points seemed to have been made by myself thankfully!


Person Asking Question with Raised Hand

In my experience, answering questions are a common attribute to both types of meetups


One common attribute shared by in person and online talks is post-event questions and feedback. Online meetups normally include a few minutes for questions after a talk that can be asked directly or via the integrated chat feature. In person, while there was no Q&A segment, people were happy to approach me afterwards with any questions they had. I even got some great suggestions on how to improve my slides by a fellow speaker, for which I am incredibly grateful.


Online, I have found that feedback is normally submitted afterwards in forms or in the integrated chat. I have always enjoyed answering questions and using those perspectives to inform future talks. It was reassuring to find that common trait between these two formats.


She’s Still the Star


Overall, I found that many aspects such as questions, nerves and support are very similar between online and in-person meetups. Given that many in-person meetups have spawned from a need to move in-person sessions online to meet the needs of their communities, this makes a lot of sense. Online communities are very accessible to people who need to be home in the evening for caring or other commitments, and there is still a need for both formats as the state of hybrid working evolves.


Bar conversation over drinks

In person meetups allow for organic conversations over a drink, which are missing from online forums


Nevertheless, one element of in-person meetups that I do not feel has been replicated successfully are the conversations you have after the talks are over. Talk questions organically morphed into full conversations into technology, best practices, and career experience. I have seen attempts to replicate this practice with post-event breakout rooms.


The unfortunate reality is that most people will head off from an online meetup as soon as the meeting closes. It is almost as if working remotely has morphed these jovial encounters into another meeting slot. I hope in time we will come to figure out how to integrate the social element into online meetups to preserve their accessibility.


All the World is a Stage


Overall, my first in-person meetup experience was a positive one. Much like the online communities I have spoken at, the audience wants you to succeed. I am not the gazelle that this pack of hungry lions wants to eat. They are actually more interested in pacing around the bar after I speak in search of a libation.


Audience With Love Heart Hands

Meetup audiences, unlike a pack of hungry lions, want to see you succeed on stage


I am glad to have participated in this exercise. It serves as good practice for my next in person speaking engagement for when conferences resume. I am hoping to speak in person at Devoxx UK in November, assuming in person goes ahead. I am so excited to have that opportunity. This first in-person experience has been a good starting point focusing on a smaller audience, that I hope to build upon in future.


Thanks for reading! Do share your own experiences of lightning talks, in any format. I would love to hear how you get on!

Let The Record Show

Confessions of Creating My First Pre-Recorded Conference Talk

Recording yourself is hard! Recording yourself is downright uncomfortable! Nevertheless, with us all working from home for the past year it has become a more common format for conference talks. Live talks are still happening, and for tips and tricks for that format I recommend you read Helen’s amazing blog post on the topic.


Up until now all the talks I’ve given have been over Zoom. Despite those all being recorded, I’ve only once had the nerve to watch myself back. I’ll be honest, it was not comfortable.



Recording your first pre-recorded talk feels just as intimidating as standing in front of the mic for the first time


I recently had to record and edit my first talk. I made a lot of mistakes while doing it. And many of them seem completely daft now! Through sharing my Confessions of a Sprint 0, I’ve also uncovered a new set of admissions relating to the challenges of recording my first talk, and more mistakes that I have made along the way. Here I regale the lessons I’ve learned, as well as some right daft tales of getting your first recording wrong, to ensure that your first recording experience goes more smoothly.


What Makes These Talk Types Different?


In my continuing speaking journey, I have been fortunate enough to have given talks at various forums including speaker groups, meetups and one online conference. I have observed that there are several key differences between live and pre-recorded talks that make them more difficult to prepare for:


  1. It may sound obvious, but they are due earlier than the conference. This means you need to be slightly more organised about preparing for the upcoming deadline.
  2. There are stricter boundaries between the speaker and the audience. This can make projecting your natural energy and authenticity difficult.
  3. It will take a lot longer than you expect to prepare. In addition to the recording, you’ll also need to spend time editing the recording as well.
  4. Speaking of editing, it may be the case that as a new speaker that you don’t have any editing experience. You’ll also be unlikely to have any editing software installed on your machine. I fit into both of these camps!
  5. Using some formats and mediums are no longer available. Techniques such as polling are not possible unless you ask the organisers to incorporate a live element at the start.


Tips and Tricks


Despite these challenges, I do have some tips that will help you pull off looking like a pro-speaker, even when recording at home.


How to Show Genuine Energy


As you can imagine, talking to yourself is pretty uncomfortable. It’s easy for that energy to translate badly in a recording. Even someone as bubbly as myself came across as flat when I did my first recording on my own. I was so unhappy with that version that I re-recorded the entire thing again before editing.


When giving a talk, you want to come across as genuine, and project your natural energy. I found practicing a few times before you even start recording helped me settle the nerves and find my flow. I did have simple notes up on the screen for each segment to keep track of where I was. However, I recommend you avoid running through a fully written script unless you are confident it won’t sound flat.


Man behind the camera

It’s difficult to show energy to an empty room, but there’s nothing stopping you having some moral support hiding behind the camera


No one really said you had to speak to just the camera. It is possible to try and elicit help from a friend. This individual could either join muted to a video call that you are recording. Or, in my case as my helpful husband did, stand attentively behind my laptop, so I could look like I was looking at the camera, but was speaking to him instead (thanks honey!).


How to Record Yourself


There are two key themes you need to be mindful of when recording yourself. The first, and hopefully more straightforward item, concerns the software itself. You can easily use the default camera app on your PC to record. However, if you need to apply a background for the conference, or in my case blur the background since my curly hair interferes with the background, you’ll need to use alternative software.


With us adapting to working from home through the global pandemic, we have had to acclimatise to video meeting tools such as Zoom or Microsoft Teams. Zoom specifically has a recording function, which can also be used with the free version. Simply join a new meeting, setup your background or blur, and hit the big recording button.


Recording Sign

Consider your recording plan before you start recording, but it in parts or as a single run


Before you hit the recording button, take heed of whether you want to record in a single run or in sections. I initially took the advice to record my talk in batches, and split it into sections of a few minutes that would fit with my transitions and section slides. For me personally it didn’t work for several reasons.


  1. Trying to record segments between meetings meant I didn’t have continuity of lighting through the recording. So be mindful that the segments need to be recorded at a similar time of day.
  2. I would psych myself out when I made a mistake, meaning I would try again and get into a loop of making mistakes. Before you ask, I’ve now deleted the bloopers reel so unable to share these. Sorry, not sorry!
  3. I would cut at the slightest mistake, rather than accepting the imperfections that show my humanity and leave them in. This meant rather than having a perfect video I would have loads of continuity issues that I had to address through transitions. It would have been better to keep the stutter over going from wide smile to concentrating brow in a single frame!
  4. I struggled to keep to time, since I was recording in segments. This resulted in a far longer talk than I wanted. Editing the recording to time without introducing continuity errors was impossible.


In the end, I took the advice of my conference mentor and recorded the talk again in one take. Thankfully, since it was 15 minutes long I could do this. For talks longer than this I would try to break it into 10 minute chunks, that I would time, and included transitions to address the continuity issues. Also make sure to add a buffer of at least 1 minute to ensure you don’t run over. I would also add in transition time on top as I just squeezed in at 30 seconds under time when this was taken into consideration.


Editing Tips and Tricks


Unlike some friends and colleagues that have experience of video editing from their side hustles, this was my first time doing any form of video editing. Whenever I’ve had to record sessions in work, I tend to air on the side of hitting upload. Mainly because sessions included Q&A segments where I wanted to share the questions and answers. But there was also a part of me that dreaded watching myself back and saw a direct upload with "Och it’ll be fine!" to be a way of avoiding an uncomfortable experience.


Watching yourself is hard! You’ll spot imperfections like your hair being out of place. The non-mirrored view may be rather confusing. And you will not be able to stop yourself wondering "Wow, do I really sound like that?!". Although many have told me it gets easier over time, I’m still not quite there yet. And when you’re having to watch segments over again to try and perfect alignment with slides or to add in transitions, it becomes and even more uncomfortable experience.


Person editing a video

Watching yourself while recording can be quite an uncomfortable experience


What will help with the discomfort is trying to avoid editing excessively to make yourself sound perfect. Editing out ummms, brief stutters and embarrassing moments when the dog walked in or the doorbell rang can have a negative impact on your continuity when cut.


We’re often given feedback in presentation workshops that ummm is a bad word, that should be avoided to achieve presentation perfection. The reality is the occasional one is not a big deal. We’re all human after all! Embrace the occasional imperfection in your recordings and focus instead on ensuring continuity of flow, particularly when it comes to hand gestures and positioning.


How to Produce a Quality Video


Editing my first recording was very much a learning experience for me. I was fortunate to attend a workshop that gave some tips on recording and editing. Examples were editing using Camtasia, and it initially looked very simple. But upon seeing the high cost, and not having any other need for editing software, I began scouring the internet looking for a free alternative.


Free trials for many popular tools, and some other free to use tools were out as they added a watermark on the video. You definitely don’t want a tool watermark in your for a conference recording! I settled on OpenShot, an open source editing tool that doesn’t add a watermark.


I had to redo my edit a couple of times as I dived straight into editing my video after watching a couple of tutorials on YouTube. Looking back on the experience now, I wish someone had shared the below tips with me.


Managing Layers


Firstly, try and keep each content type on its own track. I found it helpful with ensuring transitions between my section slides and video segments were clean. It also helped prevent situations where the accompanying slide hid my video, especially in the segments where I am visible at the bottom corner of a slide.


I had a slides layer, a video layer and a section transition layer to keep myself right


Splitting Video


There will most likely be small cuts that you need to make. One possible reason to remove segments is to eliminate trailing segments at the start and end when you’re pulling your concentration face to find the start or stop button. Another reason could be removing segments to meet time constraints or that must be removed even to keep with our not so perfect ideal. Or even just splitting video segments apart to make transition management easier.


Most tools, including Open Shot, have a paddle that allows you to forward through segments. From this point, you can select the video segment you would like to cut, right-click and select the slice option. You will be able to keep both sides, or just the left or right as you can see from the screenshot.


You can slice video segments and keep either one or both segments


Separating voice and video may be something you want to do if you have busy segments such as animations or content showcasing an interactive workflow. I initially experimented with this technique, which is very simply in most video editing tools. If they are anything like Open Shot it’s a case of right-clicking the video segment you want to split, selecting one of the separate audio options (most likely single channel) and deleting the video segment to keep only the audio.


You can choose to separate video and audio to keep audio only


In my case I kept myself on the screen throughout, alternating between the bottom corner and full screen. Ideally you want to present yourself on the screen throughout. It is you and not the slides that are the main event!


Slides and Transitions


Producing a simple recording of yourself on video with no other content will be far more straightforward. However, to give your talk a more polished look, to show materials or references for the audience to capture, or even to walk viewers through more technical concepts, you will need to add additional content.


In my case, I added slides to my presentation to fulfill three objectives:


  1. Separate sections of the talk
  2. Showcase key resources
  3. Reinforce the tips and tricks I gave at key points in the talk


Camtasia would make slides easy to include as it has a Powerpoint plugin. However, Open Shot does not have such a feature. Instead I had to export my slides as images and import the images to Open Show as project files so I could include them on the desired track.


To ensure a more polished finish, you’ll also need to add effects to ensure a clean transition between the video and slide content, or to accommodate any continuity errors.


Open Shot allows you to add transitions onto a media element. This is done by selecting the transition effect of choice and dragging it onto the media element which you want to apply it to. I generally found using fade with a duration of 1.75 seconds worked for me.


Drag a transition from the panel onto the media to apply it


I would also suggest adding the same transition reversed on the other side for symmetry, which can be done by right-clicking the transition and selecting the Reverse Transition option.


You can also reverse transitions at the other end of a particular media type for symmetry


Video Exporting and Profiles


You might think that once you’ve gotten past the challenges of editing and watching yourself repeatedly that the hard part is over. However, there is one gotcha left that rather badly caught me out. It concerns editing and exporting profiles.


Conferences will specify a format to provide your talk, most likely MP4. But there are various different profiles that correspond to that format relating to size, pixel density and frames per second of the video.


Initially I found that my recording audio had a 1 second delay compared to the video. It turned out I needed to specify the same export profile as the profile in which I edited the video.


Look for something like Choose Profile from the File menu, which is exactly how it is made available in Open Shot. The same profile should be selected in the export dialog, accessible using the Export option under the File menu.


Check what profile you are using while editing…
…matches the export video profile


Closing Comments


Looking back now, recording my first talk was not as stressful as I thought it was going to be. Setting yourself slightly earlier deadlines and checkpoints, just like any work deliverable will give you additional time to try and redo any segments that you later decide are not quite right. If you are representing an organisation that would wish to view the recording before it is sent, also factor that time into your deadlines to ensure you’re not late submitting your talk to the conference.


I hope that by sharing my experiences of my first pre-recorded talk that you will feel better prepared for your own. In addition to the guidance I’ve outlined here, I strongly encourage you attend any support session the conference runs to help you with recordings. Also ensure that you read any recording instructions the conference gives you prior to hitting the record button.


Thanks for reading! Do share how you get on with your own pre-recorded talks. I would love to hear how you get on!

The Great Impostor

Tackling Tech Impostor Syndrome

When we were young, we relished the opportunity to pretend to be someone else. Perhaps you were a fan of playing astronaut. Or pretending you were a wizard at Halloween when you were wee. Or later when you pretended to be older and more grown up to sneak into an older rated film. Don’t worry, I won’t judge!


As professionals we lose that joy. In our current roles, being someone we think we are not feels far more stressful. As does striving towards the dream roles that may appear out of reach. Rather than enjoying the escape, we feel like an impostor who will eventually be found to be engaging in a campaign of deception.


Venetian Mask

Many technologists feel they are hiding in wait of the mask being listed and them being discovered to be inadequate


Irrespective of whether you have experienced it first hand, or are comfortable stating openly that you have, I’m finding that the majority of people working in tech and finance today have heard of impostor syndrome. A study taken in 2020 by professional community Blind, found that 62% of surveyed tech and finance professionals fear that people will find out they are less intelligent or capable at their job. That’s potentially a lot of people feeling inadequate in their role. If you are unsure if this applies to you, you could try this quiz.


Through my own career journey, including breaks from active software development for maternity leave and roles in Scrum Mastery and tech management, I’ve found there are points where the presence of that lurking impostor feels more prominent. Speaking to others has only reinforced that opinion. Here I discuss the times where impostor syndrome can be particularly hard to manage, using my own and others experiences, and some learning tips to help silence the faker.


Don’t Let the Sun Catch You Crying


Part of the problem with the tech sector specifically is the high rate of change can make getting started and catching up feel like an impossible task. This amazing piece by Helen Scott presenting the evolution of Java over 20 years shows how intimidating it can be to get back into well established technologies. We must also be mindful that in the Web UI domain where I work, there has been an explosion of frameworks over the last 10 years, which can make your head spin! It is no wonder that any break from being technically hands on can make the idea of getting back out there an exceptionally daunting prospect.



Regardless of whether it’s been 2 or 20 years away from a technical role, getting your hands dirty feels like an impossible summit to climb


You may assume from the above that I’m only talking about a traditional career break. However, that is only a drop in the ocean. Through my own experiences, as well as chatting to others, I’ve identified numerous other individual circumstances that could be a potential target for that sneaky impostor demon.


  1. Transitions between technical, product and people-focused management positions.
  2. Agility focused roles, including but not limited to Product Ownership, Scrum Mastery and coaching.
  3. New graduates taking their first steps into the world of technology who may need to use new technologies and techniques not covered in their degree course.
  4. Interns, placement students or apprentices gaining their first experiences of work while studying at university.
  5. Long term sickness returners.
  6. Maternity and parental leave. Not all new parents in the world have the luxury of much time off with their new arrival, so I would also include those trying to balance sleepless nights with a transition back to work in this category.
  7. Gaps for travel or any other personal voyage of discovery.
  8. Career transitions to new domains, or even for those starting up their own business.


Managers and leaders, do take note of the above demographics as people to watch out for who may need some support getting back up to speed. As a supporter of these individuals, you can help them find time and space to gain their tech confidence back through learning.


The Sun Will Shine Again


There are many resources out there from experts that look at how to address impostor syndrome. Doing some quick research for this piece, I found there was a common theme to their advice.


  1. Remind yourself of past successes and achievements.
  2. Celebrate present wins, irrespective of how small you think they are.
  3. Adopt a growth mindset, to help you accept setbacks and continue to press for successes.
  4. Take solace in knowing that you’re not alone. Think of the your role models who openly speak about their own experiences with impostor syndrome.


Man celebrating success

Celebrate every win, even if it’s as small as finally getting that Gradle build working!


With tech imposter syndrome specifically, it’s also about building the confidence to try again. Just like any learning journey, the road to making piece with this demon is filled with successes and failures. Ultimately you need to remember that your skills that helped you leaning technology X or even how to code the first time around are still relevant. You can try some of these tips to help manage the journey:


  1. Set some small learning goals and build up. Even something as small as raising your first small pull request, or completing a small problem in challenges such as HackerRank or Advent of Code can give a much needed boost to your confidence. It certainly did for me last December!
  2. Dedicate a regular time slot to brush up on old concepts or to learn something new that excites you. I received this great tip from a colleague who used a regular evening slot to juggle interview preparation and family life.
  3. Elicit support from your manager to have dedicated learning time during work hours if you can. Historically as a Scrum Master or Team Lead I found myself repeatedly wondering why people never blocked out time for learning in their calendar. Or why there were no scheduled team knowledge shares. On reflection I could have done more as a manager to adjust capacity to accommodate their training time, therefore giving them the space in their calendar.
  4. Experiment with different formats to try consuming information in a different way. For me, and some others I have spoken to, listening to a podcast while cradling a sleeping baby or folding clothes is accessible. You can find out more about my own experiences comparing my work and maternity leave learning preferences here.
  5. Seek feedback from managers and mentors on your progress. This week, as I was banging my head against the wall when something wouldn’t work, I thought I was a complete failure. Chatting to someone you consider knowledgeable on how they think you are doing may highlight a discrepancy between your own performance perceptions and the reality that others see.
  6. Embrace your non-technical skills as strengths. Many consider coding or designing immensely complex software architectures to be the pinnacle in technical expertise. But the soft skills and other pools of knowledge you still possess are just as important to maintain.
  7. Be kind to yourself and embrace breaks. Setting aside regular time for practical coding with some circumstances such as illness or a newborn may not be accessible to you right now. That’s ok!


Best of luck with tackling the tech impostor!


Thanks for reading! Do reach out and share your own experiences of and tips for tackling tech-focused impostor syndrome. I would love to hear them!

All Together Now

Reflections on Our First Mob Code Review

Two heads are better than one. Indeed that is commonly the term used to justify various paring and collaboration efforts. Including the deceptively contentious topic of pair and mob programming. Diverse thoughts and opinions can come from individuals from diverse backgrounds, with diverse thoughts and experiences, and at different stages in their career and stage of development.

What about three heads? That is indeed the question I was pondering ahead of a recent mob review. I’m certainly known for my slightly odd ideas. This latest hair-brained scheme was a recent attempt of mine to correct some worrying patterns of behaviour being exhibited as part of regular UI code reviews.


Three headed statue

None of us have three heads, so we rely on collaboration with others to obtain the best solution we can


I have since moved onto a new team. Yet the story of our first mob review is one story that I am eager not to have remain untold. Here I regale the tale of using a mob review to educate myself and other developers in review standards and best practices, and how they can be used as a health check for team review behaviours and psychological safety.


Part of the Queue


Like many great tales, this story begins a little further back than the actual event. It starts with a queue. A queue of rather large UI code reviews that appeared suddenly a few days before the end of the sprint. Of course one could immediately comment on sudden work bursts, suggesting how work tasks should gradually tick down with developers raising small regular requests to ensure regular integration. I certainly raised that very point rather quickly. However it was the next step which defines the turning point in our story.


In the interest of evaluating a raised concern that UI peer reviews were not approved as quickly as backend service reviews, I waited. I waited eagerly to see what feedback would be bestowed upon these solutions. I waited avidly for the green tick celebrating an approval and merging. Yet what actually happened was…


Queue of shoppers with trolley

Queues may be a part of pandemic life, but regular queues of large pull requests is a warning sign that small regular reviews are not being raised


Nothing. The backend service requests were reviewed in a perfect swarming formation. Interestingly the UI reviews were left outstanding until I weighed in with either commentary or an approval. If I wasn’t concerned before about the expertise hole I would leave behind upon moving to a new team, I certainly was now. I’m not proud to say, but I was also feeling the effects of review fatigue after spending the majority of three days reviewing gargantuan pull requests. It’s not just Zoom fatigue we need to worry about working remotely!


When two more requests appeared the next working day, I felt it was time to understand this review reluctance plaguing the UI codebase. My working theory was the lack of experienced UI expertise that has been a challenge experienced by not only this team, but the wider group for several years.


A Little Less Talk and a Lot More Action


Team dynamics was also an issue. A culture supporting pair programming still doesn’t really exist. This has been partially manufactured through a combination of distributed teams and a lack of dedicated tooling for collaborative programming. The deliver at all costs ethos pushed by the wider group also doesn’t help. However, it’s also due to the preferences of some engineers to work alone and just get stuff done. Not everyone is geared to the pairing style.


Code with cuddly toy elephant

Like pairing with humans, rubber duck (or cuddly elephant) programming is not for everyone


I knew that leaving this issue to persist would have a detrimental impact on team productivity and code quality. Mainly because I was moving to a new team and could no longer provide dedicated review time as often. However, it is also that I realised that I had become the gatekeeper for changes, which is not healthy! Rather than continue having pair reviews with individuals, it was time to shake things up with a mob review.


Come Together


One morning on our standup the number of open PRs was raised as a blocker. This was my cue to strike. When discussing blockers after updates were finished, I asked how comfortable others were reviewing UI requests. The mixture of silence and mumbled statements of discomfort validated my assumption.


I invited everyone to stay on the Zoom meeting post-standup where we would conduct a mob review. For those unfamiliar with the term, this involves walking through an outstanding request and discussing the feedback in a group. This is far more collaborative than our normal async structure of raising a review request and pinging the team chat to notify others of the request.


After a few staggered drop offs we were left with myself and two others. Perfect, a trio review it is! We simply opened the PR within the portal and started talking. Bitbucket is our tool of choice, but many others are available.


Quiet child with hands over mouth

I found the best thing was to try to limit my contributions to questions to ensure others could speak their mind, which is easier said than done


As the more experienced engineer, it can be easy to overpower the situation and simply give feedback and note it down in the tool. What worked well in this situation for me was to ask some questions about segments to hear what others think. This method worked well as it gave everyone irrespective of experience a chance to share their views comfortably.


Another useful element was to be mindful of giving balanced feedback. As I have covered previously on my piece on UI code review best practices, developers learn from both positive and negative feedback. Actively calling out nice elements of the design and implementation in this review was a great entry into discussing alternative approaches and their trade-offs in a friendly forum.


On the Sunny Side of the Street


There were two key benefits that came out of this session. Firstly, discussion on usage of null and undefined enabled us to agree a convention for our team that could be documented in a set of UI review guidelines to help communicate our standard to new joiners, and encourage consistency across our many modules. Rather than it being mandated by myself, using the collective opinions of all to formulate these conventions establishes a shared ownership model that they can continue after my departure.


The second benefit luckily proved to be the intended myth-busting effect. By engaging in discussion rather than pushing my agenda, I managed to clear up an assumption by a colleague who was new to the team that reviews had to go through me. I was happy to hear that this discussion gave them the confidence to hit the approve button and provide comments in future PRs. All experience levels can contribute meaningful feedback to a review, be it async, pair or mob style.


Teacher at the blackboard

Learning experiences come from peers at all levels, not just the teacher at the front of the class


I’ve had the opportunity in my almost 10 years of experience to learn from not only those further on in their careers, but also those just starting out. While pair programming would be the preferred mechanism for sharing opinions and writing code in a more collaborative style, embarking on shared reviews and discussions is a great alternative where pairing is not possible.


Get Yourself Together


If I have inspired you to give a mob review a try, consider the following best practices which worked for me on this occasion:

  1. Make the review session optional so people can drop to get on with other things if needed.
  2. Consider your tooling carefully. I imagine using collaborative coding tools such as Jetbrains Code With Me or Visual Studio Code Live Share would be great. However, if those are not available a screen share and your existing review tool or IDE will also work well.
  3. Use questions to elicit ideas on what to change rather than imposing your own senior viewpoint. This will better support contribution from colleagues at all levels and facilitate discussion.
  4. Explain the reason for a comment. Explaining why you consider a particular approach to be good or bad helps educate the wider group on your thinking.
  5. Encourage questions. This is a collaborative effort, not a dictation!
  6. Document any agreed guideline conventions that come out of any mob reviews in a shared space. A good example is the Typescript project guidelines which live within the repository.


Thanks for reading! Do reach out and share your own experiences of async and mob reviews, or even pair programming. I would love to hear them!

Mix It Up

Experiences Combining BDD Behavioural Specifications with UI e2e Testing

Sometimes in life, two unexpected elements can combine together to form something better. Quite often we talk about two minds being better than one. But this applies to other things too.


One key example from music is the concept of a mashup. For those unfamiliar, a mashup is where at least two songs are merged together to produce another track. In 2020 one mashup that caused a storm in the UK was the merging of Dua Lipa’s track Hallucinate with the BBC News theme. Ben Howell’s remix actually won the Remix of the Year in the BBC Radio 1 Lockdown Awards.

I’m not a massive Dua Lipa fan, but I do find this track rather catchy. Do listen if you can!

Inspired by Ben’s achievement, myself and colleagues have been playing around with combining Behavioural Specifications with e2e testing to improve our testing footprint. In this piece I discuss the justification for combining these practices, the lessons we have learned along the way, and provide a simple example showcasing these benefits.


My Name Is


Before delving into why these techniques combine to be a match made in heaven, let me explain what each of these concepts are for anyone new to these concepts.


Blank Name Tags

Let’s get to know these terms a little better


Behaviour Driven Development


BDD, or Behaviour Driven Development is a practice where new features are discovered by collaborating with business partners and specified as a set of examples that can drive implementation and testing of said feature. It evolved from the Test Driven Development movement.


I refer purposefully to specifications being used as part of this mashup very purposefully. What we intend to use in conjunction with an e2e testing framework is the examples, most likely specified in a format such as the Gherkin specification used along with the Cucumber framework. If you are following BDD as a practice, these specifications shall be outlined as part of the formulation stage. There are numerous resources available online that explain BDD as a concept, along with the benefits. Do check out two of my favourite sources from Seb Rose:


  1. Seb Rose @ Lean Agile Exchange 2020: Our BDDs are Broken
  2. Smartbear: Understanding the Benefits of Test Automation and BDD


End to End Testing


e2e, or End to End testing, refers to the ability to test the end user workflow by recreating the product experience from the user perspective. You’re basically testing the entire product from beginning to end.


Looking Over Shoulder at Person Using Site

e2e Testing is focused on testing the product from the user perspective


Of course with e2e testing there is an argument to be made as to when it is appropriate to connect to the live running services compared to mocked services. I could spend an entire blog talking about my thoughts on when to connect to live running services compared to mocked. Since we are focusing on the basic setup today, the example covered later in this piece uses a hardcoded dataset.


Put Yourself In My Shoes

The user perspective aspect of e2e testing is exactly why it can merge with BDD practices so well. Behavioural specifications, such as those we shall write in Cucumber using the Gherkin format, are the examples that expose their view of the product.


We live in the age where technology and software are heavily ingrained into our everyday lives. Users of our software are not faceless individuals anymore. If we are not the direct end consumer, we often work within the same organisation with them, as I do, or we are competing with many products to gain attention and revenue.


> You never really understand a person until you consider things from his point > of view… until you climb into his skin and walk around in it. > > Harper Lee, To Kill a Mocking Bird


To build good products, we need to embrace the comments of Atticus Finch and walk in our user’s skin. By collaborating to form examples using BDD, the documented examples can then be used in your tests. This makes the intended workflow understandable for developers and stakeholders alike.




There are several different technologies that can be employed to achieve this mashup. Primarily, you need three frameworks:


  1. BDD Specification Framework
  2. Assertion Library
  3. e2e Testing Framework


This example, available on my personal GitHub, covers usage of Cucumber, Chai and Protractor. The main justification for using Protractor is that it is available with any Angular project created using the Angular CLI. I am very intrigued by Cypress as a potential replacement for Protractor as the expressive language it uses instead of the Page Object pattern looks to be more inline with user workflow than Protractor’s element based syntax. I will happily report my experiences in a future post.


Good Example


There are many resources that explain in detail how to setup Cucumber, Chai and Protractor. This guide by Amadou Sall is particularly helpful. However, at time of writing with the release of Cucumber 7 and the bundling of the cucumber types, you need to explicitly state install of Cucumber 6. Note that this will be required until Protractor provides support, which was not the case at time of writing. The command is as follows:


npm install --save-dev @types/{chai,cucumber} chai cucumber protractor-cucumber-framework


Focusing on the tests themselves, there are three file types for a given test that we require:

  1. The feature file containing our examples, or the behavioural specification. This is identifiable from the .feature extension.

  2. The test steps, postfixed by .steps, which lists the implementation of a given scenario step.

  3. Since we are using Protractor, we are adopting the Page Object pattern. This means we have an additional file, containing .po within the filename. It is here that we place our logic for accessing elements on the page.


Based on my experience of writing these tests in enterprise software, I’ve found it useful to use the folder structure depicted below. I advise adopting the below folder structure separating feature, test steps and page object files to stop your e2e folder from ballooning out of control. Adopting a component-based folder strategy similar to the Angular implementation is a valid option. Nevertheless, since we are testing the user perspective of the application, we will most likely have any given scenario touching multiple components, meaning this structure is less clear by comparison.

I’ve found structuring the folders in a file type rather than component structure scales better for larger applications

American English


Using Cucumber exposes the Gherkin syntax. The power of this syntax is that it allows you to express the user workflow in english-like language that users will understand. Often you should be able to collaborate with stakeholders using the BDD process to formulate their perspective as a series of examples.

The feature file allows you to use the examples elicited
via user collaboration as the scenarios to test against

As you can see from this example each scenario will specify a particular scenario outlining how the user expects the system to behave. Within each scenario:


  1. We can set the initial state using the Given line.
  2. The When segment outlines the precise action that you are expecting the user to perform.
  3. Our Then statements show the expected behaviour. Here you can see I have two checking on not just the title, but the list of artists I expect to see as a data table. These data tables are particularly useful for data-driven products such as financial systems.


Step by Step


The implementation of these steps is carried out in the steps file, depicted below. You will see for each Gherkin keyword, we specify the expression matching the precise step in the aforementioned feature file. We also specify a callback function dictating the steps to execute for that precise step.

The steps file are the main glue outlining the system
actions corresponding to each scenario step

Focusing on the Then statement, you will see we are using parameters to promote reuse of these steps for potentially multiple scenarios. In addition to simple textual parameters, data tables such as the artists table shown in our example can support specification of complex data types and collections. Data tables are particularly useful for data heavy applications such as those I see working in financial services.


Being a web application, we often encounter asynchronous situations in obtaining the page results. It’s important to ensure you use async and await correctly to handle the time taken to capture the elements or perform service calls. Often when starting you may be tempted to start including timeout waits, but these should be used sparingly. In this trivial example it is not required, but I have often seen them be gradually increased over time when pinging backend services directly.


You Find Me


Looking at the steps you may see we are performing particular operations to get elements on the page. With Protractor we use the Page Object pattern to seek out elements to inspect within the tests. It has the advantage of decoupling your test steps from the page layout. Be mindful that other frameworks such as Cypress do not advocate that pattern.


All of the examples here search by CSS paths, including the $$ and $ Protractor shorthands. Other selectors, including by id, name, ng-model and binding are provided.

The po file is a Protractor specific construct as it uses the
Page Object pattern to separate DOM-based logic from the testing framework

All of the examples here search by CSS paths, including the $$ and $ Protractor shorthands. Other selectors, including by id, name, ng-model and binding are provided.




As we have reached the end of this track, I hope you have seen how combining BDD specifications and e2e testing helps provide expressive and understandable testing. By using examples produced in conjunction with key stakeholders, we can develop features in collaboration with users to showcase the expected product workflow.


Sheet Music

Let music inspire your technical choices


Feel free to check out the code on my personal GitHub at the listed link if you’re interested in digging more into the code. I hope this also encourages you to think about how other technologies and techniques you either use or research can be combined to make a more effective combination. Be inspired by music and mashup your technologies today!


Thanks for reading!

The End Where I Begin

Identifying Sprint Review Anti-patterns

We’re coming to the end of the year, which means a lot of us are attending various town halls and high profile meetings showcasing achievements of the year. Particularly for me working in a large organisation, I’m attending a few of them. It’s nice to reflect back on recent accomplishments. Less so to focus on any failures.


December Calendar

It’s rather appropriate that recent issues with sprint reviews occurred towards the end of the year


A more regular Scrum ceremony focused on showcasing sprint achievements and contributions is the friendly sprint review. Recently we have faced considerable challenges with this ceremony which are slightly different to those I have reflected on before. Here I discuss some of the recent review anti-patterns I have encountered, and explain how to address these early warning signs.


A Horse With No Name


For those unfamiliar with this term, let’s review the Sprint Review definition as per the new shiny 2020 Scrum Guide:


The purpose of the Sprint Review is to inspect the outcome of the Sprint and determine future adaptations. The Scrum Team presents the results of their work to key stakeholders and progress toward the Product Goal is discussed.

The Scrum Guide 2020


Make Your Move


Moving the Review out by a few days or hours is a symptom that often originates from good intentions. It is normally an attempt at kindness to accommodate others. Yet it is akin to that age old analogy of moving the goalposts half-way through the game.


There are numerous examples of these innocent rescheduling attempts that I’ve encountered over the years:


  1. Issues with non-prod environment unavailability.
  2. Key stakeholder or team member out on vacation.
  3. It’s almost finished. I just need X more days to complete the item.


On point one specifically, there is definitely a concern there about incomplete features being showcased. However, in larger organisations with poor support for fast pipelines to production, this can be an allowance teams make in their Definition of Done. However, with the others it’s probably best to proceed at the original slot rather than break the cadence. Movement can interfere with scheduling for all stakeholders and have them question whether it is proceeding or not.


Don’t Stop Me Now


An issue related to the aforementioned movement of a review is cancelling the session altogether. It is a common anti-pattern I observe when a sprint doesn’t quite go to plan. I’ll hold my hands up and admit that I have also been guilty of this previously as an engineer. However, on reflection I see it was the wrong thing to do. Each time it was moved I was projecting a false illusion that we were perfect achievers. In reality we were not.


This situation can be identified by these common phrases:


  1. We don’t have anything to show.
  2. We are not ready to show feature X to users yet.
  3. It’s not done yet.
  4. The team is not prepared.
  5. Users are not interested in the hygiene work delivered this sprint.
  6. There’s not enough features delivered to warrant updating stakeholders.


By cancelling the sprint review, irrespective of success or failure, you remove the ability to inspect the outcome of the Sprint and determine future adaptations. Cancelling a review even once, removes accountability from the squad. Let’s face it, if you cancel the session once, there’s nothing stopping you repeating that pattern the next time you’re not comfortable facing stakeholders.


Cancel Culture

Cancellation culture is difficult to break


Can we honestly say we’re working in a partnership to achieve a common Product Goal if we are not comfortable showcasing failures and challenges as well as successes? I would suggest not.


It’s (Not) A Demo


Remember back to school maths and set theory? Did you ever think it would connect to Agility? Well you are in luck! It’s time to commit the following equations to memory:


  1. Sprint Review ≠ Demo
  2. Sprint Review ∋ Demo


To reiterate, a sprint review is not a demo. Yes, a sprint review can contain a demo. However, many of us are incorrectly using the terms as equivalent structures.


I can’t take credit for this insight. Many amazing people have pointed this out, including the insightful Ryan Ripley & Todd Miller in Fixing Your Scrum. But this piece wouldn’t be complete without commenting on recent experiences that many consider a review to be only a demo. Attending a recent guild meeting I was very aware that many of us were using the term demo throughout, even after learning they are not the same. It’s been hardwired into our brain.


Now is the time to break the habit. Part of the problem may be that the Scrum Guide doesn’t prescribe a clear agenda. However, as we can see from the following quote, it does impart some advice on what the intent should be:


During the event, the Scrum Team and stakeholders review what was accomplished in the Sprint and what has changed in their environment. Based on this information, attendees collaborate on what to do next. The Product Backlog may also be adjusted to meet new opportunities. The Sprint Review is a working session and the Scrum Team should avoid limiting it to a presentation.

The Scrum Guide 2020


From the above, a sample structure that I’ve been working to recently comprises of the following steps:


  1. Welcome everyone! You’d be surprised how many times meetings don’t include a simple hello.
  2. Reiterate the product goals.
  3. Highlight process towards any goals, and results of any Key Performance Metrics (KPIs), or metrics to show your progress towards product goals.
  4. Highlight key achievements or issues achieved during the sprint. Yes, we want to showcase success and failure.
  5. Demo these achievements. Ideally this should be working software. However, any artefacts you can show to demonstrate progress towards the sprint and product goals can be showcased. Eligible artefacts include, but are not limited to, analysis results, mock-ups, wireframes and architecture diagrams are eligible.
  6. Obtain feedback on these items.
  7. Review next steps for the team, highlighting any risks or concerns you see. This is the perfect time to highlight any help or support you may need from stakeholders.
  8. Add anything else the team feels is appropriate to cover in the review.
  9. Close out and thank everyone for their time, as well as the team for their contributions.


There are many other resources available on conducting effective sprint reviews. A simple online search will give many useful posts. Do also check out the aforementioned book Fixing Your Scrum as well.


Be Prepared


Recently I have seen that lack of preparation is a key problem that impacts a sprint review. It can be easy to stick our heads in the sand and focus on the work and not consider how to demonstrate progress. Especially if the squad has exhibited the aforementioned moving or cancelling of sprint reviews. That can set the expectation that it might not happen. Therefore why would I prepare for it? Which in turn can lead to moving or cancelling as the team are not ready to showcase work and be accountable to stakeholders.


Meal Preparation

Much like a good meal, a good sprint review requires preparation


When I think back over my Agile journey to date, I know I have been guilty of inadequate preparation. Back when I dipped my toes into the fast-paced world of front-end Web development, I was often the individual conducting the demo. It was very easy to have a local version running on my machine and quickly click through how the new shiny feature worked on the screen. Yes I intentionally use the word demo here as at the time that’s what we were doing rather than a review. Even your friendly neighbourhood agile advocate has been guilty of past Scrum indiscretions!


The reality is that my prior style presents some challenges. Simply showing the feature working doesn’t highlight what problem has been solved with this new addition. It limits the feedback model to a simple question and answer format, rather than encouraging meaningful conversation on the item. Finally, it doesn’t make clear how this feature fits with the Product Goals.


I’m not suggesting you need to practice for weeks on end over and over again to refine your review. I save that level of diligence to my talks! Nevertheless, I have found taking time to determine what I want to say helps me focus on the true journey. Preparation should apply to the entire review. The recent addition of a quick team sprint review prep call is yet to be evaluated for its preparation benefit. However I remain optimistic that those 15 minutes shall help the team be more prepared for their next review.


Lead Me On


Many of the anti-patterns discussed here can be symptoms of a lack of education within teams. They can also be a symptom of management interference. Traditional technology-business relationships are generally classed as a service function. Showing any weakness or failure in such situations is a big faux-pas.


Team Rowing Together

Management figures can veer the team off course if they attempt to influence the direction of a sprint review


Management have grown up within cultures where these relationships are common place. As idealistic as it may sound to some, my perspective is that these relationships should be fostered as more of a partnership. This can be very challenging indeed if you are having to change from a servant mindset.


Leadership within both IT and business functions may think it is right to influence or alter the timing or content of a review to increase attendance or convey a particular success. By doing this they may break team autonomy in certain situations by influencing the timing or content of a review. It’s important for them to support the team by attending the review, rather than undermine the squad’s ability to conduct a regular review.


Final Warning


There are many more pitfalls to watch out for when it comes to sprint reviews. It’s definitely worth investing time in learning about these other anti-patterns and seek ways to avoid them if you can. I would strongly recommend checking out Fixing Your Scrum by Ryan Ripley & Todd Miller, focusing on the dedicated Sprint Review chapter. It’s definitely been a great resource for me over the last year for me in so many ways.


Warning Sign

Look out for these warning signs


Press ahead with any of these symptoms at your peril. The five faux-pas discussed today point to a massive problem with accountability and partnership plaguing not only the team, but management and stakeholder circles. Outside coaching and influence is imperative to fix such anti-patterns and guide all levels on the course to frequent and successful sprint reviews.


Thanks for reading!

Poker Face

Gamification of Scrum Learning Using Scrum Delegation Poker

Scrum Masters and Agile Coaches play a key part in the development and supporting of Agile practice within Scrum teams. Both hold key responsibilities to support and educate teams in the ways of the Scrum force. However, sometimes more than talking needs to be done to help squads. Occasionally, bad habits creep into practice that need to be addressed. At times, teams need stronger support to learn Scrum principles and ceremonies.

No matter how many times you try, it is my experience that you cannot force them to read The Scrum Guide. Not everyone can be an uber Agile enthusiast such as myself. For those who simply want to use Agile techniques to focus on their primary love of coding and building cool things. Irrespective of the number of pages, or the incentives you put forward to encourage them, they will only read it when they want to. If ever.

Although the Scrum Guide is not volumes long, I regularly struggle to encourage individuals to read and learn to help them improve their Agile practice

When it comes to learning the important lessons, there’s no reason we can’t have some fun. Recently I have been having fun, yes fun, transforming Management 3.0 Delegation Poker to help teach our squads Agile best practice. Here, I provide insights into how this game can be used to educate teams, and the successes and lessons learned from our first pilot poker game.

Playing Cards

Applying an adaptation of Delegation Poker to this Scrum delegation seemed like a good opportunity to clarify some elements of Agile practice and encourage collective learning of Scrum best practices. In advance, you’ll need a set of delegation cards for each player. The set includes the key Scrum roles, as defined in The Scrum Guide, along with a few other common IT roles. Feel free to print off the below template, or add additional roles to ensure all members of the Scrum superhero squad that is playing are represented!

My Superhero Scrum Squad Delegation Poker Cards can help you clear up common misconceptions and clarify team roles

In preparation for the session, the dealer running the session should select a series of scenarios to present to the team. Six to eight is a reasonable number to cover without making the session too long.

These can be selected from The Scrum Guide. In my case I used this resource for part of my inspiration. There were particular red flags present in this Scrum team that I also hand picked events to include in the game. For example, following a comment from one team member that they felt they had to commit to all items shortlisted by the Product Owner, it seemed appropriate to ask which group is responsible for committing but not shortlisting work.

Select the scenarios you would like to cover, similar to squares on the Monopoly board

To ensure the team also reflected on prior experiences I also added situations the team have encountered where perhaps they had struggled with key principles such as autonomy or collective ownership. Given each team member commonly selects a story to work on individually rather than together, questioning the responsibility for unfinished elements seemed appropriate. Especially since it is the responsibility of everyone in the team to complete the work. Presenting situations where they can present one or multiple cards forces the players to consider if all parties are key to addressing a particular set of circumstances.

The Dealer

You will need approximately one hour to play. The rules of the game are simple. For each identified scenario:

  1. Present the team with a given scenario.
  2. They are able to ask questions to clarify the situation.
  3. Place down one or more cards to represent the individuals who are responsible for addressing the event in question. Encourage participants to place them face down until everyone has voted.
  4. All players should reveal their hand at the same time.
  5. Spend a few moments asking players to explain the reasons for their selection. Encourage all viewpoints to be discussed.
  6. Reveal the true answer, clarifying the reasoning for those individuals being responsible to remediate the issues within this situation.

Not so difficult to follow, right?

That Was a Crazy Game of Poker

We held our first Delegation Poker session in July 2020. Overall, I was very happy with the level of engagement. As a facilitator of any session, having a number of attendees contact you post-event commenting on how helpful and well-run the meeting was always leaves a warm, fuzzy feeling.

The above format can always be included as part of a larger session. I included a role identification step where each participant voted on who held each of the key rules using video conferencing annotation tools. The initial goal of this stage was to highlight the confusion of who held the Scrum Master role. It meant that when they were later voting on scenarios, they were able to learn the key responsibilities of this role, and later discuss who of the shortlist should be carrying out the role. After all, there should only be one Scrum Master!

We found it easy to encourage the players to show their hand for each scenario

There were several situations that highlighted the team have a good understanding of some other roles. The Product Owner and his need to shortlist work items was very clear. The team had a good understanding of some collective responsibilities. And most players gave thoughtful justifications for their answers. We also managed to clear up some misconceptions on the team committing to shortlisted work, which facilitated some interesting questions.

Playing the game with a remote team is slightly more challenging, as we found out in this case. Being able to play the cards would definitely have been more fun. Bandwidth issues meant players used annotation tools to place a mark next to their card(s) of choice. If you have all participants in areas of reliable broadband, I would strongly advise playing poker by holding up your cards to the camera.

The Winner Takes It All

The success of this session gives me hope that the game can be used again in other situations. We have a couple of other squads that currently hold onto certain misconceptions, or need similar support. It is clear that with a similar, or slightly modified set of scenarios, the game can be reused to help them recognise pitfalls in their own practice that require remediation.

This isn’t the only Scrum game out there. After running this session I happened to come across The Scrum Card Game. I am definitely tempted to try this game out too. Although some colleagues may require convincing on the benefit, especially if they consider themselves to be an established team.

Gamification is a powerful learning tool

Gamification of learning Agile theory may seem to some to be rather juvenile. They call it work for a reason after all. Nevertheless, learning and work should be enjoyable. If they are not, question how you can make it so. Be sure to play your hand at Scrum Delegation Poker, and learn how the key roles can help you adapt to past and future software development challenges.

Thanks so much for reading! Claps and comments are always appreciated. Do get in touch to let me know your experiences of playing Scrum Delegation Poker!

Eight Days a Week

Reflections on the Pitfalls of Story Points and Velocity Capture

Many don’t know this, but I studied mathematics for two years at university before specialising in Computer Science. One mandatory class specialized in teaching the fundamentals of mathematical proof. In a nutshell, we learned how to establish that a given hypothesis was correct, or identify the contradiction that disproves the theory. It was immensely satisfying when you reached the end of a proof. Furthermore, verifying that you had the correct answer was pretty straightforward.

If only all hypotheses were so easy to disprove. Lately there has been an unfolding obsession with story points across the squads. Managers, business stakeholders and even the PO are starting to raise questions on why this item is X points. Worrying it has become the hot topic within our circle.

Why should we need to prove the correctness of our story point estimates?

A couple of teams have raised concerns that the metric reported in a centralised dashboard is incorrect. That their true sprint velocity is actually higher. They feel pressure to justify to that same stakeholder group that they are delivering value. However, unlike in my university proof class, this result has been reached through gut feel rather than mathematical proof.

Subsequent conversations have me thinking this is more about proving velocity correctness. Do the numbers really add up? Or are there bigger lessons to learn? While trust in the metrics is indeed one problem, it is not the full picture. There are several estimation pitfalls contributing to this situation. Here we discuss story points pitfalls and how they can erode customer confidence.

Original Sin

While evaluating our stance on story points, it’s important to reflect on their origins. According to the legendary Ron Jeffries, story points originate from the initial XP evolution. Fascinatingly they were meant to represent ideal days. Essentially, a story point is a productive developer day.

Is there such a thing as a super productive ideal developer day anymore?

Let’s take note of the terms ideal and productive in that statement. A common planning pitfall that is contributing to our current issue is implicitly mapping points to days. Humans are absolutely awful at judging time an item will take. Coupled with the symptomatic optimism of programmers, it’s easy to see that we are setting unrealistic estimates.

There is a case to be made to potentially join the #NoEstimates movement. Although this is a wider journey to commit to that requires extensive engagement with stakeholders and the wider department. Given the state of play, a smaller series of steps to be applied to provide shorter term improvements.

Relative estimating using either points or t-shirt sizing could be more helpful here.

Some tips outlined within Software Estimation Without Guessing by George Dimwiddie can help. A small step in the right direction would be to move to relative estimates, either as points or t-shirt sizing. Both approaches require estimates to be made relative to previously undertaken work. A second item would be to revisit items to provide further estimation practice for the team, and to provide further data into the relative scale the team is using.

Crystal Clear

While estimation is a clear problem, it is important to identify the root cause of the lack of confidence in the published metrics. Lack of transparency in how metrics are calculated on the shared portal is definitely a key one. While there is a publicly queryable API, the underlying calculation remains closed. This makes it easy for people to point the finger at the numbers, and claim they are wrong.

Since these numbers are under the spotlight by management and clients alike, it’s natural for development teams to try to either game the system, or defend their record. This is a classic case of weaponisation. In this case, blame has immediately fallen on the Jira workflow feeding the dashboard. No one has done the maths. No one has investigated how the dashboard number is calculated, just what we expect it to be.

The age old saying of a bad workman blames his tools can apply to software development too. It’s a natural defence.

We always jump to blaming the tools, and justifying that it doesn’t cover a particular portion of our lifecycle. Here, the justification to change the workflow was that the UAT carryover phase is responsible for a large portion of incomplete stories at the end of the sprint.

The reality is that there is more to this story than incorrect metrics. Looking at a cumulative flow chart shows that a long time spent in stages other than UAT, such as TO DO. This is partially down to unplanned work. Pulling in unexpected items to the sprint puts the team under pressure to deliver the committed items in a shorter time frame. Inadequate developer testing means defects identified in UAT pull features back to development. Key acceptance criteria is missed. Tight deadlines push the team to burnout, represented in a high rate of sickness and sprint rollover.

Retrospectives are a vital tool in identifying the source of issues and a remediation action plan. Use any metric trends as a communication starter, not a justification of your work.

Calm Like a Bomb

Weaponisation of velocity metrics by management and client groups is a major concern. While I understand the desire to compare the effectiveness of squads at a higher level, story points are not the way. Story point estimates are personal and unique to a team. They depend on numerous factors, not limited to:

  • Team experience
  • Degree of squad autonomy
  • Average story complexity
  • Level of Product Owner engagement
  • Development team collaboration and cohesiveness maturity levels
  • Degree of process and testing automation

If story points cannot give a comparable value, some may seek to find another metric. Story count could be considered a viable alternative. However, it unfairly discriminates against small teams or those squads that encounter work gaps for events such as vacation or long term leave. Furthermore, it can be gamed by writing minutely small stories that may not reflect a true customer value.

Comparing stories across teams can encourage bad gamesmanship as teams try to beat the system.

Assuming a single set of metrics fits all approaches for all squads is a monumental mistake. A pitfall in large scale Agile transformations is that a single paradigm is enforced from the top. It shouldn’t matter whether squads adopt Scrum, Kanban, Scrumban or any other paradigm. That choice should be made by the team depending on their collective circumstances. Allowing them to prescribe their own practice empowers teams to be in control of their own tracked metrics and the hypothesised affect their deliverables are expected to have.

If you start to get questions about your point commitments in a sprint, escalate immediately. Even some of the alternatives such as number of completed stories per sprint cannot provide a fair comparison of team effectiveness. What is more important is tracking of sprint and product goals using the corresponding Key Performance Indicators, or KPIs. If those goals are not defined and quantified well, it is impossible to show the Product Owner or any other stakeholders that valuable increments are being delivered.

Prove It

Any fascination with story points or sprint velocity by key stakeholders should be considered unhealthy. From many of my experiences over the years, a significant cause is often management pressure. Someone is looking at that trend of points and asking why it is lower than last time.

Scrutinising a single metric will not demonstrate team effectiveness or productivity. Number of points committed or completed isn’t important. Neither is whether you finish every single story committed to in the sprint. Neither is how many stories a given team completed in a sprint.

Success is a straight road for all development teams.

What is the true measure of success? Why it’s client value of course! KPIs are one way to measure this. If these are tied to the product vision, an increase or decrease in these values can provide an empirical method of measuring team effectiveness. Over time they allow us to prove the hypothesis to one simple question. Are we going in the right direction?

Thanks for reading!