Women working in tech

Emilia Trendafilova

Emilia

Women in tech? We need far more!

There are an increasing number of us in the tech and digital sector, but it stubbornly remains a male-dominated industry. Asked to picture a software developer working away at a busy desk and the vast majority of our population would still envisage a man in front of a screen and not a woman.

Things are changing – but not nearly quickly enough.

Like many other women in tech, my journey into the sector began at an early age. I was always far more interested and intrigued by what were seen as boys’ toys, and not ‘traditional’ girls’ toys. So I was also found playing with toy cars or Lego rather than dolls or prams.

When I was about seven, I saw my dad playing what I thought was a really cool PC game called Doom (not so impressive now, but back then it certainly was!)

I wasn’t just interested in the game and watching my dad play, I was interested in the amazing technology behind Doom and other computer games. I wanted to understand the technology that could be used by millions of people – like my dad – around the world.

I suppose my interest was inevitable as both my parents were software engineers so I was quite used to tech talk, and I shared their passion for computers from a very early age.

I suppose my mum was a particular inspiration and I could see no barriers to women working in the tech sector as that’s exactly what she was doing.

It was no surprise to either my mum or dad that when I graduated from school I decided that I wanted to study computer-related subjects for my higher education at college in Sofia, Bulgaria.

And that is how I’ve found myself in Newcastle-Upon-Tyne.

I studied a BSc (Hons) in Computer and Networking Technologies at Northumbria University, where men made up a very large proportion of my classes. I found this quite surprising as because of my background and upbringing, I’d just never considered the possibility that studying any form of technology was a male subject – AND IT ISN’T!

Later, when I studied an MSc in Cloud Computing at another University I was the only woman in my class.

In those years of study, I learned alongside some fantastic people. However, on occasion there were opinions shared in my presence such as, “some women struggle to reach the required standard in technology” and that “women can get preferential treatment and achieve things easier for being a minority in the sector”. In reality, neither of these were true and I was keen to demonstrate the exact opposite of this.

I am now working at a well-respected and admired tech company, one of the best in the region so I KNOW I am good enough – and so do my colleagues. And during my studying, rather than getting preferential treatment, I knew I just had to work hard in order to prove to myself and to others that I did have a future in tech.

Sadly, I know a lot of women have had difficulties entering our profession and many intelligent, bright and ambitious women will have chosen not to work in the sector, scared of the possible reaction from their male colleagues.

What we need is more women role models. Women who are good at their job in the tech sector and are respected by their colleagues. Women who will be the living proof that a career in technology is not just for men, and that ability is the only thing that matters.

Technology is about the future – and that future should be one which will never discriminate or show any sign of gender bias. There have been positive changes, but we must all do more.

Remote research: the positives and the caveats

Miriam Boyles

IMG-20191231-WA0013_2

Introduction

Remote research encompasses a range of methods and practices, and, whatever the project, we can almost always find a remote method which gathers enough insight to inform decisions and drive a project forward. While COVID-19 is currently putting an unprecedented demand upon remote communication, remote research has been successfully applied since the technology for remote communication have been available to us.

In this article, I explore how remote methods help you to build rapport with participants, identify needs, pain points and delights, and gain an intimate understanding of people’s experience. However, I would not be a thorough researcher if I didn’t also identify the limitations to only conducting research remotely. I also highlight how, in particular circumstances, observational and contextual research have no real substitute.

Remote research: The positives and possibilities

Usability testing and interviews are two core methods employed by user researchers and are regularly conducted using phone and screensharing technology. As the Service Design and User Research Lead on my current client project, I have been conducting remote interviews and usability tests with users of the existing product we’re seeking to improve

This research didn’t come without challenges: communicating in the inconvenient circumstances of coronavirus lockdown from our respective homes, we experienced the additional disturbance of loud DIY from my neighbour above, and some participants’ inability to screenshare. Despite such disruptions, however, these sessions have allowed our team to confidently identify user needs and pain points, gather valuable feedback on our prototype, challenge some assumptions, have in-depth discussions about the findings, and populate our backlog with tasks for future sprints.

