Carly Richmond

You Learn

Evaluating The Effectiveness of Different Learning Mediums on Long Term Leave

We spend a significant portion of our adult lives working. Eurostat estimates the expected working life duration of EU workers in 2018 to be 36.2 years. Given such a large window, it may come as no surprise that we all need a longer break than the occasional sick day. We may take time off for travel, long term sick or parental. Irrespective of motive, we will have breaks in our employment history.

Taking a long term sabbatical makes keeping up to date difficult. Regardless of your occupation, you will undoubtedly return to work in N months to a new cast of colleagues; a forgotten array of knowledge you need to claw back; and the need to adjust to a large set of procedural changes. In any profession, returning from a period of leave will be daunting.

Returning to work after a long period of travelling or parental leave can leave you feeling behind the technical curve

The rapid pace of technological change means those dedicated to a Software Engineering career must also contend with missing out on the technology evolution. Learning should form part of your daily work routine. However, discussions with colleagues leads to an element of learning via conversational osmosis. The latter is a critical element that is missing when you are not in the office.

My extended leave has required me to adapt my learning style to assimilate new information. Partly because I no longer have a daily commute to cuddle up with a book and a hoard of squashed travellers. In some ways because I’m isolated from these office conversations. But also due to the sheer number of interruptions I encounter everyday. Here I share details of my learning journey; which formats I have found effective for keeping up to date; and my reasons for wanting to stay in touch with technology.

I Can Learn

Before delving into details, I must state the following unequivocal disclaimer. No one should feel pressure to try and learn while on leave. Organisations and managers should support colleagues irrespective of their decisions for contact or learning.

There should be no pressure to hit the books while on a sabbatical. Supporting those who wish to learn must be balanced.

Many are quite happy to put work on the back burner. For me switching off from the exciting world of software development has been an impossible dream for a couple of years. Of late it has become more of an intellectual life buoy that I cling to in the scary world of new parenthood. Sometimes your brain needs a well deserved break from the mindless repetition of nursery rhymes and The Very Hungry Caterpillar!

This article is intended for those who wish to continue their learning journey while undertaking a period of leave. Or who are looking to incorporate learning into a busy work schedule. Essentially, for those who share my ethos for continuous learning. Here are the mechanisms which I have found accessible on leave, in increasing levels of difficulty.

Letter in the Mail

Medium: Email | Difficulty Level: Easy

With the majority of organisations providing remote working capabilities, reading the occasional email is a quick and easy means of researching current internal trends. Personally I have found the occasional scan useful for monitoring several knowledge streams:

Product domain knowledge
New product features
Technical trends and practical applications
Organisational updates
Internal initiatives
Team changes and events

There is a wealth of information to be digested in your own time. Nevertheless, there are a few pitfalls you should avoid. Depending on your internal infrastructure, passwords may need to be updated regularly to prevent lockout. The regularity with which you monitor email, and access systems to maintain access, is another danger.

Email exhibits a similar hit to gambling. Beware excessive email monitoring while on leave.

Ensure you exercise a degree of control. Email addiction is the last demon you want to try and kick when you’re balancing dominating life commitments. Set yourself a frequency and maintain that routine. Avoid replying. Trust that the team can handle things without you. Set up mail filters to exclude or delete any system alerts or checks. As discussed previously, filtering out relevant information from high volumes of email alerts becomes exceptionally difficult.

Cast Your Pod to the Wind

Medium: Podcast | Difficulty Level: Easy

Until now, I’ve never been a big fan of podcasts or audio books. Music and the written word tend to be my commuting mediums of choice. But if you’re out exploring, or in my case trapped on the couch with a cuddly newborn, listening is far better. Quite simply because it frees up your hands.

Podcasts have become a useful hands-free learning tool for me.

Podcasts have become an invaluable knowledge source. Obviously getting your hands back is a big advantage. The ability to subscribe to channels and be notified of new episodes makes it easier to track new trends. It is possible to focus on what is being said while you are doing something else. Audio content also makes for a nice break from the mind numbing repetitiveness of daytime TV. Oh how I have come to loathe TV and media streaming platforms!

There is a myriad of different podcasts available covering a variety of fascinating topics. In addition to the Agile focused streams I’ve been following, other podcasts including TED Talks Daily and Superfreakonomics Radio have provided a set of welcome alternative topics. In fact, the recent recast of How to Change Your Mind got me thinking of the importance of openness in Software Engineering and our desire to track technology evolution. No one said software topics are the only way to engage your brain.

Keep Talking

Medium: In Person Catch Up | Difficulty Level: Medium

Extended leave can be an exceptionally isolating time. It’s imperative that you attempt to meet new people and establish new relationships while on leave. Antenatal groups and tour groups are examples of great methods of building networks on paternity leave or while travelling. Discussing your current challenges in these forums is invaluable. In the case of parental leave it can be difficult to escape baby talk for some much needed adult conversation.

Coffee catch ups have formed a welcome learning opportunity, as well as exposure to adult conversation.

Keeping some of your current working relationships warm provides vital support. Those connections can alleviate the fear of being forgotten. Both phone and in-person are valid formats for such meetings. However, be mindful that in-person conversations within the office require a supportable environment. Irrespective of your chosen location, these sessions are a great opportunity to find out about new products and features, organisational updates, team restructurings and new internal processes and initiatives. Such topics satisfy the need for adult conversation and allow avoidance of controversial subjects such as politics.

Internet Killed the Video Star

Medium: Blog Article | Difficulty Level: Medium

One aspect of my original morning routine that I have managed to preserve is my morning perusal of blog articles. With the small amendment that anything over five minutes needs to be reserved for nap time. Ironically this piece would meet the latter requirement.

Blogs are short, sweet and instantaneous sources of information.

There are numerous mobile reading and social media platforms that can provide blog recommendations. Utilising various platforms exposes varying opinions and topics. My personal top three are as follows:

The sole challenge I’ve found is setting up preferences across various apps. Push notifications are a great time optimisation compared to manual searching. Depending on the platform, preferences can be tweaked far more quickly. Especially if they support automatic suggestions based on your reading history.

Read it in Books

Medium: Books | Difficulty Level: Hard

Now we are getting into the more challenging learning formats. Books require a greater level of effort and dedication than the aforementioned blog posts. The premise is certainly the same. However, the sheer length of the content makes it increasingly more likely that you will encounter interruptions.

Historically, I have always managed to read at least one fiction or non-fiction text per month as part of my daily commute. Therefore a pre-maternity goal of one book every two months while on leave appeared feasible. Oh how wrong I was!

Curling up with a good technical book is not always possible while out exploring the world.

Curled up on a twelve hour flight, or a two plus hour train journey, this goal would be achievable. It was achievable while I travelled through Japan last year. You have ample time to settle in and digest the content. I’ve found the number of interruptions I currently encounter result in repeatedly re-reading sections. In hindsight, I may as well restart the book over again when I return to my daily commute. Until then, let’s see how long it takes for me to finish my latest Swedish crime noir novel.

Video Games

Medium: Tech Tutorial | Difficulty Level: Impossible

