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!

Why Won’t We Change?

Exploring Reluctance in Automation of Manual Development Practices

When building software for clients, a key driver is providing value and improvement to current manual user procedures. We should always look at ourselves in the same light. Without eliminating the manual processes in our own software engineering practice, how can we advocate the same lean focused benefits when automating client processes?

In the digital age, all teams must embrace automation to eliminate waste

Maintaining manual elements of the software development cycle in fully remote situations such as the ongoing COVID-19 lockdown is rather difficult. Rather than trying to communicate more via informal channels to keep things going, teams resort to communicating less to “just get things done”.

Automated release and deployment mechanisms that could help reduce the amount of manual intervention are being ignored. Each dismissal often comes with mutters of “oh, I’ll do it next time”. Yet next time the recursive rejection cycle continues.

Trying to encourage process automation among reluctant colleagues can be frustrating

It is easy for the agent of change to become frustrated at the reluctance to change being exhibited by others. I imagine many of you are now reflecting on a time where you have faced hesitation for changes you are passionately advocating. With my most recent experiences in mind, I reflect on the reasons for automation hesitation.

The Certainty of Chance

Firstly, consider for how long these activities have been conducted in this way. How long have manual release procedures existed in your organisation in their current guise? 1 year? 2 years? Perhaps more than 5 years? Manual processes tend to hang around for a long time like a bad smell. New elements are bolted on over time. It’s rare steps are removed.

The longer things remain the way they are, the more difficult it becomes to change minds. Especially in times of strife. Even the most burdensome elements can be transformed over time into elements of comforting certainty.

Even the most frustrating manual procedures can become the comfort blanket of most established engineers

Don’t confuse this comfort as acceptance in how things are done. Strangely enough, complaints on the degree of manual effort required have persisted for some time. Developers do raise concerns about the amount of time it takes to perform manual elements of our process such as release management, migration to testing environments and undertaking of manual testing. Nevertheless, when opportunities are presented to address these gripes we chicken out.

Tracking repeated rumbles is imperative to identify your complacent counterparts. Those are the individuals that will require support to adopt anything different. Just like all change and influencing forums tell us, it’s important to sell the change to them, including the cultural support, to encourage them to try using this new mechanism.

Feel the Pressure

Another cause of reluctance to automate our own processes is the degree of delivery pressure applied to teams. As process automation requires upfront effort, there can be a misconception that the automation takes longer than “just doing it”. Even with the best intentions and willing colleagues, they will take the easy way out and justify waiting until next time to take action.

If clients are continually yelling for new features to be delivered yesterday, the last thing developers want to focus on is automating procedures in their own back garden. There is a perception that, at least this time, it will take longer. If the team doesn’t see a potential future time saving, they won’t automate. Also, if they are pressed to get something out now, they will default to the old ways and still won’t automate.

Teams under pressure will be reluctant to commit to more work to automate their processes

We’ve all been guilty of thinking “it’ll take X to automate, I don’t think it’s worth it”. It’s not that they don’t want to be good scouts and leave the campground in a better state than it was found. It’s that they observe that users and Product Owners don’t appreciate the value or benefit. That the PO dictates all work that they complete.

I implore anyone who perceives that their Product Owner controls their sprint backlog to re-read the Scrum Guide very carefully. In particular, focus on the below two quotes:

The Development Team consists of professionals who do the work of delivering a potentially releasable Increment of “Done” product at the end of each Sprint.

The Sprint Backlog is a forecast by the Development Team.

— The Scrum Guide, Jeff Sutherland and Ken Schwaber

To foster innovation and improvement, development teams need to feel empowered to control the sprint backlog and accept the work they undertake. It should be a conversation with the Product Owner to explain the value of process automation, along with the benefits they will see. Leaders need to protect teams from client pressure and ensure there is sufficient breathing space for teams to learn, grow and automate for their own collective benefit.

Learn to Fly