This is just one of many examples where I have used remote usability testing or interviews to gather valuable information. Others include: telephone interviews with customers of the Financial Service Compensation Scheme for their Service Design Project; usability testing with customers of a government financial compliance service, preparing the service for its Live Beta GDS assessment; mapping the diagnostic and management pathway for patients with Lewy Body Dementia for Newcastle University through telephone interviews with clinicians of different services.

It is often stated in-person is better than remote, but I have found video conferencing and the telephone both generate an immediacy that can in some ways be considered better, rather than worse, for establishing a rapport with participants. This is not always the case but in my 10 years as a researcher I have been surprised to learn people are often more open and candid during telephone interviews than in-person, perhaps because they feel less self-conscious and more in control. (They can leave whenever they like!).

Some research methods are remote-by-default rather than an alternative for when in-person or contextual research isn’t an option. These include diary studies and surveys, both of which are purposely designed to gather information without a researcher needing to be present. A diary study is a great way to access information about the ‘day-to-day’ of people’s lives.

Inspired by the uniqueness of the times we’re living in during the coronavirus pandemic, I decided to conduct a diary study with people across the world living in lockdown. Over three consecutive days people replied to a set of question over email, telling me what they had done that day, who they spoke to, their highlights and low points. People were candid and reflective, telling me about their worries, the importance of social connection, the things they missed, the new things they were appreciating. I then had telephone interviews with participants, asking questions framed around their diary entries. I’m excited to now be making a podcast from this material!

Remote research: the caveats

Remote research doesn’t come without its downsides and limitations. For one thing, the reliance on technology for a lot of remote research means your sessions are put at risk by technological failure. With remote you can easily lose internet connection or experience some other technological failure that interrupts the session completely.

Nevertheless, these tend to take the form of technical hitches that prevent the research process from feeling seamless rather than preventing research happening at all. Having a ‘Plan B’ can ensure you still get value from the session: I prepare an interview script in case a participant can’t access a prototype for usability testing and ring people if the internet goes down.

In many cases, remote research does enough to gather the insight you need to make informed decisions about the direction of your product or service. However, particularly at the discovery stage, or for a service design project where you want to fully understand a context and its people, remote methods cannot substitute observational and contextual methods for their capacity to generate a lot of in-depth information. These methods include participant observation, shadowing, contextual usability testing, contextual interviewing. Observational methods allow the researcher to notice things their participants would not directly share: things that are tacit, assumed and go unspoken. Behaviour, values, culture, context, process and relationships are all difficult for people to articulate.

Another important limitation is that in some instances certain kinds of remote research are not suitable for accessing certain users. Some people may not have the technological confidence or ability to access your prototype and screenshare, they may not have a good/any Wi-Fi connection or have access to a home computer or smartphone. To make sure you design for all users, and not just the tech savvy, we need to reserve time to reach users in a way that works for them. A semi-structured telephone interview is often a valid option.

Finally, many of us by now will have experienced the difficulty of talking with friends, family and colleagues in group meetings on apps like Zoom, Houseparty, and WhatsApp video. In such communication platforms people accidentally talk over each other, the sound or image quality is often poor, and they tend to favour extroverted people whose voice can be heard above the echoes and distortions caused by a poor connection. This illustrates how difficult it can be to conduct a remote focus group or the remote equivalent of a workshop which involves group practical activity. At the moment we are reliant on the tools and technology improving before remote group research becomes a strong option.

Conclusion

Choosing your methods should always be a response to the research questions you’re trying to answer and the conditions you are attempting to answer them in, with COVID-19 being a uniquely relevant current set of conditions. This article has explored how remote research can be powerful, useful and more than sufficient for generating the insights a team needs to move a project forward. However, for an in-depth and more subtle understanding, observing behaviour in its natural context cannot be replaced.

WFH: make it work for you

Mark Robinson

OC-47-square-resized

Years ago, before WFH even became an acronym, I was employed by a small technology company where everyone worked from home, apart from when we had to make necessary business trips to see clients. So home-working due to the arrival of the Coronavirus and the need to help prevent its spread is nothing new to me. Of course, in those days the technology was not what it is now. Communication was generally by phone, so we all had unlimited call packages with our respective phone companies, and we had to remember to finish and redial if the call lasted longer than an hour in order to avoid additional charges. Skype was a revelation when it arrived. Document sharing meant emailing changes back and forth and testing required the developer to email the code (zipped so Outlook wouldn’t quarantine it) to the tester…