While I’ve made attempts to try the aforementioned mediums, completing at least one tech tutorial has proven to be an elusive dream. I can imagine completing tutorials would be a powerful means of combating concerns of falling behind the technical curve. Yet it is the most challenging mechanism with which to dedicate time. Although I successfully completed one tutorial pre-baby, post baby it has been impossible.

Tutorials require an attempt to follow the steps to reinforce the lessons.

Simply watching video tutorials is certainly achievable, just like podcasts. Nevertheless, practicing the corresponding techniques is imperative to reinforcing the skills covered. Practical implementation requires focus. It is hardly easy to maintain concentration in the face of interruptions and background noise, irrespective of where you are. In this regard, I’ll save these learnings for a Friday afternoon back in the office.

Learn From This Mistake

This piece serves as a reflection on my experiences of trying to maintain my learning without a regular work structure. Even the most varied of software development roles has a relatively strict workday. While on leave, you would expect a new routine to form within which learning opportunities can be integrated. In reality this is unlikely to happen within the first few months.

Learning should complement and not dominate your time away from work. Remember to live!

I have enjoyed experimenting with new learning mediums over the past few months. Diversity of formats allows for the extraction of varying knowledge and perspectives. Yet it has also had the unintended consequence of exposing the need for balance in my life. Work and learning has always come first. Yet the next challenge awaiting me in 2020 will be balancing work, learning and family life.

Thanks for reading!

Breaking The Silence

Evaluating the Effects of Workspace Factors on Non-Permanent Stakeholders

Being on parental leave has a funny way of forcing you to look backwards rather than forwards. To reminisce about your old life. The one where you went to work everyday. The one where you got through one book per week on your commute. The one where going out was impulsive and required less supplies. Nowadays you would think I’m embarking on an expedition to scale the nearest summit every time I walk out of the door with all the stuff I take with me!

The state of our workspace, and it’s problems, is yet again a focus of conversation

Lately I’ve been reflecting on prior entries. Coming across my old pieces on workspace agility and developer perks collided with a colleague’s recent thoughts on the state of our workspace. He correctly pointed out that the same issues that have plagued us for years persist. They still impact those trudging into the office every day. But some were surprised to hear that they also impact me. Albeit for rather different reasons.

Yet again I’m thinking about work environment, but from an alternative angle. Workspace quality affects people other than those who use them every day. To this end I ask myself two simple questions. Who else are our workspaces built for? How do the gripes of the regular workforce impact those other parties?

Waiting on a Friend

Recruitment is paramount to the competitiveness and survival of any organisation. Leaders at all levels comment on the importance of the interview format and interviewer demeanour. Both are vital to conveying the culture and role. Considering my own interview experiences on both sides of the table, I see how important politeness and openness have been in attracting the candidate. Interviewers must be salespeople of the organisational culture.

Interviewers are selling your organisation and culture as well as the available role

Interview location also makes an impression on candidates. While contenders are usually ushered off to meeting rooms, even the quickest dash provides them with an opportunity to view their potential work environment. Applicants will absorb the noise levels. Candidates will observe their possible workstations. Interviewees will view how teams use any collaboration resources such as whiteboards and huddle areas. They will also observe if these spaces are actually provided. While they may ask questions about the environment, which some have in my experience, many will remain silent.

A good impression of the work environment should be presented to all entrants, regardless of level. From leaders, to managers, to future graduates, all have a vested interest in the space of their potential workspace. I recall my own assessment centre. We were placed high up on the swanky floor with the breathtaking view. Today we conduct office tours of the newly renovated floors to convey a similar impression to graduates. While I was aware that I would be unlikely to work on a floor filled only with meeting rooms, the latter tours can set up candidates for bitter disappointment when introduced to a cramped, noisy environment lacking those same facilities that they were sold. Such perspectives are regularly conveyed when discussing the older floors.

Keep the Customer Satisfied

Every technology team builds software for the benefit of a particular user base. Otherwise the need for the product should be called into question. The strong client focus baked into the Agile manifesto, and every practical implementation, means that development teams and client representatives need to collaborate.

With internal clients, logic dictates that you either have the development team and users co-located on the same floor, or individuals take turns visiting respective areas. Having the development team and Product Owner inhabiting the same area helps establish a strong, cohesive relationship. Although I do not work in such a situation, I imagine the reliance on noise-cancelling headphones we currently have could not thrive in such an environment. Fostering the desired synergy requires huddle spaces and noise reduction mechanisms to eliminate the need for headphones for brain intensive work.

Our reliance on noise reducing headphones for coding would be counterproductive when co-located with our clients

Having operational teams and development teams on different floors can set a dangerous precedent in the event that facilities differ. Remember the infamous coffee machine incident? Animosity was allowed to breed as technologists believed they were being treated differently from other employees. Permitting a wedge to develop may harm the close relationship that we seek through Agile practice.

Coffee Machine Gate still remains a sore spot for some

Hosting clients on the technology floor will not necessarily be harmed by having the lower specification coffee machine. Nevertheless, other factors such as lack of meeting rooms or huddle spaces will negatively impact collaboration. More of these spaces are required, complete with whiteboards. I am a big fan of using scribbles to explain my perspective, so the more whiteboards in the workspace the better.

Mother’s Little Helper

There is a common misconception that every employee taking a sabbatical, parental leave or any other extended time off doesn’t need or want to step foot in the office. That you are taking a well deserved break. As if it is a vacation. Sadly a small number of individuals still believe this to be the case.

Noise travels. I have previously discussed how the distracting hum of conversations ebbs through the floor like the blob slowly creeping and eliminating all productivity in its path. In my experience, this issue exhibits three key symptoms. Many employees wearing noise cancelling headphones is the first indication. The second manifestation is many colleagues occupying meeting rooms to complete focused work. Unfortunately the third warning is acrimonious employees complaining about noise levels.

Changing attitudes to parental leave and family mean office facilities need to better support keeping in touch

By no means am I suggesting that offices need to support swathes of babies arriving everyday. There is no need for swanky parent rooms with baby changing stations, bottle warmers and every other baby gadget in existence. Although I do hear rumblings of office spaces having baby changing facilities on canteen floors, which is fantastic. Spaces simply need to be inviting to parents. The introduction of Shared Parental Leave in the UK, coupled with increased focus on female retention now makes baby friendly amenities an item to consider in the urban planning of work environments.

Workspaces have some useful resources. For example, Offices in the UK are required by law to provide private spaces for expressing. But such areas are often hidden away from work floors. Furthermore, monopolising these spaces for even a half day of KIT catch ups will inconvenience others. For reference a half day is the minimum you can claim for. A shortage of drop in meeting rooms makes spaces less inviting for visiting parents. The last thing you want on a KIT day is running around the floor with a crying baby and being asked by a colleague to quieten the child down.

Small drop-in rooms that don’t require reservations from colleagues on leave would greatly help support keeping in touch

Also examine the effectiveness of your remote working offerings, and ensure all sabbatical employees are provided with remote access for the full duration of their leave. Just like Eli Pariser proposes to foster desired culture on social media platforms, remote and physical work platforms should be evaluated for effectiveness and cultural impact using similar techniques adopted by town urban planners.