Think back a few years ago when you were just starting out at a portion of your educational or professional journey. Did you know absolutely everything you needed to complete work assignments? Of course not!

With the wealth of knowledge that exists in the world, only a fool would expect to know everything they need to do their job

Fast forward to today and contemplate your current position. Do you always know the answer to everything? Is there never a situation where you need to search for an answer using your friendly neighbourhood search engine? I don’t believe I’m being presumptuous in assuming the answer is no for you as much as it is for me.

We may not be in education anymore, but we should be constantly learning. Lack of learning mindset is detrimental to any team. With technology frameworks, programming languages and paradigms continuously evolving, being a software engineer is a lifelong commitment to learning new and better practices. That includes learning how to automate your current processes. Especially those where established team members have a high degree of muscle memory.


Of course a collaborative and continuous improvement culture across organisation should make change easier to apply. However, team cultural pockets also impact the willingness of squads to embrace change. Closed minds at both the individual and management levels can promote change resistance, even in the midst of top down transformations.

Automation of manual processes makes us stronger, not weaker

The reality is that unless all colleagues share the continuous improvement mindset and the desire to automate wasteful stages in their software development cycle, they will continue to follow the same repetitive manual procedures. Although we are privileged to have individuals willing to embrace change, that enthusiasm is not present across the entire collective.

I implore all teams in varying stages of DevOps adoption to consider any manual step in your process as waste to be eliminated. Don’t wait for that dreamy post-lockdown utopia to improve your own ecosystem. The benefits will still be there whatever that new normal is, and you will be a stronger team for undertaking the journey. So act now!

Thanks for reading!

Baby It’s You

Diagnosing and Addressing Remote Working Connectivity Issues

It’s week two of UK lockdown, and many of us are trying to adjust to stringent restrictions coupled with working remotely with pets and children. We’re silently celebrating the first week of being home with the kids. Successfully writing emails and code with a baby bouncing on knee is still a work in progress for me. Practice will hopefully make perfect. In the meantime, any tips others can provide are definitely appreciated!


One achievement I am proud of is that I finally have an isolated work setup and generally good remote connectivity. Having persistent connection freezing, pixellated video calls and disconnecting sessions leaves you feeling powerless and useless. With all the negativity and worry ebbing through the world, the last thing we should be worried about is performing at work.


Isolated Man

Remote connectivity issues can be leave you feeling very alone and frustrated


I am thankful that this means I can now focus on supporting colleagues and trying to build software from home. Yet, the journey to isolate the source of my issues has been far longer than I would like to admit. There is a struggle to figure out if it’s down to my own home environment, work capacity, or some weird combination.


To help support the wider community, here I list the key external items I investigated in improving my own work connectivity. Hopefully it helps others find remote workspace nirvana and further promote the work environment empathy I have previously advocated.


The Original Wrapper


There are many different remote working configurations adopted by organisations. From dedicated laptops, to remote connections via a personal machine, there are several options provided to the workforce. If you rarely work from home, it is easy for versions of remote tooling to become obsolete. There are definitely security and other implications of not keeping this software up to date. Yet the last thing we think about when browsing our personal laptops at home is updating work related software.


Old Bible

Newer rather than older software versions can help improve performance


As we are facing a considerable period of working from home, now is the time to update the relevant software. Connectivity software is one. Be mindful of other tools such as video conferencing, media extensions and other collaboration software. All should be updated to the latest and greatest.


Speed of Sound


This next item may seem obvious. Yet it has several nuances that are worth investigating. It is definitely worth checking your broadband connection. This may be a challenging item depending on the number of people remote working from your home. Those in flatshares may be vying for bandwidth on a low speed connection. Irrespective, it’s worth investigating broadband if you’re struggling to connect.


The first aspect of your connection worth investigating is the overall speed. Many ISPs have an online checker that you can use. Regardless, using an impartial tool suitable for your region such as UK Broadband Speed Test is a good method of testing your speed.



It may not need to be top speed, but is your broadband speed and settings supporting your remote working