My experience of working from home – or let’s call it WFH and bring me into the 2010’s – was largely positive. I was pretty disciplined and didn’t let myself get distracted, so I was productive. At the time my children were small so being able to be flexible about my working hours meant that I was usually available for the school run, sports days and school fairs, so I was lucky to be able to enjoy those. Not something that’s an advantage at the moment with the school closures of course…

My business trips were invariably long distance, either by train or plane, hence we were able to get by with just one car. In theory this meant we could save some money, but in practice we just bought a more expensive car. The lack of a daily commute effectively provided an extra hour a day, which I spread evenly between extra work or play time.

I became very friendly with the postman and delivery drivers once they realised there was almost always someone in our house, which is why we get excellent service from them to this day – one in particular will still redeliver almost any time we like. Of course, at busy times like Christmas our porch was full of other people’s parcels, but that did mean we got to know our neighbours a lot better too. And learn that some of them thought it entirely reasonable that you store their package for a week or so.

I recall feeling somewhat isolated at times, and I was fortunate to have my family in the house with me when I needed some human contact – though admittedly it’s hard to bounce ideas on the best way to model the cells in a  demo mobile network off a four-year old who really wants you to build him a train track.

The lack of face-to-face contact was a struggle occasionally, though of course today’s video conferencing through apps such as Teams does mitigate that in the main. However, nothing replaces being able to park yourself by someone’s desk and demand their attention; when remote it’s too easy to ignore emails or chat messages! You also miss out on those office conversations you overhear and become part of that can spark a great idea or help solve the problem you or a colleague has been fretting over.

Discipline is very important too. By that I mean disciplining ourselves to stop work, rather than falling into the trap of checking emails, replying to chat messages and finishing tasks off that if we were working in an office we’d probably leave and come back to the next day. And even with my almost fifteen years prior experience, I still catch myself doing that this time around.

So try and make the most of these strange times we’re living through, use the available technology to stay in contact and don’t be afraid to admit it can be difficult sometimes. I look foward to a face-to-face chat in the pub one day…

Mastering the basics

Tam Mageean

TamB&W

The root cause of a lot of adolescent Agile issues spur from exceptions that teams make in the values and principles in order to better accommodate conventional ways of working.

Common examples include:

  • Waiving the need for a dedicated Scrum Master/Product owner in Scrum
  • Creep of exceptions to the definition of done
  • Removing structured points of collaboration (ie standups, retrospectives)
  • Introducing dependencies external to the team

The reasons behind allowing these problem-causing exceptions are often “it is what it is” instances – “we had to do that because that’s just how our business works”, “we aren’t a typical Agile implementation” etc.

The belief that a team or business is unique and therefore unable to adhere to all of the Agile values and principles is more-often the norm. There’s nothing wrong for wanting to tailor their implementation. However, the ways in which people modify and when they choose to do so are the source of the issues.

Every business, team and service is a little bit different, so it’s not surprising working in an Agile way isn’t ever a one-size-fits-all solution. Furthermore, in this age of “scrumdamentalism” and other rigid “dark agile” methodologies, we’re seeing more and more reasons why treating the manifesto and the scrum guide as gospel could cause more harm than good.

Most experienced agilists will likely agree with your want to customise. After all, it wouldn’t be “Agile” to have a framework with a fixed means of implementation. Allowances can be a sign of a mature team and can boost team performance if done correctly.

So, how do you make exceptions to your implementation without them becoming the cause of your problems? The best thing you can arm yourself with is, in true Agile fashion, is an awareness of where you are and where you want to be.

When you take a look at skill acquisition paths like Shu-Ha-Ri and the Dreyfus model, they share similar steps.

  1. Start with adhering closely to rules, followed by
  2. Learn to adapt and apply situational awareness.
  3. Apply your own rules based on experience, learned behaviours and awareness.