Baby Driver

Of course the primary consideration in the design of any workspace should be the employees working in the space everyday. Regardless, indirect users of any working environment will take away an impression of your culture from the provided facilities. Their perceptions are absolutely worth considering.

Organisations jumping on the Agile bandwagon should take note that workspaces must support squad practices. Only by addressing these environmental issues will you foster the culture you wish to convey to these additional agents.

Thanks for reading! Do also check out my other pieces on developer perks and workspace productivity.

The Mother We Share

Confessions of a Neurotic New Mummy Coder

Becoming a parent is hard. It doesn’t matter how many books you read. Or how many warnings you receive from friends and colleagues. Or however many hours of extra sleep you attempt to stockpile in advance. Your new reality swings through like a sledgehammer through a paper wall. A world of laughs, tears, isolation and general cluelessness becomes your new routine, and that’s if you’re on parental leave. We’ll see how the adjustment to juggling work goes next year. Until then I’ll probably continue to have nursery rhymes running on repeat through my head.

Becoming a parent requires adapting your coping mechanisms. If you are on leave, not all confidants are accessible. That second glass of wine is a bad idea. As is one more slice of cake or chocolate if you’re attempting to lose that pregnancy weight. Or sympathy weight. Partners be honest, you’ve all been there.

One of my key coping mechanisms has been humour. Humour that seems to become increasingly more borderline appropriate, depending on your personal preferences. Thankfully I don’t seem to be alone. Sharing with my antenatal mummies has shown many of us are adopting the same tactics. Friends with and without kids see the funny side, even with the darker jokes.

The Joker

Becoming a software engineer was far easier. Many of the stereotypical programmer pigeonholes I’ve never fitted into now adapt to my new existence. Here I share some of my observations. None are intended to belittle the challenges of parenthood. All simply serve as a means of uniting humour with my other coping mechanism of reflective blogging.

Humour is an important coping mechanism for many of the challenges of life

Birth plans, like any production deployment run book, never work out to the precisely defined steps. Many tasks are deemed either not required, altered or swapped with an entirely new procedure.
Forget formal Agile ceremonies. Stand ups are redundant. There’s no point listing what you did yesterday and today as they are exactly the same. Retrospectives, while useful, are rare. When they do happen, half the mechanisms that worked last week now result in tears or looks of befuddled wonder.
In the beginning, simplified Kanban is the only way to manage the priority tickets raised by your little bundle of joy. The new need immediately jumps to the top of the prioritised backlog.
Regardless of whether you are in the zone writing code, blogging, reading, showering or simply having a cup of tea, be prepared for constant thought interruptions. Each of these tasks takes three times longer than before the baby arrived.
As soon as you find a new algorithm to solve putting him down to sleep, it will prove ineffective. The quest is then on to find another, or add yet another conditional to the ever increasing if construct.
Even the most introverted of developers will feel isolated and crave any basic form of adult conversation. Mainly to escape the loop of singing nursery rhymes, or yet another reading of The Very Hungry Caterpillar.
It doesn’t matter how many conference t-shirts and pairs of jeans you have collected over the years. You will quickly run out of clothes not covered in pee, spit up or poo. Good thing you’re washing clothes almost every day to keep up with demand.
Late night and early morning production escalations become the new norm. Every two hours the cries ring out requiring feeding, changing or other maintenance steps to keep the system alive.
The fear in transitioning from developer to manager quickly becomes overshadowed. No longer are you concerned about negatively impacting a human’s career. As a parent you worry about screwing the entire life and development of a tiny human.
Browsing of framework API’s is quickly replaced by instructions for prams, carriers, sterilisers, cots and any other equipment deemed necessary to keep baby happy, content and unharmed.
Group play, mummy play date and other baby related activities become more akin to your first tech meetup. Many are exceptionally cliquey. Breaking into the established mummy groups becomes a game of minor baby chit chat.
You spend far too much time in coffee shops. Take the quintessential freelance developer. They exchange coffee for WiFi access to API docs and social media forums. The typical new mummy swaps coffee for basic human contact; a feeding and soothing forum; as well as the toilet for timely nappy changing. It’s far easier than risking a trip to the noisy throws of a crowded office where you run the risk of no free meeting rooms to soothe the little one!

Appreciate the thoughts of all those wishing to contribute to this discussion. Thanks to the many friends who helped refine these jokes!

Rudie Can’t Fail

The Case for Evolutionary UI Prototyping Over Primary Feature Perfection

Over the past through years, innovation has become a buzzword in many technology domains. This includes the finance industry where I currently reside. Yet many consider it to be an extra function, rather than a core tenet of their daily responsibilities. Or even a one day event in those circles that host regular hackathons. Yet the fail fast mantra has a strong synergy to Agile development. No UI development technique could be more imperative to regular innovative development than prototyping.

Last week during my daily article perusal, I came across a piece on Agile misconceptions. The key item that caught my eye was preconceptions that adoption of Agile methodologies have stifled their ability to innovate. My initial reaction is that adoption of Scrum and Kanban for various teams has ignited a fire of innovation among our engineers. This is true in the production of our overall system infrastructure. However, UI design remains an area where we are unwilling to make mistakes.

Evolution of man to modern day with phone — Interfaces should evolve to encourage failing fast and learning from our mistakes

Wireframes are one option to explore product designs. They are certainly worth considering when you have a dedicated designer. My musings on this were presented some time ago. Evolutionary prototyping is another powerful tool in our quest to fail fast. Particularly for development of the user experience. As a visual medium, everyone from developers to clients to designers has an opinion of what is considered usable and intuitive. Here I reflect on our struggles of building evolutionary prototypes, and the resulting impact on features.

Perfect Illusion

Programmers are perfectionists. Despite adoption of Agile practice, we still often struggle with showing work in progress. Yet we then become frustrated that we didn’t get it right first time. Or that the requirement still keeps changing an we want to lock it down to complete the work and move onto the next shiny feature. We should all hold up our hands to being guilty of this cardinal UI sin. Myself included.

Breaking the programmer psychology that I can only present a complete feature. The fear of feedback in a cycle needs to be broken. Showcasing of smaller increments does not make development of any feature appear less impressive.

Stack of books — Evolutionary prototyping is a useful tool for team learning. Endless reading will only get you so far!

The learning opportunities evolutionary prototyping presents are another ignorable advantage. Lack of UI development expertise has been a considerable challenge for us. To the extent that we wrote our own blended learning course to up-skill our existing engineering contingent. Evolutionary prototyping follows the same philosophy of learning by doing.

A Little Less Conversation

Regular demos have been attempted within several squads, with mixed results. The aforementioned developer perceptions is one hurdle. Another would be the rate at which client feedback can be obtained, along with the number of stakeholders involved in discussions.

Smaller, regular feedback on small changes has worked well in one space. This is down to having an extremely engaged pair of stakeholders that possess a strong vision for the product. In another space, time to market for equivalent features is longer due to the degree of dialog required to achieve client consensus.