A secondary yet less obvious item that I didn’t initially consider is evaluating your broadband router settings. Particularly the frequency settings. The last thing we tend to focus on at home is whether our router is using 2.4 GHz or 5GHz for our devices. As long as your favourite streaming service is working while you’re on the couch glued to social media on your phone, you probably don’t care very much. Yet if you are still struggling with connectivity, it may be worth investigating the best potential frequency for your connecting device.


Somewhere Over The Rainbow


Much has been said in numerous articles on the importance of a dedicated workspace. Many posts I have read in recent weeks strongly encourage us to find an isolated space. There are many advantages to a dedicated area for working. These include establishing a physical separation between work and home and encouraging focus on work. Finding such as space is easier said than done


Your chosen working location can also be impacting your connection. Wireless signal strength can be impacted by the proximity of your space to the router, wall thickness or other aspects of your home. For me, working from kitchen table was difficult for reasons other than the usual distractions. I definitely did encounter the standard challenges such as battling the siren call of the fridge, the lure of another cup of tea, and the tempting giggles of my son on the changing mat. Nevertheless, I also found my connection was dropping off when WFKT, or work from kitchen table. Thanks for the tip Lucian Stan!


Dressing Table

Many spaces can be adapted to be a dedicated workspace, including dressing tables


Adding a desk to the spare bedroom has been a salvation in connectivity improvement. While it was the best choice for me, it is possible to find an inventive solution by reusing some furniture. Both a colleague and my sister-in-law advocate the surprising effectiveness of work from dressing table, or WFDT for short. With space for a second monitor and your legs, it proves to be an ingenious solution. I definitely approve of the creativity used here!


Shiny Toys


With the amount of negative information; concerns for friends and family; worries about food, toilet paper, social isolation; and the various other worries buzzing around our heads, the last thing you’re probably thinking about is the newest gadget. Yet an ageing personal laptop could be causing your connectivity issues. The various reasons for why this could be the case are outside the scope of this article.



Equipment, as well as location, can have an impact on your connection


For me this was literally the last resort. If you only use your home machine for the occasional browsing, upgrading to the latest laptop may seem like a frivolous expense. If you already have your eyes on a shiny new toy, and have the means to cover that expense now, it may be worth bring that purchase forward.


Join Together


Slow connection issues can be exceptionally frustrating to rectify. Sympathy can be difficult to find. Particularly where things just work for others and not for  you. Quite often it is difficult to know where to start. By ruling out your home configuration, it is easy to identify when it’s not you.


I’m sure there are many other diagnostics you can perform to rectify your own personal remote connectivity problems. Hopefully some of the steps I’ve had to execute will boost your connection and allow you to work at a productivity level closer to your native office. If you find any more, do share and help the community remote work together.


Thanks for reading!

Long Distance Call

Where is Our WFH Workspace Empathy?

Let’s be honest, we are already getting tired of hearing about COVID-19. It dominates our media headlines. It is leading to the cancellation of many events and conferences. Company policies are invading our mailboxes. The resulting panic is emptying our supermarket shelves. As much as we want to ignore it, this disease is having a significant impact on our lives as it moves throughout the world.

This week it has escalated in Europe to the point where many are beginning to work from home for significant periods of time. Suddenly, vast numbers of people used to the daily commute are stuck in the confines of their homes. Many will not have a comparable home setup to support a productive working day. Myself and colleagues are facing ongoing challenges in adjusting to self isolation. For those with no home setup such as myself, we are scrambling to invest in home workspaces to continue to be meet deadlines. Yet when challenges arise, many struggle to remediate the resulting issues.

Many of us are struggling to work from home due to insufficient workspace

I have previously discussed workspace effects on developer productivity and the practice of pair programming, as well as the impact on non-permanent stakeholders. In these tough times of self-isolation remote workspace support should be a paramount concern. Here I discuss some of the challenges of poor remote workspace support, and how a consistent lack of tooling focus impacts our capacity to work in times of hardship. Furthermore, I will emphasise the importance of workspace empathy, and how true leaders can support their teams.