These models reinforce tailoring is necessary for progression. The difference, however, is exceptions are applied as a result of proven experience, not on assumptions that have been informed by years of working incorrectly. In Agile, this is where the importance of empiricism comes into play and where exception-makers stumble.

We learn our way forward in Agile. Making exceptions for fear of things not working, rather than with empirical evidence that they don’t work is a regular tripping point. When this happens, not only does it show that the exceptions are fallible, but it also shows there is still a need for a more competent understanding of the Agile values overall. At this point it’s recommended to go back to the basics and see if you can apply your learnings differently.

Until the values and principles are truly internalised (such as knowing the need for empiricism and improvement through retrospection when making changes), there’s enough evidence to show the team is still not at a point where it’s ready to jump into the much tougher realms of exceptions and custom, post-agile approaches.

For example – until you understand why you estimate, there’s no need to experiment with the concept of “no estimates”. That lack of understanding will become both a pitfall and a roadblock in your recovery from an inevitable failure.

Start with the fundamentals and aim to master them. Only then have you created a safe environment to experiment and adapt with any substance. At the very least, you’ll always have those basics to fall back on.

How one scrum team reached and maintained the ideal burndown line

Robin Moore

Robin

There is a general question in Scrum circles about how closely it is reasonable to expect a scrum team to adhere to the ideal line on a burndown chart during a development sprint.

Here we take a look at what a specific, Opencast-led scrum team, in a specific set of circumstances did to move from having a volatile burndown chart to one that fairly closely and consistently tracked the ideal line in just a few sprints.

For clarity, in Scrum a burndown chart is a graph used to track the progress of a team of software developers during a development cycle or sprint.  The vertical access on the left shows estimate of the amount of work a team has committed to complete during that sprint and the horizontal axis depicts the number of days available in that sprint.

The ideal line is a line starting from the top left of the graph and moving down towards the bottom right.  It plots work completed by the team in equal daily increments until all the work is completed, exactly at the end of the sprint.

How closely teams adhere to this line can be used to identify and manage project risk early, but can also be seen as a measure of how effective a scrum team is in terms of estimating the amount of work to be done and their capacity to deliver it, in uncertain and complex situations.

A key Scrum principle is that software development teams improve by inspecting what they are doing and adapting what they do, to improve their predictability and productivity, in terms of delivering valuable working software.  The main mechanisms they use to do this are the sprint retrospective, where they identify areas for improvement, and the actions they agree to implement in the next sprint, to capitalise on those opportunities.

What type of improvements were made?

To keep things simple, we looked at the number and types of improvement actions the team agreed to implement over a 10-sprint period.  We then looked at the changes to the burn down chart and team velocity (amount of work done in each sprint).  They fell into four categories, with 77% being things that the team were in control of themselves, their ways of working.

no of improvements

Direction & stakeholder engagement improvements

Stakeholder direction was clear at a roadmap level and we worked with them to agree the concept of a single front door to the scrum team.  This was to avoid stakeholders going direct to developers to ask for specific work to be done outside the roadmap or challenge team estimates. We also agreed the principles that the scrum team has ownership of what they would commit to in a sprint and the sprint backlog.

Office facility improvement

The office environment and facilities were challenging, and the team needed basics like functioning Wi-Fi, a large screen TV to allow mobbing, and we also provided a coffee machine.

Development tool improvements

There were challenges around the build pipeline and not having access rights to different environments were identified as problems. Although some of these issues were addressed, many had to be lived with and it was accepted these would be a drain on the team’s resources over time.

Ways of working improvements

The team initially used the mobbing technique do develop software. This helped them to learn the new technologies together, share their different skills sets and bond as a team.  Over the course of 10 sprints the team made lots of small improvements in the way they worked which ultimately did have an impact on their productivity and predictability. The areas improved included:

  • Communicating concerns around the size of the team to ensure it was understood that bringing in more developers would likely slow the team down.
  • Morning stand-ups initially took too long to go around the whole team. Also, on Fridays the team was dispersed meaning we had to do the stand up over a voice only Skype call. A couple of useful improvements were: the daily time taken doing stand-up was cut in half by walking the scrum board rather than going around the individuals.  Friday Skype calls were replaced by; doing Friday stand ups on Slack, which was both quicker, more easily understood and more enjoyable.
  • New definitions of ready and done were created by the new team.
  • The approach to story development and elaboration underwent 5 or 6 improvement iterations over the sprints. This helped improve engagement within the team.  Engagement between, developers and testers were further improved by changing seating arrangements and ensuring they discussed bugs before raising them on Jira and the physical scrum board.
  • Noise levels were identified as an issue for developer concentration, affecting productivity, because the office was fairly busy with a large scrum team and stakeholders. A number of approaches were iterated to improve this over time.
  • Improved engagement between the two teams working on the same code base was achieved by attending each other’s daily stand ups, ensuring development was aligned.