“We like you too” text on a wall. A very succinct piece of feedback. — Small, regular feedback is far more effective in driving feature direction than many upfront conversations

Some upfront discussions will of course be required to identify the initial features. User story mapping is an invaluable tool for generating the initial story subset. Constructing client side features through evolution changes the conversations. Any artefacts serve as a conversation stater, as opposed to a validation.

Time After Time

Despite the justification for their usage, prototype production time will affect delivery times. Regardless, making space for evolutionary prototyping should not be discounted. Neither should we ignore the advice of Fred Brooks and simply throw more people at the problem. More people does not necessarily mean more time to prototype.

Adding manpower to a late software project, makes it later.

Frederick P. Brooks Jr., The Mythical Man-Month: Essays on Software Engineering

Some companies adopt design sprints, but regular small prototypes can be just as powerful. Arguably, depending on the agreed deliverables, teams may still fall into the upfront design trap with design sprints unless they are embedded into regular practice. Discipline is required with either option to ensure regular feedback and experimentation.

Failure by Design

I don’t think regular design sprints are the silver bullet that we seek. Even if a dedicated designer was present in our squad, I doubt it would break the discussion deadlock that we have seen with some features. It will also restrict developer learning opportunities, as discussed previously.

New York City Gridlock Alert Notification — Endless discussion cycles can leave features blocked

Arguably it will reinforce the perfection paradigm that currently plagues our practice, and leaves us in endless discussion loops. It has been found that regular discussion of prototypes, even down to the smallest design aspect has lead to rapid turnaround of new features. Now it’s time to experiment with other teams to ratify that this technique works regardless of the client base.

Thanks for reading! Do let me know your prototyping experiences, regardless of whether they are similar are different.

Danger! High Voltage

Managing Software System Alerts

Blaring sirens. Whooping car alarms. Crying newborns. Be it noise, lights or colour, everyday life is full of alerts to which we need to react. People learn heuristics to guide them in identifying the how to’s of everyday life. These rules are normally generated through reaction to the piercing sirens and learning from the resulting successes and failures. However, one just also learning to discern between showstopping signs, indicative warnings and false alarms.

Our real world heuristics to deal with alerts is often more clear cut than those for the software that we build and support

Just life real life, supporting software systems requires reacting to alerts and system status at key points in the business day. Yet, the common developer support divide often leads to poor alerting capabilities. Developer empathy is often lost when considering exceptional situations to flag.

Discussions regarding alerting considerations and their support impact by developers have previously taken place. Nevertheless, it is only when we experience it ourselves that engineers stand up and take notice. My current sabbatical has meant our warning mechanisms have proven difficult to filter out alerts that I won’t react to with information that will help me keep up to date. To this end, I reflect on the state of our system sirens, and attempt to identify some good and bad practices with our approaches.

Cum On Feel the Noize

To understand the solutions presented, we must first understand the problem. There is indeed a selfish motivation at play here. Regardless of the origin, it has definitely shone a spotlight on as existing issue that until now I was happy to endure.

How do I know about delays and issues in my system, like I would with my train?

Validating the state of some of our systems, be it production or non-production, is a minefield. A myriad of dashboards, emails and custom alerts bombard engineers and support teams alike. Infrastructure mayday emails in particular flood our inboxes. For me on sabbatical, despite reviewing my mailbox filters ahead of my leave, I find navigating the flood to find the useful content exceptionally challenging. Testing environment volumes are often exceptionally high. Despite focusing on only the primary communication groups, I am continually swiping left to clear the clutter.

I Got the Message

While my situation is rather specific, and arguably self-inflicted, they highlight several challenges facing the development and support teams. The first relates to the level of context switching this demands. Programmers find themselves switching more often between email and IDEs. Support teams shift between monitoring dashboards, emails and other applications as they process not only alerts, but ongoing status snapshots. While it might be acceptable for leadership to live in Outlook, we are fostering a requirement for developers to live there too.

Email alerts result in regular context switching between IDEs and inboxes

We should also consider the relevance of each of these signals. While it is perfectly adequate for me to not react to these signs, should our engineers be ignoring them. Differing behaviour is expected for alerts originating between production and non-production environments. Nevertheless, some warnings are consistently ignored due to known issues or lower thresholds. Instilling a selective reactive culture of alerts, desensitises developers.

One (Clear Channel Stripped)

Given our problem statement, what’s solutions can help alleviate the current burden. One cause is that communication and alerting channels have been combined together. Hence why I am filtering through these groups to find the juicy content. A trainer once explained that forums such as emails and social media feeds exhibit similar traits to gambling. I am definitely guilty of searching for the jackpot, while clearing the junk!

My current email addiction is further exacerbated by the number of testing environment email alerts. Honest!

One could argue that separate conduits allow for teams to ignore warnings altogether. Team culture should be evaluated to determine if this is a true worry. Regardless, in addressing the volumes for non-production environments, this is definitely a useful technique to utilise.

Of course, adoption of on-demand testing environments would be a far more effective solution. There are many additional benefits aside from reducing the number of SOS messages sent. Unstable environments can be wiped clean with a single click. Infrastructure costs can be reduced as environments are only available when required. Testing coordination becomes a thing of the past as multiple different environments can be brought up for differing purposes. This is but a distant dream for us currently, but one cannot ignore its place in our alerting allegory.

Message in a Bottle

Another rather troubling issue is developer and infrastructure analysts decision on which events for which to send alerts and warnings. My experiences show that groups gravitate towards opposing extremes. In the majority of cases, when to raise alerts is often only considered when it is too late and the offending feature is live and misbehaving. However, when the need to send a software smoke signal is realised, the volume is not considered. This leads to the opposing problem of flooding subscribers. When using shared alerting infrastructure that many larger organisations possess, a new issue emerges. No one wants to be the software engineer that inadvertently initiated a distributed denial of service attack on another application!

Do we need nearly all of these messages? Of course not! Many are regularly ignored. Developers will instantaneously jump to remedy one issue, but leave another to fester.

The problem with instilling a psychological mindset of different reactions to different alerts is the need to learn them. You are enforcing a set of heuristics to govern your application. Regardless of whether these unwritten rules are alert type, infrastructure or environment dependent, if the reaction required differs you are increasing the learning overhead for application support. Reoccurring sirens should be evaluated to determine why they keep appearing. The most common cause for us is low message thresholds, which should be reviewed more regularly. Here we should either be increasing the limit, evaluating our infrastructure size, or both.

Like newborn cries, alerts should be an indication to react, not ignore.

Much like the different sounding cries of a newborn, the instinct must be to immediately address the issue. The fix can certainly differ. Nevertheless, one should never question the need to react.

Smoke Signals

Yet another cause boils down to a poor choice of signal sending. Emails are not the best alerting mechanisms. Be it a small startup, or large organisations, there are a myriad of different communication tools available to teams today. Yet, email is seen as old reliable. It is the most overused tool of any organisation. They promote confusion. They cultivate a reactionary culture where people rarely speak. They encourage context switching. There are valid scenarios for email usage. However, I would argue that system monitoring is not one such use case.