The Only One

If we consider the usual WFH setup, casual remote workers have a far less sophisticated setup than they utilise in the office. Numerous tweets coupled with my own experiences over the years point to the lonely laptop and mobile phone. The vast multi-screen office setup with high specification PC and fixed phone definitely pales in comparison. While in my university days working with a single screen was comfortable, the reality is it is far easier to scale up monitor use than it is to scale down. Nowadays, context switching on a single monitor for me is immensely infuriating. I’ve been spoiled by having multiple screens.

Many of us have been spoiled with PCs connected to multiple monitors

Some organisations are providing additional monitors and headsets to help support their people in adjusting to regular remote working. This support must continue to ensure colleagues are able to carry out their daily responsibilities. We must ask ourselves if this is the only mechanism to help our workforce remain productive.

Your New Twin Size Bed

The expectation that all team members have a dedicated workspace at home needs to be rapidly corrected. Lacking a space to work at home has a massively detrimental impact on productivity.

There are many life factors that result in people having a lack of dedicated space to work outside the office. Perhaps their proximity to the office means it’s not worth the effort. Perhaps living in a single room in a flat share means they are short of space or struggle to share a poor common WiFi connection. Perhaps you have noisy neighbours or temporarily high noise levels at home due to construction work being undertaken by yourself or neighbours. Perhaps the cost implication in comparison to other needs and desires is rather low. It may even be as simple as a preference to work in the office as it is a space your mind associates with work tasks.

Not all of us have a dedicated space to work at home. My space is currently the kitchen table next to my son’s changing mat and nappies!

This phenomenon does not just affect developers. Yet it is the junior developer population who are more likely to be impacted. I am in a different situation still where I had to dismantle my office to provide a bedroom for my infant son. My circumstance primarily arise from different reasons than those cited above.

Nevertheless, we now face the mutual challenge of scrambling to provide ourselves with the necessary space to work effectively. Often with little support. Providing headsets and monitors as described previously is a fantastic step forward. Yet support for helping individuals with a dedicated setup often falls short. That’s were help with items such as furniture should be considered.

Video Phone

Connectivity software and collaboration tooling is imperative in our quest for remote working productivity. Yet historical investment in such software is often an afterthought.

Despite working from home being actively encouraged this week, I actively sought refuge in the office. Partly for workspace reasons discussed throughout. But also due to the state performance of collaboration tooling used by many organisations. Certain messaging and screen sharing products have been the bane of my office setup for some time. One particular piece of software freezes and crashes several times a day due to poor scaling support. You have to complete numerous steps to enable video as it’s disabled by default. The strain of a remote connection exacerbates these problems.

High quality collaboration tools such as peer to peer video and screen sharing should be a focus in times of normality rather than an afterthought for times of panic

Although these issues impact the entire workforce, we keep calm and carry on with this particular tool. It is only now that we are required to remote work for a considerable period of time that the surge of requests for a comparable tools are appearing. The video calling issues can no longer be remediated by meeting people directly in other floors or buildings.

There is an element of personal preference at play here. It is my opinion that these tools should be made available to all in times of normality. This should be done in anticipation that these products will help to eliminate the shock of remote working isolation in times of strife.

Bad Connection

The world right now exhibits a strong and ignorant it works for me attitude. We have all shared a laugh or two at those stockpiling tinned food, pasta, hand wash a toilet paper, but to name a few. On the day I write this we have been unable to secure the nappies and formula we need for our infant son. We are clearly part of the minority group that only purchase what they need. Warnings to take what you need to ensure others can also obtain what they need are definitely being ignored. How people have the time to try numerous shops every day to find new stock of items to pilfer is beyond me.

With high numbers of us establishing remote connections to the office, some such as myself are left out in the code with freezing connections