When were improvements identified?

Initially a broad mix of improvement opportunities were identified but once these were addressed the majority of improvements were achieved by making changes to the way the team worked and engaged.

improvements2

What impact did the improvements have on productivity?

improvement3

Velocity improved quickly by clearing the environmental impediments. There was a peak around sprint six, where the team worked outside normal timeboxed sprint to hit a hard deadline.  It took a couple of sprints for the team to recover from this, as can be seen by a dip in productivity, however the overall improvement trajectory continued.

What impact did the improvements have on predictability?

 The first 3 sprints

The highest variety in terms of action type and volume of improvement opportunities were identified here.  The burndown charts were fairly volatile with a number of environmental factors slowing the team and blocking developed code from being deployed.

improvement4

improvement5

improvement6

The next 4 sprints

A fewer number of actions issues focused on fewer types of improvement that the team could control.  It can be seen that the burndown charts are less volatile and moving closer to the ideal burndown line.

sprint1

sprint 2

sprint3

sprint4

The Final 3 sprints

Only a slight decrease in the number of improvement actions but the team tracks much more closely to the ideal line – less volatile and therefore much more predictable.

final1

final2

final3

Conclusion

Clearly a development team needs to have decent relationships with their stakeholders, a functioning office and a reasonable set of development tools in order to be able to deliver working software, but once these are achieved to a workable level, improvements in productivity and predictability would appear to be in the team’s own gift through identifying and making improvements to the way they engage with each other and their approach to development.

So what is a Technical Lead anyway?

Snip20200129_1

What’s the difference between a Technical Lead and other developers? It’s not just about the years of experience. Some people will never learn the skills they need to become Leads, or are more interested in becoming technical specialists in one area. Some developers will show their aptitude from the start. So what makes someone a good Lead?

It’s not necessarily about technical knowledge

Is someone a Lead because they know more Java patterns than you? Because they are know what a Monad is? Not necessarily. The Technical Lead does not need to be the developer with most experience in the technology stack you’re working with right now. A junior developer with a year’s experience may have spent that time immersed in a single JavaScript framework and have the best knowledge on the team of its peculiarities of syntax and usage.

But it can be about bringing their experience to bear…

A good Lead will be looking at things more broadly. Using the example of the JavaScript framework above, a lead will be more concerned with the following:

  • How does this framework fit with the rest of the architecture?
  • How do we share that developer’s experience with the rest of the team so that we eliminate the single point of failure that exists due to that key individual?
  • Can we write good tests for this code?

A Lead Developer will have spent years working with different technologies and approaches. This experience can be the key to being able to know how to ask the right questions, and then to take the correct actions based on those questions.

…and applying best practice

A Technical Lead knows that they won’t be spending all of their time coding, in fact they’ll spend less time than any other developer in the team and, when they do, it will be as part of a pair or in a mob – it should be rare to see a Lead typing alone with headphones on. Instead they’ll be spending their time trying to bring best practice to the whole development team – TDD, pairing, code review, running automated tests, monitoring builds and deployments and in general ensuring that if they were to leave tomorrow then team would be in a better position than before they joined. They’ll also be spending time making sure they know what best practice is – attending developer communities, having conversations about upcoming changes on Slack and doing research on advantageous new technology.

Think of the development team as an orchestra – the Tech Lead is not the solo lead violinist, they’re the conductor. They make sure the whole team works harmoniously to produce the final result.

Picture 1

Characteristics of good and bad Leads