Centralised diagnostic tools should allow the ability to capture current state, potentially using a traffic light system. The use of RAG status allows us to beat the psychology of ignorance and be clear on what alerts require action. There are cultural considerations when using colour and iconography. However, the premise is that systems should be monitored in one place.

Much like we need to contemplate our communication channels, the medium through which application alerts are communicated must also be cautiously deliberated. It must be accessible via any dashboard capabilities that are made available to teams, possibly as some kind of news feed. One tool is required to communicate the news of the world for your systems.

Last Train to Clarksville

Yes, the suggestions listed in this article stem from a very selfish place. The need to optimise my email monitoring is not the key takeaway. The goal is to convey that programmers and support analysts alike are often the forgotten stakeholder in many applications. Supportability should not be the last resort.

Next time you write a feature, be mindful of what happens when it goes wrong. Who needs to know? How should this be communicated? How many times should the same type of signal be sent? Having business users notify the teams of a problem should be the absolute last resort. The exception rather than the rule.

With the many interruptions I encountered while writing this piece, I appreciate your reads!

Over the Wall

Reflections on the Adoption and Use of Obstacle Boards in Agile Practice

Life is full of obstacles. Be it school, work, home or any other feat we set our sights on, there’s bound to be a few blockers along the way. Let’s be honest, if every desire or achievement came easily, life would be rather dull and unfulfilling. While we can’t always get what we want, jumping a few hurdles builds us up better than having everything handed to us on a silver platter.

Software engineers regularly overcome hurdles in the building of new products

Software development is no different to life. Regardless of the process and technologies utilised, teams will encounter issues. My personal view is remediation of these blockers make building software to be one of the most challenging and fulfilling pursuits. There is nothing more satisfying that solving an issue that has been plaguing your progress. However, in order to achieve that dizzying high, we must first identify and remove the obstruction.

Recent challenges with development of a new product have required some experimentation in how we manage impediments. Our latest experiment is using an Obstacle Board to visualise and track problems. While I’ve found many useful resources describing what Obstacle Boards are, and how to create them in particular tools, people’s experiences of using them seem to be less forthcoming. This week I ponder the successes and challenges of our recent Obstacle Board adoption along with next steps in our journey.

Outside the Wall

While there are many resources that describe what an Obstacle Board is, a brief overview is definitely required. I have certainly found that almost everyone has some knowledge of Scrum and Kanban boards, but that same population are less familiar with Obstacle Boards.

Quite simply, it’s a twist on the usual story board that the majority of Scrum and Kanban teams use. Regardless of whether you use physical boards and post-its, or tooling such as Jira and Trello, an Obstacle Board provides visibility to the state of any impediments to your current work. As pictured below, blockers can still go through a simple workflow to address them, or even be integrated into your existing Kanban Board as discussed by Judicael Paquet.

As you can see, Obstacle Boards visualise development hurdles In a very similar way to how we visualise work in Kanban

Before adding an Obstacle Board to our process, it was important to provide an education to both developers, business analysts and the product owner. Not only is this required to explain the concept, it can help to justify why it should be introduced, and facilitate discussion on if and how the team would like to use this technique. In particular, I have found the following resources useful not only in reinforcing my own understanding, but also in this education exercise.

Building a Wall

Now having done your homework, you should know the purpose of an Obstacle Board. The next question on everyone’s lips is normally what is an obstacle? This is an interesting idea in itself as engineers perceive a blocker to be an issue that means they are not able to make any progress on an item. Snags that slow them down are not considered to be impediments as they are still advancing to their goal. A common understanding of what constitutes a blocker also needs to be agreed when adopting Obstacle Boards.

All squad members need a common definition of a blocker to make a success of Obstacle Boards

Our key problem here was stories were not being completed in the sprint due to logic investigations. With the build out of the new product, comparisons against the existing legacy system found behavioural differences. These proved to be a significant challenge for the development team, who needed to identify the root cause of these differences. Initial tracking measures attempted by the business analysts included Excel spreadsheets and email threads.

The team encountered several issues with reacting to these notification mechanisms. Firstly, the Excel sheet revisions being sent out daily resulted in many duplicate items when the same issue was encountered. The development team struggled to identify key themes, which made raising of defects to fix difficult.

Furthermore, investigation progress was all but invisible as we could not identify when issues were being investigated, and by whom. For those discrepancies that were investigated, significant delays were experienced as all updates were chased via email. Engineers don’t monitor their email constantly to reply to update requests, and if they did I wouldn’t certainly expect a reduced productivity rate as they’ll spend less time engrossed in their favourite IDE. These issues come under the latter definition of blocker, making them more impediments to team progress. Something had to be done.

Climbing Up the Walls

Like any experiment, control parameters and metrics needed to be set to allow for us to measure the effectiveness of the Obstacle Board. Firstly, we needed to identify the issues that were going to capture on the board, along with those responsible for raising the items. It was agreed to focus solely on the data integrity issues rather than raise other development blockers that programmers face while coding. Effectiveness was to be measured by tracking the number of obstacles raised per week, and time taken to commence investigation. Our hypothesis was that both would go down as issues were remediated and the tools accuracy improved.

I’m not going to quote numbers, which may sound strange given the push for quantitative metrics. I’m happy to reporting that both measures have been experiencing a downward trend. In fact, over the last month no new logic snags have been reported, which is a huge achievement.

Initial experiences have shown the Obstacle Board to be a great success in the tracking and remediation of specific impediment types

From a more qualitative standpoint, the board has proven to be a success. Both the Product Owner and Business Analysts have commented that the state of any investigations is more transparent. Any blockers can be explicitly assigned to developers and then back to BAs or the PO if further work is required. The added bonus is that they can be easily converted into stories where development is required, or linked together in the event that pitfalls originate from the same root cause. Developers are also reaping the benefits as they are better able to manage these investigations with other tasks.

Off the Wall

These initial accomplishments are amazing. However we do have some challenges to face to improve and expand our usage. In the current squad, we’ve had to tweak our capacity to ensure we can balance blockers with committed stories. Velocity is starting to even out, but for future efforts we may need to revisit the balance depending on the restrictions raised.

Balancing velocity is one challenge that must be monitored when we expand Obstacle Board usage to other teams

Board overload is a concern raised by some other teams when expansion to other squads has been discussed. I’ve already seen some reluctance to adopt on the basis that we are introducing too many boards. Many managers profess to the desire to have one board to rule them all. Coveting a single precious board has been far too limiting in my experience. Different audiences want a different view of state, be it precise development steps or a more high level, is it ready to deploy yet. Therefore, it is limiting to dismiss using an obstacle board purely for this reason.

Future plans are focused on expanding out Obstacle Board usage to other squads. A similar use case in other squad has already lead to requests from another Business Analyst group to suggest using the board in another space. However, blanket enforcement across all squads should not be the goal. Mandating tools and techniques removes the flexibility and team empowerment that Agile adoption is meant to provide us. Use Obstacle Boards when they can provide a benefit. Do not adopt them as the one ring to rule all issues.

Thanks so much for reading about our Obstacle Board journey!