Remote workspace attitudes are exhibiting the same selfish side effects. The age old joke of it works on my machine leaves a rather bitter taste in the mouth of those who are expected to be productive using connections that lock up for half the day. True leadership on remote workspace requires ensuring all have the tools they need. Leaders must provide support to expedite issues quickly. To do that they must listen to the concerns people are raising in the first place.

Anybody Seen My Baby?

Over the next few months our work and personal lives are going to collide together into an ugly mess of inactivity. Conference calls will be interrupted by family members and neighbours. With my quintessential self-deprecating humour, I joke about my infant son and husband joining the stand up. However, the reality is that a baby’s cry breaking through in the middle of a planning call leaves me feeling very raw and exposed to colleagues. Until I take the financial hit and sort out a dedicated space this will continue to be a problem. Even once a dedicated space is found, I will continue to battle to be heard through the noise of my neighbours ongoing construction work.

It’s time to put down the toilet roll and show some empathy people, both while working remotely and enjoying our homes!

As the world progresses through this period of social isolation, I am struck by a disappointing realisation that support will be hard to find. Having gone through a reduced element of isolation for 6 months while on maternity leave, I know first hand the emotional toll it can take. As many petition for us to think of others and stop panic buying, the same must apply to our colleagues. Think of those who live alone and may appreciate a video coffee break. Consider the opposing exposure of family and how invaded it can feel. Expressing kindness and empathy to others situation is paramount to making it through this tough time. Good luck all!

Thanks for reading! 

One Week

The Adventures of a Newly Returning Coder Parent

Cue the fanfare. Coder Mummy is back! Following six months of bottles, nappies and home nursery rhyme karaoke, the time has come to return to work. It’s constantly been referred to as my transition. In a way that’s true. Frustratingly, my first week has definitely been more of a mental and emotional metamorphosis rather than the regimented algorithm I would expect as a software engineer.

Going into my first week back, I encountered a strange mixture of excitement and dread. Yet I found very few honest accounts of people’s experiences. Returning role models are happy to engage in discussion, but very few appear to have documented their experience. Furthermore search results captured using your favourite search engine focus on legal rights rather than personal experience. It’s almost as if talking parental return is a weakness. As a result I’ve been trying, and failing, to dust it under the carpet and separate parenthood from my work life.

Working as a software engineer and being a parent currently seem like opposing aspects of my life

One profound moment was a colleague attempting to convince me that being a parent is in fact something to be open about. That it can be used to built rapport with clients for example. For that to happen, someone needs to start talking. To close the maternity journey, and start the conversation, here I reflect on my first week returning to work as a software engineer. Check out a subset of the expected and unprecedented challenges here.

Knowledge Me Again

One strategy I employed to keep abreast of domain knowledge during my leave was monitoring emails while out of the office. This was only partially successful. Many on long term leave may wish to switch off entirely from work. However, I seemed to miss that desire completely. Despite telling myself the purpose of email checking was to ease my transition back, the reality is that I also feared my inbox being full of irrelevant errors and warnings. These frustrations still remain, and I still support my previously mentioned musings on system alerting considerations for development and support teams.

Email mountain was difficult, but not insurmountable

Irrespective of how much you try to keep up to date with emails, you will have to conquer email Mount Everest upon your first day. Especially if we continue to adopt emails as a poor alerting mechanism. I wasn’t able to send emails for around one hour as I frantically deleted pools of alerts from one of our noisier components. Regardless the only impact this had was delayed notification of treats to the team. It did have the expected result of people stopping by to say hello. So if you only take one piece of practical advice from this post, make sure it is to celebrate your return with cake.

Lack of Knowledge

An unexpected surprise I uncovered was how much information I had retained. Although one must question if this is an indication of the capacity of my mental hard drive or how often I was digging into emails and catching up with colleagues. Yes part of the justification was the alerts and keeping up to date. However, the unfortunate reality is more that I never switched off from work at all. Instead I succumbed to an overwhelming desire to keep plugged into the matrix. Not exactly the healthiest of strategies!