In the course of my career I’ve met a wide variety of lead developers. While they have exhibited a diverse set of personalities there are certain characteristics I have seen that can make teams successful and happy, or conversely an immensely frustrating and dysfunctional experience.

 

Bad Leads

  • Think they know it all
  • Don’t listen to more junior staff
  • Sit and code all day
  • Don’t make themselves available
  • Don’t know what’s going on in their team
  • Take on all the complicated tasks themselves

Good Leads

  • Spend a substantial part of their day away from coding
  • Pair with and mentor other developers
  • Keep learning and are prepared to take advice from anyone
  • Make themselves open and available
  • Know what they don’t know
  • Know when to delegate

Picture 2

Still want to be a Lead?

Not everyone wants to lead a team. Many developers become contractors because they are more interested in broadening their technical experience and want to spend as much time as possible solving technical problems. But being a Lead Developer can be immensely satisfying for those who want to have an influence on the software development process and who want to help other team members to improve their skills and experience.

The skills you learn as a Lead can help you progress in your career as well – learning the fundamentals of Software Architecture, understanding approaches to Testing, Continuous Delivery and Agile Development can lead to other roles within the industry. Make sure you stay open to new ideas, listen to your peers and remember, no matter how senior you are, you should always keep learning.

At Opencast Software we’re always looking for good Leads, alongside strong developers and automated testers. Why not get in touch via https://opencastsoftware.com/careers/ ?

Using ML to improve alerting systems

Andy
ALERTING systems are an important tool for IT support teams. These teams are often responsible for maintaining and fixing services, so they need to be informed in a timely manner of any faults in order to keep services running at peak performance.

Traditionally, alerting systems consist of simple threshold-based anomaly detection processes, where the threshold value is manually set by the team. For example, the error count for each service is calculated over rolling time periods (say, five minutes) and if this count is greater, than or equal to, the threshold value then the team is alerted.

The main benefit of this approach is it enables the support team to have a degree of control over the alerting process (e.g. adjusting the thresholds according to planned activity). However, there are a couple of drawbacks:

  • The threshold is static – it is the same value every day and every time, which may not be true of user activity;
  • Low thresholds – usually chosen for services with lower user activity, they tend to alert on noise, or when there is an atypical burst of activity, as opposed to symptoms of a faulty service.

We decided to test a theory that Machine Learning could circumvent these drawbacks. An innovation project set up by the team prototyped an alerting system that dynamically and automatically determines if there is a genuine fault within the services.

Fundamental to the prototype is a predictive analysis tool that, for any given rolling 15-minute period, determines if the number of errors is typical or atypical.

It achieves this using statistical formulae to benchmark the real time error count value against historic data for that same 15-minute time period. Then, if the number of errors is atypical, the prototype computes if this is or isn’t noise. It achieves this by comparing the ratio of healthy calls to error calls in this 15-minute period.

Thus the prototype only alerts on a service if both the number of errors is atypical for the time period, and the error count is not the consequence of noise. In this way, the alerting of a service is controlled by an automated, unsupervised machine learning algorithm.

To determine if machine learning can improve the alerting process, we tested the effectiveness of this prototype by comparing it to a traditional alerting system over a period of 14 days, for a single service and a single type of error.

Fortunately, this was a period where there was a lot of alerting activity on this service. The traditional service alerted on 32 separate occasions. In contrast, the prototype alerted on only four occasions (these overlapped with four of the 32 occasions when the traditional system alerted).

Clearly, the prototype has the potential to reduce the number of alerts but is it missing any genuine system faults that the traditional system is alerting on? The team found the answer to this was ‘no.’ This answer was arrived at by comparing the ratio of healthy calls to error calls for each alerting period.

In the periods alerted by the traditional system, this percentage of unhealthy to healthy was consistently less than 0.5% , with a maximum of 2.93%. In contrast, in the periods alerted by both, this percentage was 50.2% at its lowest.

In conclusion, the prototype empirically demonstrates there is the potential for machine learning to seriously improve traditional alerting systems. Although this is good news, there are many other issues to consider in order to improve the prototype further. These include collecting more suitable historical data and improving the predictive analysis model.

Let us know if you’ve had any interesting findings or how you’ve used ML to improve service performance.

Andy.