In Front of Me

Reflections on UI Code Review Rules

The sun rises in the east. Two parallel lines will never intersect. A true idea must agree with that of which it is the idea. From real-life to mathematics to philosophy, life is full of axioms. Despite their established truth, it takes us time to learn these maxims and become comfortable that they are indeed true.

Life is filled with rules to follow, including in writing and reviewing of code

Developers build up knowledge of rules and best practices through their experiences writing code. Part of this knowledge is transferred between developers through code reviews, and use of coding patterns. Exposure to different parts of the system will impact the patterns and rules that we learn. When the experience is weighted more towards backend development, as is the case for us, it becomes harder to disseminate UI standards across the group.

Last week office discussion has turned to UI code review standards. With our aforementioned skills gap, I’ve had colleagues asking what rules I employ in reviewing of our Angular code. These requests have me pondering if code review best practices really that different in Web UI versus traditional back end services. This week I outline some of the my own personal UI code review regimen, and analyse the overlap between UI and middle tier practices.

That’s My Style

Common style guides are a great tool for enforcing a consistent code appearance. While developers have their own preferences on attributes such as brace placement and indentation, enforcing a common standard ensures for better code readability. Many organisations, or even individual teams may have their own for key languages within their technology stack. Regardless, there are plenty of external guides that can be leveraged.

Despite all engineers having their own style preferences, teams should adopt a common style and stick to it

Technology specific ones, such as the Angular Style Guide are preferred over internal standards to align with industry best practices. We have our own Java style guide that integrates with developer IDEs. But for UI, we conform to the Angular Style Guide across the team since we use the Angular framework for all our UI modules. We also ensure our style is enforced using linters such as ESLint for JavaScript and Typescript. Note that it is now standard practice to use ESLint for TypeScript projects as well since TSLint no longer has active support. In addition to providing the aforementioned readability benefits, it also reduces the codebase learning overhead for developers. This applies to those both new to UI within your company, and those new to the organisation altogether.

Complex Person

File and folder structure standards are another important style guide attribute to note. These are often enforced by frameworks. In our case, these are established by the Angular and Gradle structures mandated on the client and server respectively.

For the UI we have all code for a given component housed in a single folder, and common project components listed under a shared folder as outlined in the official Angular Style Guide referenced previously. I also recommend a standard of housing templates in a separate file over inline to ensure consistent usage across the platform. Otherwise programmers tend to use a mixture of inline and separate file based on component size.

Modules should use a simple, agreed structure, with a folder for shared components

Once projects start to grow in size, the nested structure outlined by Tom Cowley becomes more scalable. Where components are required across modules, they should live in a central module that can be managed using NPM. The balance is difficult to strike, but it’s important to identify copy patterns across your own modules to decide when to split a component into a shared module.

Different Languages

Developers should also make use of language construct best practices in their code. These attributes are easy to enforce via code reviews. We are well established in server side practice. Through our use of Java developers are comfortable on when to use streams and collectors versus loops.

Be mindful of using standard programming language patterns

With our heavy use of Typescript, there are some key language good practices that we should be on the lookout for, and should be including in our linter configuration. My biggest bugbear is the use of the any type as general practice. Developers commonly use any in circumstances where they can use a defined type. It is often made use mistakenly in core utilities, where generics would be used in Java. Given Typescript also supports generics, as well as the unknown type, any is not always a valid alternative.

Legitimate cases do occur, especially where you are using a third party library interface that is making use of any. Define explicit interfaces and use types to enforce type safety. Make use of Typescript constructs such as union and intersection types where you want to support multiple types. Otherwise, what’s the point of using Typescript over JavaScript?

Coming Clean

It is a common misconception that best practice patterns are limited to a particular technology or programming language. This notion limits software engineers in their ability to grow as front-to-back developers.

Clean code practices can be applied to any programming language, not just Java

The key text I refer developers to for code standards is Clean Code by Robert C. Martin. I commonly hear from programmers that it is only considered relevant to Java since all the examples are written in Java. This could not be further from the truth. As part of my own reviews, I am regularly on the lookout for many of the practices Uncle Bob preaches, especially the following:

Descriptive functional and variable names that gives detail on the constructs purpose. This includes being on the lookout for non-standard abbreviations that may not be clear to all.
Levels of nesting. Initially reviewing the indentation of a method can give a strong indication on code complexity. Nesting several levels deep should be refactored to promote readability.
Class and function length. Although number of lines of code is not a prescriptive measure of productivity, large classes and methods should be broken down to improve readability.
Levels of code duplication. While in UI projects there is an element of duplication in terms of annotation and form component usage. Although it could be argued that using CLI utilities such as Angular CLI does eliminate most of these requirements. Be wary of significant copy pasting efforts. If you are regularly using the same settings on components such as date pickers, or cell for matters, consider extracting them to a shared utility that can be reused across the project, or even modules.

There are extensions that are UI specific. A key example for me is the use of variable names in style sheets. Through our use of Sass, we can utilise many CSS extensions such as hierarchy and variables. Use of variables for common style attributes such as colour and padding size are another quality that I look for in reviews. These searches are inspired by the descriptive variable names above, and definitely makes style sheets more readable.

Close to the Front

The final, crucial element of any UI review is to evaluate the appearance and workflow of any functionality that is built. While wireframes and prototypes should be produced in advance to determine the feature direction, that does not negate the need to assess the appearance.

Presentation of any UI component should always conform to consistent practice. As the platform grows, it’s important to replicate style and workflow across the system. UX designers are pivotal in establishing common design. However, in the event that a designer is not present in your team, the responsibility relies on all developers to conform to a standard.

Code style is important, but in UI the appearance and workflow of the feature must also be reviewed

Centralised components and style sheets allow you to build up reusable facilities to enforce common appearance. It is important to review style as part of any peer review. The simplest way I’ve found is to attach a snapshot to the pull request to showcase the new features appear.

While a great initial step, screenshots are limited in their capability to allow inspection of workflow, cross browser compatibility and general style. A better approach would be to have an instance spin up as part of the pre-commit build for every request. These ephemeral instances allow for developers to live test and experiment with the features to provide more targeted feedback. This is currently a dream for us, but very much an achievable one with some time investment.

Front Row

Regardless of technology, peer reviews are a vital skill for maintaining quality standards and building developer experience. I’ve outlined many of the resources and attributes I use in reviewing of others UI code. The importance is to adopt a common standard to which the team can commit.

Growing a set of UI review best practices takes time, and performing of reviews from many other reviewers

These maxims will form but the beginning of the total rule set. Our axioms will continue to grow as we receive feedback on our code from others. That includes others reviewing my own code.

There is more to reviews that hard rules too. My last, and most important advice, is to be wary of your language in comments, particularly if using commenting features in tools such as GitHub and Bitbucket. In more recent times we’ve had discussions about being clear what items will block merging and which items are optional opinions that can be discussed or actioned later. Unfortunately we have even had discussions about which comments are hurtful and derogatory too (yes really). Feedback builds better engineers. But ensure you communicate them with humanity and empathy.