One must wonder how much of the information I gathered during my time out turned out to be fruitful. As stated in my piece on my maternity learning journey, changes such as organisational updates was helpful in assessing the new world order upon my return. Although I did note that product domain knowledge would help me hit the ground running, the reality is that it’s not helpful as I initially thought. Mainly because I’m no longer actively working on that product anymore. It simply satisfied my urge of curiosity for what’s happening. But now I am suffering information overload from this new project. I’m all for being thrown in the deep end, but this feels more like I have been pushed out of a helicopter into the pacific!

The mix of pride at knowledge retention, dread of information overload, and feeling of muscle memory loss is a rather odd combination

A rather unlucky trait to lose was what I like to call my role muscle memory. Essentially the instincts that you develop over time that govern your capability to form strategy and identify the next step on the product development journey. My current strategy to build this up is simply to ask what I perceive are obvious and ridiculous questions. I am extremely aware that I may be asking more than before. Yet the opinion of others is that I have always been that way.

Differing viewpoints on whether this constitutes as a strength or weakness are definitely fascinating. My perception of question overload as a bad trait is most likely down to an over-awareness upon returning to work. I need to consider this as a normal personal strength as opposed to a negative side effect of my return. Until then, it’s time to apply the poker face. Or quite simply, keep calm and carry on.

Buzz Buzz Buzz

Concentration on mentally involved tasks such as coding are proving to be exceptionally difficult right now. Originally, I attributed this difficulty to lack of use over the past six months. In a way my brain is much like a disused car abandoned in the garage for months on end. It’s going to take some time to get it started again.

There may not be bees buzzing around me while I work, but without headphones it definitely feels like it

The reality is I’ve become more susceptible to the buzz of the office. I’ve discussed office capacity and its effect on developers before. It also has an impact on other practices such as pair programming. While I acknowledge babies cry, it’s a different kind of noise to the haze of unintelligible murmurs that echo through the floor.

Focused tasks like coding are definitely more challenging now. Noise cancelling headphones are helping to reduce the distractions. Nevertheless coding tasks are definitely taking a lot longer since I’m out of practice. I pity the poor individuals reviewing my code!

Song for a Friend

My support network has definitely changed. A big concern for me was lack of support. I’ve effectively grown up in my organisation, so my friend network consists of colleagues and my graduate class. All of these individuals were at work when I was not. Therefore, a significant concern for me was having to adapt my coping mechanism and expand my support network to include others.

I’ve been having quite a few coffee catch ups since I returned

Much of the existing network did disappear the moment I waddled, yes waddled, out of the office six months ago. Some of it I have managed to maintain while out through catch ups. Others I’ve had to claw back. Coffee catch ups are great for this. I’m fortunate to work in an organisation where people are very giving of their time. Nevertheless, some contacts have been lost.

There are several reasons people have become disconnected. People do come and go, meaning more effort is required to keep the connection alive. However others just get busy. Reigniting those relationships will take a more flexible approach.

Time After Time

Most of the aforementioned challenges are specific to either office or IT working. One of the more normal struggles I’m currently experiencing is the “get up and leave on time” paradox. There is yet to be a day where I have left feeling productive. I am completing some work items, and managing to either delegate or negotiate deadlines for others. Just not always as many as I would like. Not leaving in the evening now will set an impossible precedent for when baby goes to childcare in a few months. So not getting a handle on this now will definitely bite hard later.

The complementary “leaving in the morning” conundrum is also proving to be exceptionally frustrating. While I am fortunate that I’m sharing parental leave, and it’s partner’s turn to have his moment, it doesn’t make saying bye every morning any easier. Thankfully he has first hand experience of the heart-string tug, making it easy to talk over.

Leaving both work and home at respective points in the day is yet to become easy

Perhaps there is also an element of FOMO, or fear of missing out, at play. Of course it’s normal to regret the work opportunities missed on leave. Everyone undertaking long term leave will definitely lose out on some opportunity simply due to not being present.

