Joining a company during lockdown can be surreal, but needn’t be painful!

Paul Crisp

Paul Crisp Blog

My entire interview cycle and subsequent joining process with Opencast as an Architect fell during the height of the lockdown restrictions. After a month my head is still spinning but I am able to take stock.

I have now met some of my colleagues in a socially-distanced meeting in a secret location (Haylofts new business centre on St Thomas’s Street, Newcastle. Very handy for Eldon Sq, Haymarket bus station and Newcastle University). However, I’m yet to meet most of my colleagues face to face.

Opencast famously has a very friendly culture, built around the offices in Hoults Yard which I’ve not properly been to yet. I only knew one person at Opencast and although I’ve worked from home a fair bit over the years, have never done so exclusively. So it could have been a very unsettling experience – but it hasn’t been.

The company culture is the overriding reason – Jim the office manager made a point of meeting me to give me my laptop and company handbooks in person. He could have couriered them, and it meant a lot.

The IT all works. It’s amazing how often that isn’t the case. Mike, one of the company co-founders, lives near me and arranged to meet on a park bench with two flasks of coffee, one each, just to say hello. This was an experience we both likened to a drug deal or possibly a scene from a sitcom.

The company message boards are also full of jokes, Spotify playlists, erudite discussions, rather less erudite discussions, memes and more jokes. There are quizzes and a regular Friday evening online get together. I was invited to introduce myself online and I’ve been made very welcome. I’ve also been lucky to be given a work stream to look at which means I get to talk to lots of colleagues about what they do.

Much of the company culture stems from the North East of course. So many clichés about the region are true – hard work, mutual reliance and mutual respect, and an almost pathological friendliness are built in. I’ve been here for 20 years so they weren’t  a surprise, but we must never, ever take them for granted. I’ve had quite a long career in many different parts of the UK and it’s definitely not universal. The friendliness has gone up a notch too with the company being so successful, but also with the strange intimacy that comes from the whole organisation working from home. Children, dogs, cats, partners, ‘rellies’ can be seen wandering in and out of the background of calls sometimes, and there is always the fact that you really have been invited into somebody’s home. 

It’s still a new job in an organisation seemingly jammed to the rafters with extremely clever people, and I am keen to get stuck in and prove my worth, but the profound weirdness of the situation has been strangely muted. I’m both grateful and impressed

On reflection…

Bill Robinson

Screenshot 2020-07-16 at 10.18.38

32 years ago I started work for South Tyneside council as a Junior Programmer. 

One of the first requirements was to provide some data analysis for a councillor’s question highlighting ward by ward winners/losers as a result of the new council tax that was being rolled out in England (after being  so warmly received in Scotland). 

He was very keen to get the figures and was delighted to note that the richer (conservative wards – yes, they do have a couple in South Tyneside), were firmly the winners. 

I realised whilst we discussed the work that there was a bug in the logic which meant a fix and rerun was required. However, the councillor didn’t feel this was necessary, so we left it at that. 

Next day front page of the Shields Gazette contained the headline “Tories council tax windfall”  (sic) with a table of figures that looks exactly the same as my dodgy analysis from the day before. 

Thus began a lifetime of learning how to do IT right  – by making mistakes…. 

In recent years it’s been great to see our industry make tremendous improvements in the delivery of digital and technological solutions for our business and clients. I’ve heard many people state that there has never been a better time than now to be in IT and I agree. 

So, why am I packing it all in? 

I absolutely love my job, love working with data, getting the quality right, getting the performance right, sharing and learning from colleagues. 

But I also love being outdoors, finding the universe in a blade of grass or a rock pool. I love cycling, walking in the hills, sea kayaking, planting trees. I want to learn to grow food, live small, campaign on social issues. 

I’m incredibly fortunate to be able to do so. My final and best employer has supported my transition to a new way of life by enabling a career break two years ago so we could road test our ideas of living small. They subsequently supported four day working on my return. 

I know that Opencast will continue to flourish – there’s something amazing happening almost every week within it.  I’ll keep a careful eye out for more of the deserved success that the people working here will inevitably have.  

So after 32 years of making mistakes am I about to make another?  Who knows? I can’t wait to find out. We’ve escaped up to Scotland to enjoy this next exciting step in our lives.   Slàinte mhath! 

How are you coping in lockdown?

Sheena Widdowfield

Screenshot 2020-06-24 at 11.31.17

 

Since going into lockdown, a big concern for many companies has been ‘how can we look after everyone in this new environment?’ I shared that concern, wondering how we would possibly know everyone was okay and our people were setup for success.

The first week of lockdown was a whirlwind across the management team. Making sure everyone in the company could work from home with their equipment; managing client expectations; checking how we could support people with children and other commitments and trying to predict the future on what this meant for the short to medium term for the company. Meanwhile, our consultants kept calm and carried on, providing their usual exemplary service to our clients.

I have to admit I was apprehensive about the whole approach in the beginning. This was mainly because having our whole workforce working from home was not something we’d ever tackled before. But when I think about it practically, and with the benefit of hindsight, I needn’t have worried in the slightest.