Thanks so much for reading! Do let me know of any review criteria and resources that you also use for reviewing code.

Come Together

Experiences of Software Development Squad Makeup

No man is an island. It takes a village. Quotes are littered through our culture in support of working together. Be it in our personal or professional lives, we achieve more when we collaborate with others.

Much has been said on the importance of diverse teams. This includes diversification of personality and thought. Regarding role diversification, the traditional waterfall software development model encourages segregation of different functions that contribute to the development and maintenance of systems. It has always seemed like a strange model to me, that breeds division.

No longer can developers build software in isolation and ship to customers

Our Agile journey has taken a further step forward in the combining of some key functions within the Agile squads. As with many experiments, this has produced mixed results. This week I reflect on our progress of integrating various roles into one particular squads, and set my sights on future inclusive goals.

Let’s Build a Home

Developers are the cornerstone of any Agile software development team. Without their coding skills, the products we built to support our clients would be but a distant dream. It is for that reason that Software Engineers and Scrum Masters have always been part of our squads.

Having them work as an isolated team has reaped rewards. In our early Agile adoption days, all teams were delivering working software at a constant pace. Coding and testing standards are on the rise. Morale was on the up as teams achieved a steady release rate.

Developers working together in small increments did initially improve software delivery rates

This isolated model does introduce strategic challenges. The team were building strong client relationships and working across the divide to product features of value. Yet, these features became disjointed due to a lack of product ownership. Without direction from a single senior stakeholder, programmer only troops will struggle to understand the product strategy. This manifested itself for us in the delivery of features that didn’t quite hit the mark. These became the justification to push for our first addition to the squad.

Go Your Own Way

These experiences highlighted the need for an integrated Product Owner. Someone able to own the product direction. Many Agile frameworks, including Scrum, mandate that the Product Owner is always part of the squad. Yet in many organisations it proves to be difficult to sell the role. Despite practicing Scrum and Kanban for almost three years, it has only been this year that we have achieved the impossible dream of a truly dedicated Product Owner that gives true product direction.

Until this role is recognised as a legitimate and rewarding role, many other teams will fight the same battles. While awaiting someone exhibiting the desired attributes of a Product Owner, we made use of proxies. Said proxies are not nearly as effective, especially if using a Business Analyst or Product Owner in their place. I have encountered exceptions. However, the majority fail to meet expectations as they don;’t have a vested interest in the product. Instead or driving to a strategic direction, they conform to the age old man in the middle that can obfuscate the vision through indirection.

Dedicated Product Owners have the keys to drive value for their own benefit, which proxies do not

Level of engagement does indeed vary. Our greater commitment successes have had the Product Owner being present in the majority of ceremonies. Extending invites to standups and backlog reviews have proven to give better direction to developers. Yet if the reluctance is to be obliterated, it is more important to identify Product Owners available for questions if attendance to all ceremonies is not achievable.

Misery Business

Business Analysts have been a recent addition to a couple of our squads. This might sound odd as there is great differing opinions as to the value of BAs in Agile practice. Historically they have worked in isolation as either an information wall. Or as a compromising Product Owner Proxy in some of our later trials. This delegate approach proved fruitless for one crucial reason. They don’t necessarily care about the features being built. This is not intended to criticise their work. It is simply acknowledging how challenging it is to give accurate indications of priority, or answer process related questions when you have no vested interest in using the product itself.

The days of BAs writing large requirements documents are, thankfully, for the most part gone. Instead they support the Product Owner by assisting in the logging of stories and generation of behavioural acceptance criteria. That frees up our busy Product Owner to juggle prioritisation, product strategy and their day job.

We’ve found that BAs can change their focus from writing endless requirements documents to writing user stories and acceptance criteria at the direction of the PO

This engagement is proving more effective than our prior proxy model. Teams still engaging in segregation are finding that requirements clarifications are less forthcoming. Furthermore, signoff of deliverables is far more elusive as the team quite often build features that don’t quite meet the intended requirement. This breeds the common misconception that Product Owners, or indeed other stakeholders, cannot reject features they consider to be unhelpful or unsatisfactory.

No Control

One group that proves to be elusive to integration is our Quality Assurance arm. While some squads have better success integrating dedicated testers, our model of automated testers and user testing means this is not required. QA for us is more around supporting of the products we build, and integration of tooling for diagnostics.

This lack of integration poses several challenges. The main is that developers have a distinct lack of empathy for those supporting applications. Documented details of the platform infrastructure are not provided. Design of the system support mechanisms such as alerting and logging are an afterthought. The optimistic nature of developers means we need expertise in those used to failure in building our systems.

If QA colleagues are constantly working to stop a flood on legacy applications, they will struggle to support developers in the build out of scalable, supportable applications

The message that everyone is responsible for production support must be reinforced. Integrating a dedicated support agent looks to be a valid approach. Pressures on their time is the main blocker around integration. Especially when we balance support of our legacy systems that require more intervention. Global support by a co-located squad would also be difficult for one agent. The first step would be for assigning of an individual to to be available to guide developers in building supportable applications.

A Change is Gonna Come

Reflecting on our journey this far, the integrations achieved are reaping great benefits. Developers now receive feedback and clarifications on features more rapidly than before. Clients better understand the value they receive, and are empowered to prioritise the features they need, as well as understanding the reason for any hygiene the team performs.

Our successes are simply the start of our journey to integrate all required agents into all of our squads

That’s not to say that the adventure is over. Our QA engagement is another item of focus. The successes clearly can be scaled and replicated across our other sprint teams. That way we can ensure all groups come together.

Thanks for reading!

Same Size Feet

Identifying the Need for Story Splitting

We all remember our favourite childhood fairytales. Despite being significantly short, they all follow a similar format. Each story arriving at the perfect ending following the protagonist overcoming strife.

Every time I think about story splitting, I am immediately reminded of Goldielocks and the Three Bears. A young girl’s quest to find the perfect tasting porridge and unequaled chair. It’s easy to draw parallels between relative story sizing and this well-known fable.

Much like the chair in Goldielocks and the Three Bears, User Story size must also be just right

Regardless of degree of Agile maturity, the size of the stories our squads are working on and their ability to split is an ongoing issue. Different teams have different challenges. Some stories are too big. Others are too small. This week I look at how to identify issues with story sizing, and showcase possible mechanisms to help identify when to break them down to a size that is just right.

Shapes and Sizes

The primary manifestation of poor splitting is a large variation in the size of stories on the backlog. Most squads in our area have significant stories in their backlog, intermingled with small single point defects. One team is better than most at creating smaller stories. Even then, their range can massively fluctuate.

Having large variance in story sizing makes it diffcult to track velocity and compare stories for future estimation

tions across these teams. We cannot compare their velocity. Despite management objections, we push to prevent comparison across teams. The relative comparison of story points should be across a single squad. It is the responsibility of each individual Scrum team to regulate story size, and split as they see fit.

It’s Only Rock and Roll

A secondary symptom we have encountered is regular rollover. Large infrastructure upgrades on a legacy system have been a key example in our space. Having a single story was not viable for several reasons. Legacy systems are often poorly documented, making identification of dependencies difficult. Larger systems also require significant work to upgrade as well.