Currently I’m hanging back too often to help others and be seen as a team player. No one wants to be seen as not performing. However right now my feeling is I’m both not performing at work and missing out on Baba’s latest achievements such as rolling over and trying food X for the first time. Cue the age old parental guilt!

Please Be Kind

I haven’t covered every niggling thought that occurred over the course of my first week. If I did, this blog post would rapidly evolve into a book. The key themes of disparate knowledge retention, a lack of control and the endless quest for work life balance are definitely covered. Nevertheless, the biggest surprise has been that there is a wealth of support out there if you just ask.

One of my next steps will definitely be to focus on establishing a better work home boundary. Otherwise in addition to parental guilt I’ll end up suffering burnout.

This new dual existence needs to be combined together for me to be my authentic self

I’ve realised that I need to be kind to myself. The skills I thought were gone are still there. I can still design and code. Albeit the latter needs some coxing out. Right now I am my own worst enemy. Segregating my character is stopping me feeling comfortable bringing my authentic self to work, and that’s not going to help me develop. It’s time for Coder Mummy to embrace the dual identity of mother and software engineer.

Thanks for reading. Do share your own experiences of leave and returning to work!

New Year’s Resolution

Planning Kanban Adoption for Home Task Management

New year. New decade. Cue the numerous social media posts outlining unachievable resolutions that people have absolutely no chance of keeping. The majority of my friends set typical goals such as new gym routines and healthier eating habits. However, the Richmond family have a more unconventional ambition in mind.

Throughout my eight years as a Software Engineer, I have grown to be strong Agile advocate. My experiences working in both Waterfall and Agile focused teams have fostered a strong preference for the latter model. To the extent that my status as an Agile evangelist is known far and wide. Furthermore, it is also a source of jest, as emphasised by the Scrum notebook I received as a baby present, illustrated below. Apologies colleagues, I thought evangelist was more suitable than geek!

My reputation as an Agile advocate is well known across the team. Hence the Scrum notebook as a maternity present!

I’ve always been far better at organising work commitments compared to my home responsibilities. To the extent that work is consistently prioritised above home. When I return to work in a couple of weeks, a better balance needs to be maintained for the sake of my family life. As well as for the sake of my own sanity. I must find a better way of using my strong organisation experiences from work in my home life. To this end, here I set out the initial thoughts on creating a Personal Kanban process, and set the initial goals for one of my 2020 resolutions.

Business Never Personal

To ensure this is not yet another lost resolution that’s committed to the rubbish heap, it’s critical to outline the justification for using Kanban in this unorthodox setting. Our current home organisational model is flawed due to a simple lack of visibility. Myself and my husband currently use a generic TO DO app inspired by post-its. Features such as cross device collaboration and reminders are fantastic for small urgent items. When it comes to longer term items that require more effort and planning, they often become lost. Furthermore, progress made on these items is difficult to track. Especially over the last few months with the arrival of Baba and the resulting mutual sleep deprived baby brain.

A second consideration is grouping of items into themes is problematic. The vast majority of TO DO applications provide colour coding and labelling capabilities. However, the agreed formats or labels are also challenging to track.

Use of a personal Kanban board to track my own work items has proven to be a helpful tool for me for several years. As a team we use Jira for our work items on our products. Regardless, for my own additional work items such as paperwork and goal setting, I use my trusty personal Kanban board to plan out my week, presented below. This is definitely the best and most practical gift I’ve every received from a colleague.

This physical board has pride and place on my desk.

Of course we could simply use this board at home. From a selfish point of view, I would require another board for work. There are also some practical considerations worth noting. Firstly, with my son’s impending weening and current focus of sticking everything in his mouth, falling post-its are bound to end up being eaten. Therefore a board out of reach with cards that won’t wall is definitely needed.