On reflection, we’ve been working remotely for years and we’ve done it exceptionally well. As consultants, we have nearly a hundred people across at least five different sites, meaning we should be used to this setting of contacting colleagues over email and MS Teams. And it turns out we are.

In my role looking after Learning and Culture, I’ve found the need to be more creative with my approach. For learning, I’ve sourced online accreditations, virtual conferences and free online courses that you would usually have to pay for.

In the early days of lockdown there was a temptation to put learning and development on hold, “until we get back to normal.” However, we really don’t know when that will be and what it will look like. So instead of delaying, we’ve kept adapting.

From a cultural perspective, my main focus has been bringing people together as much as possible through virtual socials and common interests, being completely transparent in communications about the progress of the business and any ongoing impacts of COVID-19. Our whole team have made a point of generally checking in with people to ensure they are okay with their work and, importantly, their wellbeing. We have a unique culture at Opencast and I wanted to ensure we maintained that, despite the circumstances. In addition, we have onboarded a number of new people to the business during this period. For them in particular we have taken extra efforts to make sure they feel included and engaged.

While the COVID-19 outbreak has been a worldwide tragedy of epic proportions, I notice people being kinder, more compassionate and more understanding of each other’s differing situations. More so than ever before. People live in so many different environments: some live alone, some with parents, some with small children, some in flats with no garden and some with housemates where there is nowhere private to work. Having that context can help you understand how someone may struggle with the pandemic and its ramifications more than others.

Sometimes we have conference calls and a child is being fed off camera – a parent feeding their child with their left hand while making notes with their right. Somebody is dialled into a meeting while they’re walking by the river, giving their dog a walk and getting some much-needed fresh air after spending most the day inside. A piece of work can be completed on an evening when the children are in bed and the deliverable can get the attention it needs.

Humanity has taken a shift, and it’s wonderful to see. We get paid to work and create a value output. If we’re delivering that output, does it matter whether we do it from our sofa, our garden, first thing on a morning or last thing at night? We’ve seen a huge cultural shift in our company, our industry and across the world. It’s enlightening to see, and let’s hope this is something we manage to hold on to in the rush to get things back to how they were.

What tech means to me, a non-techy

Louise Barker

louise

Before starting in recruitment, I had worked as a bartender and had pranced around on stage during my Drama and Applied Theatre degree (which was great fun!). I had never considered or could see myself working in the tech industry – oh, how things change, and in a good way.

Growing up, my relationship with technology was very much ‘turn on the computer, Gameboy or Nintendo DS and do what I wanted to do’ and as long as it worked, there were no questions asked. I never considered where my game was from, how Google worked or how YouTube was created as long as I could watch Charlie bite his brother’s finger on repeat, talk to my friends on MSN or find the right source for my coursework. Other than “needing” tech, I didn’t have much interest in understanding it.

I have now been working in this industry for just over a year and I’ve learned so much, and how I view technology has changed massively. Rather than it just being an everyday thing that I, and the majority of the world, depend on to get through our day, I can now appreciate the people behind the technology, the ideas that go into it and the time it takes to develop. When I see and hear of new technology, I find myself interested and googling to find out more about it – how it came about, how it was developed and who developed it (one thing that still surprises me is just how many different job roles are involved in this process.)

An exciting piece of technology I have learned of since working in this industry is the technology that was built to measure fill levels of public bins in Newcastle. This technology helps the bin service create the most efficient route by knowing in advance which bins are full and which aren’t. There is some more info here if you are interested in knowing more about it. This is an example of something so simple which has created a positive change – as you can see from the article linked above, Newcastle City Council were able to reduce resources by 50%.

Working as a recruiter at Opencast and talking day to day to different Developers, Testers, and others who work in this industry has given me the opportunity to see the different aspects of the tech world. I have learned that with the industry growing as fast as it is, it can be difficult to find the right people for the roles we have available as Java & Scala Developers, Testers etc are in such demand (which is not a bad thing!) However, the more I learn about the industry, our clients and the candidates we interview, I understand how important it is to fill these roles with the right people but also to make sure that the role is right for the candidate.

I have been inspired by the people I work with here to get involved in conversations about technology, encouraged to attend conferences such as Build IT Right, and tech meetups like Agile North East (highly recommended – I learned a lot playing the DevOps Ball Game!). Along with this, I am seeing the great impact that technology and software development has had in the world we live in. I see this through the projects we work on with our clients, especially some recent developments directly assisting the government’s response to the Covid-19 crisis. All of this has contributed not only to my growing interest in the industry but also my desire to further my career.

Tech to me now is a lot of different things. It allows us to improve how we teach in schools, how efficient our businesses work, and how we live our lives in general. It gives us the ability to connect; being able to see and stay in close contact with friends and family even if they live on the other side of the world, meeting and creating new relationships with people you never would have met through shared interests. We see the benefits of this more now during Covid-19 lockdown, people coming together through video calls to work and socialise, sharing relatable content from social media and also being able to keep up to date with world and local news.

For me, my journey in this industry is just beginning and I am sure that over time, what tech means to me will change as technology changes. It’s only been a year; I can’t wait to see what happens next.

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/ ?