There has been significant debate on the maximum size. Concerns are that splitting the story may mean the value is lost. Regardless, the majority agree that a story must be small enough to achieve in a single sprint. This item was not, and therefore needed to be broken down.

Stories regularly rolling over across sprints suggests it is not well understood, and potentially that it is a larger story that must be split

Our initial approach to break the story by each environment still resulted in rollover. As the work progressed, more undocumented components required upgrade. More legacy technologies required remediation. Hindsight teaches us that had we been able to isolate each component for upgrade, along with the at risk processes, each story could have been smaller and manageable. Their value would also have been easier to communicate to clients, and the resulting progress would have been more transparent.

Blue Condition

Another warning sign that I’ve recently encountered is the length of the acceptance criteria associated with a given story. As part of our increased collaboration with BAs and our engaged PO, a larger amount of detail will accompany each story.

This degree of collaboration has proven to be a double edged sword. Having greater engagement means we are getting more clarifications of user needs and product strategy. We obtain behavioural scenarios as acceptance criteria. However we still receive large sets of bullet points as additional acceptance criteria. While developers strive to meet the full criteria, in the ever changing criteria items are often missed, leading to defects being raised later.

Developers are regularly bamboozled and trapped by the sheer amount of acceptance criteria that underpins our stories

This has got me thinking of the old tactile approach of using index cards for our stories. Despite the numerous benefits, a side-effect of using automated tools such as Jira and Trello is that we cannot regulate the amount of detail using the size of the index card. Be mindful of the amount of criteria specified for any given story. Consider using our current rule of thumb, where if the criteria won’t fit on a single side of an index card, your story needs to be split.

Price Tag

Where we struggle to split using the above indicators, our ability to break down and estimate the story is our final mechanism to verify a story is not too big. As simple as it sounds, if we cannot comprehend how to break it down, or the story decomposes into a large number of sub tasks, it’s time to split the story down. Our prior rollover example certainly was partially caused by being unable to estimate the original story.

If we cannot understand or estimate a story, it’s most likely too big for the team and must be split

The above symptoms are classic manifestations of too big stories. The next question on our lips is what techniques can we use to break stories down. My research has identified several approaches to help without efforts. Initial thoughts are that the generic words and acceptance criteria approaches are particularly useful. Only time, and a future post, will tell how effective these techniques prove to be.

Thanks for reading!

The Show

Why Reviews Are More Than Just Demos

Theatre showcases are a opportunity for drama students to present a piece demonstrating their developing talents. Treading the boards to show their progress. The parallels to sprint reviews are many. Think of the squad showcasing their progress on building software to an audience of eager critics.

The sprint review is intended to showcase the accomplishments of a sprint. Arguably it should be used to highlight failures and learning outcomes as well. These days we are fortunate to have built increased engagement with our clients. Specifically, we finally have a dedicated and passionate Product Owner who has built strong interest in the product in-progress. With that we have seen that the same old sprint demo format needs some polishing.

This week the spotlight has been on our sprint review ceremonies, and how to make them more effective in eliciting feedback

Recently our team has been reflecting on our sprint review processes. More specifically, I’ve been asking myself one simple question. Can a sprint review be more than a demo? This week I look back over our review roaming, and contemplate the lessons I’ve learned on this turbulent trip.

Start the Show

The early days of our agile adoption were a buzz of activity as we adjusted to this new way of working. Enthusiasm among developers and users alike was infectious. Every two weeks we would have strong attendance to showcase multiple deliverables across numerous products. This new level of engagement did wonders for engineer morale, as their contributions were regularly recognised.

Following any dizzying high, there follows a devastating low. Over time attendance began to dwindle. Frequency of demo sessions began to drop. Feedback on new features was not forthcoming. Developers were left questioning the value of the features they built. It was definitely quite a fall.

See You at the Show

To rebuild the review revelry, we must undertake a postmortem to identify the cause of death. Part of the problem boils down to squad behaviour. One bad habit was the team cancelling reviews when they didn’t have a complete feature to showcase. Perhaps the competitive culture in which we strive to succeed encourages us to hide failures offstage. Encourage a spotlight to shine on both successes and failures to build up feelings of accountability.

Lack of preparation for demos is another cause. Developers quite often prepare a non-production environment to showcase, or mock up messages to present ticking data. Yet, they don’t memorise their script, or plan how to best present the feature. Presenters must strike the balance between winging it and over-preparing to ensure they can cover all aspects of what was achieved, as well as field the unexpected questions.

The entire team must prepare for a demo to ensure we are singing off the same song sheet

Stakeholders also have a part to play in the demo demise. Not all clients want to see all features. In our case, key users were only interested in enhancements to the products they used to conduct their daily business. Supervisors however were curious about all products generally. The lesson here is to consider your audience carefully. Distinguish between mandatory and optional audiences in any invites.

The final cause for disengagement could be a lack of context. With rewrites this can be more prominent, but I have seen the same effect on new products. A single small feature does demonstrate the incremental value we are delivering. However, clients often need to see the road we have travelled, and what lies ahead to validate we are heading in the right direction.

Don’t Stop the Show

Such issues have plagued our reviews over the past year. These are indeed fixable with preparation and mixing up the format, as we shall see in the final act. What requires more work is the changing of engineering attitudes. Technologists will always attempt to justify why their work should not be shown. The wording here is purposeful as we must consider software and infrastructure based projects in this argument.

I often hear that although work X was completed, that it is not possible to demo. Reasons for this belief are varied. In the software world, any enhancement without a UI is considered impossible to showcase. In infrastructure circles, the effort to build a functioning environment often outweigh the benefit of demonstrating the benefit.

Feedback should be gathered for all enhancements, even if they are considered to have a supporting role

These reasons highlight that the time is right to get creative, and choose the appropriate medium to showcase our work. It is true that presenting working software is a very effective mechanism. But this format is not always the right call. Perhaps it’s automated testing, message passing, diagrams. Something that shows why what was built is important and useful. If you enforce this way of thinking, the sole argument for not showing off an enhancement is then a question of business value.

The Show Must Go On

With the aforementioned concerns alleviated, technologists can no longer justify not showcasing what they’ve built. The review feedback loop is vital, regardless of the Agile paradigm practised. Rather than calling time, it should be taken as an opportunity to consider a different format. Application of experimentation and continuous improvement applies to the entire process, including reviews.

The latest and greatest feature doesn’t have to be the only item showcased. Recall one of our key issues with clients questioning where this new feature fits in their process. When clients continually ask what’s coming next, they are not providing the team with feedback on the product.

Stakeholders are always looking forward to see what will happen next

To elicit constructive commentary, we are starting to use additional artefacts. The product roadmap is the perfect tool for discussing the route we are travelling, and providing context on where we are, as well as our current direction. By-products of any analysis or design thinking stages such as wireframes and flow diagrams can be useful active mediums in conveying the value produced over the current cycle. With many methods available for reviews, it is vital for us to plan in advance with the product owner to ensure an effective feedback process.

Thanks for reading!