Additionally, the time slot swimlanes do not help with this current issue of tracking progress on these tasks. We’re not even sure which states we require. To that end, it’s time to consider a medium with configurable columns to give us flexibility of states. Finally, given the constant reprioritisation and context switching present in the current process, adoption of Kanban over time-boxed paradigms such as Scrum to reduce WIP seems most appropriate.

We Need a Resolution

In committing to this resolution, there are a few setup considerations that we need to evaluate. Just like adoption of any Agile methodology within the software development domain, details of the adopted setup must be agreed by all parties using the process. In this case we’ll exclude Baba from discussions, mainly because he’s yet to speak. Nevertheless, all attributes of this model must have full backing of both Mr Richmond and myself.

To address visibility concerns, a physical medium may be more effective than a virtual tool. Certainly I intend to conduct research to identify any Kanban applications that could solve our state and visibility problems. However, the notion of finally having a physical whiteboard for Agile activities over the typical online tools is rather thrilling. There are three key items that we required for a simple magnetic Kanban board, with configurable swimlanes.

  • Whiteboard
  • Magnetic Story Cards
  • Whiteboard markers

Yet it’s not only the existence of a board that must be assess. Board location is also of vital importance. Elaborating on the visibility issue of the aforementioned app, notifications and reminders are required to trigger your attention to particular items. Hiding the board in a far off corner of the house doesn’t call tasks to mind. The board should take pride and place somewhere prominent. Perhaps somewhere you spend a lot of time. Or even somewhere you always frequent when returning home from work. For us the kitchen definitely sounds like the prime candidate. The added bonus is there’s also a free wall already available.

The board must be prominently and proudly displayed for all to see

Agreement must also be reached on the nuances of the board itself. Our initial thoughts of states are the simple TO DO, IN PROGRESS and DONE. However, depending on our progress and the number of outstanding items at any time a PENDING state may also be required.

The scope of the item population is another consideration. The initial population can obviously be obtained through the current pending items within our application. The results of a joint brainstorm are another potential capture mechanism. There is also value in agreeing items suitable for exclusion as well as inclusion. For example, adding the nightly post-dinner task of washing the dishes is definitely overkill. Dishes and bottle sterilisation have become as second nature as Baba’s sleep routine.

Measure for Measure

As stated previously, adoption of Kanban is intended to address several challenges with organisation and execution of home tasks. In the spirit of continuous improvement, we must evaluate whether Kanban adoption successfully solves the aforementioned issues. Just as I found in adoption of Obstacle board by one of our squads back in 2019, that warm fuzzy feeling of subjective improvement is not enough. Even for personal adoption, establishing quantitative metrics is imperative for measuring progress.

Even personal adoption of Kanban requires some measurement to assess effectiveness

We can easily track the number of completed tasks per week. The advantage of adopting a whiteboard is that single metrics can be written in the top corner. I would suggest that the ratio of completed to uncompleted tasks will assist in establishing our work in progress, or WIP for the who are familiar. In formal work settings, time to completion would be effective in establishing the work rate.

Simplicity is key to ensure adoption of Kanban serves to benefit the household and improve task management. It must not negatively impact our family life. However, multi-week trending of any agreed measures requires regular documenting of metrics along with the week on week delta.

The Adventure and the Resolution

The idea of Personal Kanban is certainly not novel. A simple Google search provides articles documenting usage for organisation of personal work tasks and home use. Learning from their experiences is indeed important. Nevertheless, what is novel is the assessment of whether it works for addressing my current home organisational trials. Personal Kanban is very personal in that regard.

As with all resolutions, establishing a habit will prove challenging

Like any resolution, there is a chance this endeavour will be abandoned without significant effort to establish Kanban usage at home as a habit. Blogging my experiences is my chance to force a longer term commitment. Look out for a future update on our successes and failures. 2020 is the year where work and home shall collide, hopefully in a positive way. It is the year where I finally attempt to balance the organisation scales of home and work using a method from my working life. Wish me luck!

Thanks for reading!