Technology + Creativity at the �� Feed

Looks good to me: Making code reviews better for remote-first teams

2021-02-23T10:44:31+00:00

The Russian version of the �� News website.

Why do you do code reviews? Perhaps it’s company policy, just an automatic part of your process, but have you ever sat down with your team and asked what everyone hopes to get out of it?

As a developer, has it ever felt like playing a strange board game where the rules are secret and keep on changing? Or as a delivery manager, have you ever been puzzled why reviews sometimes seems to take longer than writing the code itself?

These are some of the things we were asking ourselves at �� News a year ago. We’re not sure we’ve found all the answers yet. But we think what we’ve learned so far has improved our engineering culture and helped to make code reviews a better experience for everyone.
In this post I’ll share why we started asking these questions, and some of the things we found out along the way.

Our first taste of remote-first working

Throughout 2019 the teams working on the �� News and World Service websites went through a period of rapid expansion and changing priorities. What had started out as a close-knit team of five building a reimagined articles page for �� News ended up with 35 engineers across five teams contributing to the same product.

Suddenly we weren’t just building one page type, we were rebuilding all 41 World Service language websites from scratch.

There were other changes. At the start of the year, everyone was co-located around the same bank of desks at Broadcasting House in London. Instant feedback and advice were usually available by turning to the person sat next to you, and pairing came relatively easily.

By December however, the engineers were split across six geographical locations in three time zones. While nobody could have imagined the upheavals of 2020 that lay ahead, we found ourselves having to adapt to a remote-first culture rapidly.

Growing pains

Despite the stresses of scaling sevenfold in a matter of months, the teams made a great success of the changes: by mid-2020 we had successfully rebuilt a set of sites that deliver free and impartial journalism to 35m unique visitors globally per week (for an overview of the ��’s cloud journey see Matthew Clark’s recent post, and for the performance improvements in the new sites see Chris Hinds’ post here).

But there were definitely challenges along the way, and one area that was often raised as a source of difficulties was peer code reviews. A large influx of engineers from other teams, most of whom were learning about the codebases for the first time, started opening pull requests (PRs) to get feedback on their work.

We saw that these PRs would sometimes spend considerable time in the code review stage, often cycling between review and re-work multiple times. Approaches to giving and receiving reviews seemed inconsistent. Some developers reported that they found the process unclear, and at times stressful.

It was clear it was time to talk and reflect as an engineering community. We started asking what this ‘code review’ thing we were doing automatically was actually for. We decided we needed a kind of charter for code reviews.

Creating our very own charter

Why make our own? After all, there are already numerous excellent online resources available (such as Gergely Orosz’s blog post and April Wensel’s talk).

The answer was twofold. Firstly, we wanted to create a shared, living document that would evolve over time as we learned more about what works and does not work for our teams.

Secondly, while existing resources offer many useful global principles, a lot of the questions we had required local answers, specific to the structure of our organisation, our codebases and the design of our automated tooling and Continuous Delivery processes. For example: who can ‘approve’ a PR? Do all types of changes get reviewed in the same way (documentation, config, infrastructure code etc.)?

As Gergely Orosz points out, having an engineer-initiated guide to code reviewing is one hallmark of organisational support for the practice. So we started an anonymous collaborative document to source ideas, frank observations and anecdotes about code reviews from engineers of all levels of experience. Then, with feedback and advice from a range of viewpoints we gradually distilled that advice into our guide.

We wanted to make sure that the guide was easy to discover and would continue to be updated, so we put it right into our repositories and linked to it from our top-level READMEs and PR templates.

And as an added bonus, the project we were working on is open source, meaning that potential contributors from outside the �� benefit from more transparency about how we aim to review contributions.

A quick quiz

What’s the goal of doing code reviews? Is it:

To catch defects before they reach production
To share knowledge about helpful patterns and best practices
To discuss alternative approaches and viewpoints
To allow developers of all levels of experience to learn
To link to useful documentation and other resources
To distribute knowledge across the team
To ask questions and check understanding
To improve readability and maintainability of the code
To identify documentation needs
To ensure that work meets quality standards
To record the rationale for certain changes
To coach and mentor junior developers
To promote sharing ownership of the codebase
To notify other affected teams of changes that are being made
All of the above

If you answered “all of the above,” you’ve come to the same conclusion that we did.

We’ve seen over and again that a good code review can achieve all of the above and more (which is not to say that code reviews are the only way to achieve these things). Participating in code reviews in a spirit of open, egoless collaboration is the key to unlocking all of these benefits.

In fact, we sometimes wonder if catching defects is one of the weakest arguments for code reviews, at least in the relatively unstructured way we do them. Think about the last time a bug hit production and caused you a problem, perhaps because of something as trivial as a typo in some config. Could it realistically have been caught during code review? Was it? The truth is that busy developers are not always great at playing ‘spot the difference’.

By the way, the idea that there is a discrepancy between what we expect from code reviews and what they actually achieve is not a new one. An empirical analysis of hundreds of code reviews at Microsoft in 2013 found that sharing understanding and social communication were more common outcomes than finding defects.

What we learned from the process

A few of the most interesting themes that emerged from our reading and internal discussions are summarised below. For more context, see the full guide linked to at the end of this section.

Reviewing code is a first-class activity

We think learning to review code well is as important as learning to write it well. Code reviews are not a second-class activity, to be squeezed in between ‘real’ work. We allow sufficient time in our planning and estimates to allow it to take place, and we don’t neglect it in emergencies, as the cost of haste at these times can be even greater. We actively nurture and develop the skill of reviewing in engineers of all levels.

Communication is at the heart of code review

As mentioned earlier, often the real benefits of code reviews are communication and understanding. GitHub is a powerful collaboration tool but not the only one at our disposal. Jumping on a Zoom or Teams call to talk it through can be friendlier and more efficient than back-and-forth debates on PRs.

This is especially important for growing, distributed teams where there is greater scope for confusion and misunderstandings. We also find group (aka swarm) code reviews effective, especially for significant new abstractions.

Don’t miss the chance to learn

To quote from our guide:

Our primary aim in participating in code reviews is to learn from each other, increasing our understanding of the codebase we are responsible for and of the technologies we use.

Code reviews aren’t just about getting a rubber stamp of approval from someone (often written LGTM, or Looks Good To Me). Every code review is an opportunity to ask questions, share knowledge and consider alternative ways of doing things. Done properly, both authors and reviewers can expect to learn and grow from this process.

And if potential bugs are caught along the way, that’s awesome too.

Remember to be kind

Code reviews can be emotionally demanding for both sides. Pride can come into play — authors may have spent a lot of time preparing their changes, and others may be protective of a codebase.

Taking a cue from the Agile retrospectives Prime Directive, we assume that everyone did the best job they could, given what they knew at the time and the resources available. As we found, trying always to understand the other person’s perspective is particularly critical when new team members are contributing to an established codebase.

Language is also important (Philipp Hauer provides some excellent examples of this). Careless use of evaluations and jargon can undermine the spirit of collaboration that ought to underpin code review. For the same reason we also make a conscious effort to to replace terminology that has racist, sexist or ableist associations.

Keep things in proportion

Many of us have seen cases where a review hasn’t gone so well. A high comment count, multiple revision cycles and comments that have forgotten to be kind are all warning signs that team leads should be watching out for.

Time spent on code review should be kept in proportion with other stages of the development life cycle including testing and accessibility and UX review.

We find that as a rule of thumb, if a change has spent longer in review than it took to implement the code that might also point to a wider problem that needs attention. Are team members prioritising reviews correctly? If there are lengthy conversations, perhaps some of them could have happened earlier in the process?

It may also be helpful for dev teams to regularly reflect on reviews which were harder or less effective than they should have been.

Look for every opportunity to make reviews easier

We’ve noticed that changes that have been authored by two engineers pairing or a larger group swarming often seem to spend less time in code review, with fewer review cycles. This makes sense given the above points about communication, as a lot of potential questions and concerns can be pre-empted, and the change should have already benefited from a more diverse range of skills and viewpoints.

And as April Wensel suggests, automate what you can, for example using linters effectively to minimise trivial nitpicks.

More detail on the above can be found in the full guide at https://github.com/bbc/simorgh/blob/latest/docs/Code-Reviews.md. Bear in mind that some of it is intentionally quite specific to how we work at �� News and may not apply in your context.

Ask difficult questions!

There are many potential benefits to doing code reviews, but they are not always what people expect, and there are pitfalls along the way too. Even so, not all teams will need or want to go through the process of reflection described above. Perhaps tacit assumptions about code reviews are working great for you, or you find one of the existing online resources sufficient.

But in the spirit of continuous improvement and trying to make the way we collaborate more transparent, we found writing our guide a really positive experience. And with remote working now the norm, having a clear shared understanding of these activities is more vital than ever.

The document is now part of our onboarding process for new engineers, and we’ve seen promising feedback about the cultural benefits that talking frankly about code reviews has made.

But the journey doesn’t end there — we’ll continue to update our guide as we learn more about what works for our teams. Sometimes it’s only by asking difficult questions about every stage in our development process that we can really improve the way we build software together.

Ingredients of a good team

2021-01-07T14:25:44+00:00

Survey results to the question "What is the most important factor in a good team?"

We did a survey across �� iPlayer & Sounds on ‘what are the most important factors of a good team’, behaviour and emotional intelligence came out as number one!

Amanda (Project Manager - iPlayer and Sounds) and Qambar (Principal Tester - iPlayer and Sounds) from the Test Team Infrastructure (TTI) across �� iPlayer and Sounds reflect on four key ingredients to help shape teams and increase productivity drawing on their experiences of working with teams.

So what are those ingredients?

1. Behaviour & Emotional Intelligence

“How we behave with each other and how we support each other makes a huge difference in how we feel and what we achieve”

-David Andrade (Head of Software Engineering at ��)

The ability to manage uncertainty is something which does not happen by accident. If we take an example of TTI (Test Team Infrastructure), as a newly formed team that is building a product from scratch, we needed a lightweight mechanism to get us started and feel supported along the way. For example, discussing our ways of working as a work in progress and an experiment, helped us to iterate toward our goals of efficiency and focus. Using this language and mindset meant that when we needed to change our direction of travel this was met with questions such as “what can we learn?”. This relied on building a culture of psychological safety, ensuring that all team members feel heard and valued. This meant that we could have quality conversations which allowed us to continually improve.

Development Cycle Time per goal

We started by discussing what behaviour we want to see and used data to help us measure how we are doing. As you can see from the above data, we planned our goals and measured how long it took us to deliver them. Our data visualisation method changed over time as we grew together as a team and became more collaborative and efficient. The data in the chart indicates that we are getting better at delivering our goals.

In general, as leaders we focus on the retro, in an agile setting, as the pinnacle moment that we all arrive as a team to solve problems and improve our efficiency. When in fact, the retro should be a mirror image of the conversations that happen daily. Listening, opening up discussions and respecting different points of view are so important to developing an empowered, emotionally attuned and empathetic team that pull in the same direction. We challenged ourselves to ask each other what we think, to ask for help, supported each other and to gained feedback. When it comes to continuous improvement, we hold ourselves accountable for the actions we generate by discussing the behaviours we want to create. The process is there to facilitate rather than dictate. This helped us to adapt and change quickly and have a lot of fun together along the way.

2. Team Dynamics

I have been working for the �� for more than 6 years and I have worked in the offices in the South (including White City and Broadcasting House) and in the North ( Media City). During my time of employment, I have worked with different teams (both front-end and backend) in different roles. I have been a Web Developer, Software Engineer, Software Engineer in Test and now a Principal Tester. What I have seen in my career is that every team has their own dynamics.

The roots of these dynamics are planted when people come together and form a relationship called “a team”. As humans we learn behaviours and pass on these learnings to the next generations. Similarly, when a team is formed the dynamics are created then they are passed on to the new joiners.

The relationship and bonds that we form are important as it builds trust and reduces uncertainty. We can predict things with confidence and are able to make faster decisions. This also allows us to form habits making us more productive.

Like a rainbow a team’s beauty becomes prominent when a group of people with different skillsets work together. It is about arranging the colours in such a way that when they blend with each other they are pleasing to the eyes.

The team dynamics can be either good or bad. The question is how do you find that out?

I personally look out for the following indicators:

How open is the communication within the team itself?
Is everyone on the same page?
What do people feel about trust and respect within the team?
How do people react to failures within the team?
How adaptable is everyone to change?
How are differences of opinion dealt with by the Team Lead?
How accountable is the team for what it produces?
How much autonomy is there within the team?
How willing is the team to share and collaborate with other teams?

The benefit of working for the �� is that it is a big organisation and we always talk about “One ��”. So you can ask for permission to attend someone else’s team meeting to learn more about what they are working on.

Speaking of One ��, there are team dynamics outside the team itself. One of the ��’s values is that, “Great Things Happen When We Work Together”. Working outside the team requires relationships with people who you normally don’t work with on day to day basis. The zoom calls and outlook invites are a formal way to ask for permission to engage with them but what if you have an urgent query ?

The kitchen area

“I think 'informal relationships' between team members as people who can 'get along’ are more willing to work through difficulties than people who don’t.”

- Jitesh Gosai (Principal Tester - iPlayer and Sounds - ��)

Lets take an example of TTI again, we started working on a product called Device Asset Manager (DAM), this is used for tracking and auditing devices. Our biggest challenge was that the data was all over the place. We needed help !

The domain knowledge within the team was limited and we had questions, concerns and quests. Working on the same floor as our users allowed us to form informal relationships which allowed us to approach them easily. This allowed us to ask for help, clarify concerns and get assistance with the quest for gathering links to scattered data sources.

We discovered the data was maintained in 5 different sources and they were all unsynced with each other. We flattened all the 5 sources using migration script and imported into our tool. Now the question was, how do we engage our users for feedback ?

The answer was simple, talk to them 😄. The book “Empathy” by Harvard Business Review goes into more detail talking about that. They gave an example of how Ford asked their employees to emulate pregnant woman by wearing “empathy belts”. The research later showed that this approach was misguided as you are still assuming what people want. The simplest way is, as I mentioned earlier, ask them what they want.

This would not have been possible if we didn’t have good team dynamics outside our team.

3. Environment

“By creating right environment this will set the precedent by which the factors can be controlled"

- Mike Wiggins (Delivery Manager)

Just like a tree can’t grow in the desert, a team cannot be sustained without a proper environment. This means you need to give your team members space to grow and permission to flex their muscles and lift weights heavier than their natural abilities. We humans are designed for growth and development, so you should not be afraid of challenging your team with tasks beyond their natural skillset. Give them permission to fail so that they can prosper and develop an ability to take interpersonal risk.

For example, our team, TTI has been tasked multiple times with challenges such as supporting a tool which we have no working knowledge about or influence a team who we have not previously worked with. It was okay for us because we knew we had permission to fail and we will not see a thunderstorm if we failed (believe me I have seen that too where I was reprimanded for poor performance for the demo, it was big hit to my confidence).

Last but not least, get feedback early and often. This helps us move in the right direction without wasting alot of efforts.

Every member of the team can contribute if you focus on their strengths rather than weaknesses and most importantly, listen. I can’t stress this enough, by listening to each other we have evolved as a team. We have a no shutdown policy and we always try to find better alternatives. Just like the other day when one of our team member was pointing out that our user interface requires improvement. But what does that actually mean? So we created a ticket with a piece of work to explore that suggestion, by conducting “User Testing” sessions which opened the door for us to collaborate with people outside our team as well as to get their opinions about the product and incorporate their ideas and suggestions.

Structure is also very important ingredient, to do that, have some team ceremonies that are known to every member. This will help with the communication and will allow team members to stay focused and productive.

We love to appreciate our differences and strengths, this makes a healthy work environment for us to spread our roots and assures us that we are moving into the right direction.

4. Clarity & Purpose

Clarity and purpose helps drive out successful outcomes and focus our direction. When surveying colleagues across iPlayer & Sounds, some of our best experiences have been when we have had a clear mission, well defined roles and supporting structures. When TTI set out, we wanted to ensure that our mission was clear, we understood what good looks like and the steps to moving us toward the goal. In order to start breaking down our mission we created a roadmap which we then broke down into smaller releasable increments.

For further clarity, we followed Amazon’s Working Backwards approach of writing release notes first for our users before thinking about the tickets. This brought everyone in the team on the same page.

As we continued to learn, we cut waste further and reprioritise work for future iterations. This helped us to move quickly in a one direction, focusing decision making and simplifying our meetings.

Finally…

Teams should be a place where we have fun. We should be able to challenge each other respectfully, creating a mindset where we share new ideas and try out new skills. We should be able to grow together as a team, take interpersonal risks and collaborate. In our experience, this is what makes a happy team.

We are all thankful to those who shared their thoughts and experiences through the survey, showing us that we are all connected in so many ways. Thank you for the opportunity given to us by our senior leadership team to share our experiences via this post. Especially to David Shannon, Engineering Manager & Test Discipline Lead at �� iPlayer and �� Sounds, who continuously allowed us to grow and to create something which we are proud off and delivers value to our users (i.e DAM). This has been a defining experience in the struggles of 2020 and a reminder to start from where you are and look out for each other.

Hope you had a merry Christmas and we wish you an amazing New Year 2021!

The Remote Generation

2020-04-27T09:00:34+00:00

Illustration of Eloise and Moritz by Eloise Coveny

About the authors
We are Eloise Coveny, and Moritz Kornher. A Kiwi who once lived in Germany, and a German who once lived in New Zealand. And now we are both Software Engineers at the ��. We gave a version of this article as a talk at the {develop:��} conference in March 2020. It was the beginning of the coronavirus outbreak in Europe, and the conference had to be moved online within a very short time frame.

A few months ago, the idea of a worldwide pandemic seemed unimaginable. Today the whole planet is in lockdown. Back then only some of us had any experience working remotely. Now everyone does.

We were planning to write a light hearted blog about remote first practices. We thought that it may perhaps be thought provoking. But as the current context has been changing daily, so has this. Now that you’re all remote working experts, what can we possibly say that you don’t already know?

We want to tell you two stories about remote-first working. Our teams have been engaging in these practices for some time now. Whilst we found remote working to be very different for each individual and every team, we did also see some common themes emerging. By putting our two stories next to each other, we hope to highlight different perspectives.

Remote Generation

by Eloise Coveny

Since I started working at the �� in May of last year I have been working in a cross-located team across London and Glasgow. Everything has been done remote-first; our morning stand ups, pair programming, and all social interaction with the wider team. In my first few months it was just my team lead and I who were in Glasgow, so our team was only just transitioning to becoming remote-first. I can only imagine for my team, who were used to being all co-located, that this must have been a difficult transition for them to make.

It was particularly awkward for me, not just because I was new to the ��, but also because of the fact that it was my very first role as a software engineer. I was transitioning from a career in the arts, so it was a completely new experience. In hindsight now I think joining a cross-located team meant that I had to be a good communicator from day one. Luckily for me I was no stranger to communication, as I had over a decade of experience in my past career.

I understood the importance of rigorous clear communication very early on, and that it would become my lifeline if I was to get to know my team and learn to become a better engineer. What helped me to feel valued by my team was when my colleagues would reach out to me and either express an interest in getting to know me, or simply offer to pair with me on a task.

So given my experience-to-date as a software engineer has been by and large remote-first, does that make me part of a new “remote” generation? It’s an interesting concept. And perhaps now due to this pandemic, we are the Remote Generation. So what does this mean for the future of software engineering?

Having been a cross-located team now for just under a year, I think we are all pretty comfortable with remote-first practices, and on the whole things seems to work quite well. But this isn’t to say that we can’t improve. Now there are more engineers in our team in Glasgow, I can be guilty of swivelling round to my colleague sitting next to me, to ask him a quick question. But when I do this instead of asking the wider team via Slack, I am excluding others and restricting knowledge sharing. Code Reviews, for example, are more inclusive when done remotely because more people can be involved, so I can receive more varied feedback and it increases knowledge transfer across the team. So this got me thinking, can remote-first practices benefit us, allowing us to develop our practices beyond the limits of co-located restrictions?

We understand the importance of social interaction and meeting colleagues in real life. As ironic as it sounds now, none of us want to be subjected to eternal house arrest. So how do we get around this? What can we do now with our remote tooling to try to bridge these gaps?

Our team has been constantly facing this problem. We have been trying a few things, and although they are no substitution for face-to-face time, they do perhaps make up for some things in our day-to-day working. Every morning in the 15 minutes before stand-up we have a casual drop-in chat room called Talking Heads. This dedicated time-box gives us an opportunity to have these over-the-desk conversations with our colleagues in London that we otherwise don’t get to have. We have also had several farewell calls, giving us the opportunity to say our byes to departing colleagues and share in their embarrassment as they open their leaving gifts. And just very recently we have begun holding end-of-play quizzes on Fridays. Three hosts prepare some questions about topics of their personal interest. The rest of us break off into groups to answer them, and we get the pleasure of learning something new in the process.

It’s fun being able to have the creative scope to use our imagination and design different ways of doing things with remote tools. But, how far can we push these boundaries? And where will remote working take us next?

Test Drive

by Moritz Kornher

For us, remote working started with an email. The subject line was unsuspicious: “Video First trial”. Its contents were ambitious, because in just a couple of weeks the whole of the Voice + AI department would switch to remote-first working for two months. It was July 2019 and little did we know of what the world would be like less than a year later. It was only after the trial that I learned it was, amongst other things, indeed planned as a test drive on our business continuity.

To be clear, we weren’t kicked out of the office. But the intentions of the experiment were communicated very openly. People would choose where they wanted to work; at the office, from home, on the beach or a lonely bothy in the Scottish Highlands. We were to push the boundaries of our existing working practices and learn as much as we can about this new exciting challenge.

How we prepared

So, how do you take a whole department remote? We didn’t need to start from nothing. Slack has always been an integral part of our communication, and early in the year the department did sign up for a video conferencing solution. Around then my team had also moved to remote-first stand-ups to support regular home-workers.

Of course we still had another three weeks to prepare. As a first measure a department-wide town hall meeting was called. Town halls are exactly what they sounds like; one large video call with everyone from within the department and an open floor to ask the senior leadership questions. We held them regularly during the trial and I found them to be a very effective tool for vertical knowledge sharing. These meetings allowed me to ask questions beyond the general brief that was normally communicated. And it was a great test to see if we could have a web conference with over a hundred participants.

With lots of questions answered, some uncertainty remained around the practical execution. What does it mean for me as an individual to work “Video First”? To tackle all these little issues a multi-discipline working group was put together. They have created a Remote-Working Handbook. It reflects industry practises as well as learnings we made during the trial and is now widely shared across the business.

How I dealt with it

The first day of the experiment had arrived. Most colleagues started to work from home straight away. Others preferred to keep working from the office, which is what I did. It gave me the chance to observe changes around us. For obvious reasons face-to-face meetings did not occur anymore, everything moved online. Our work area was much quieter than usual and some co-workers started earlier in the day to make good use of the extra time they were saving on their commute.

Eventually I took the leap and also stayed at home to work. What surprised me at first was how little changed. Within two weeks our processes had adapted so swiftly that the only noticeable difference was a lack of direct social interactions. Of course, there were challenges. If you have ever tried remote pair programming, you will know how tricky it can be. Running our team retrospectives smoothly took us a while, until we had figured out the best tools and the right flow. And yes, video call fatigue can be a real problem.

But these are not issues with remote first working. Look closely and you will find the exact same problems in a co-located workplace. Many people don’t follow proper pairing protocols even when they sit next to each other. Retros can easily be dominated by a few vocal people, and I almost never take the recommended hourly screen breaks.

It was important for us to identify these pain points and to address them quickly. As we had hoped, our ways of working were pushed to their limits and it was clear they needed to change. In a remote world everything is more formalised, therefore flaws in the workflow are exposed earlier. No overhearing of conversations to fill gaps, or kitchen chit-chat to get the latest updates. I believe that being remote helped us to manage this change.

Remote practices unlock new possibilities that a co-located world cannot provide. When I am online there is less of a barrier to use tools or online services that help me to improve my pairing technique. Virtual retrospectives allow us to be more creative and so engaged more team members in different ways, helping to encourage them to share their thoughts. And since I’m in web meetings all day anyway, I can easily schedule my breaks between calls or I get friendly reminders from my colleagues.

How we are doing now

Fast forward a few months and it is the beginning of 2020. We have been following the same remote-first practices we all adopted during our trial. On any given day in my team, someone was working from home. Sometimes it was just one person, on other days it was almost all of us. We did not plan our presence in the office anymore, it just happened. The trial had helped us to improve our working practices so much, that we did not notice a difference anymore. For us it was the new “normal”.

Until coronavirus put Europe in lockdown. At first we were told to stay away from cafés and pubs. Later we were asked to work from home. That’s when I realised how lucky we were. Because we had a chance to prepare for exactly this situation.

Now I know it’s okay to call someone for a quick question, or a wee social chat.
Now I know the value of a well facilitated remote meeting, and I never want to go back to a meeting room again.
Now I know pair programming is a much more effective tool for knowledge sharing than overhearing conversations in the office.
Now I know that it’s okay to do my laundry while I’m listening to that town hall meeting.
Now I know that regular screen breaks are equally important as doing the work itself.
And of course, now I know that I can wear pyjama bottoms all day.

Originally I wanted to finish with a recommendation. I would have suggested that everyone in your team should adopt remote-first working practises for a couple months; to maybe pick a time that is a bit quieter, but really just to go for it. I would have said that all of you need to experience remote working first-hand, so that you will be ready for the new decade and the changes it will bring.

Instead I would now like to leave you with an interesting and telling observation my team lead made at the beginning of the year.

'Everything works better when we work at home'

Keep an open mind, and I promise you can get there as well.

Futurespective

Two very different stories from two unique perspectives. In the first we learn about a team that is gradually forming remotely. We learn how a new starter finds their footing, whilst being physically disconnected from the rest of the team. And how the team finds remote answers to their remote questions.

In the second story we have an existing team that know each other well. A team that is already comfortable working together. And then suddenly they become remote all at once, and they have to figure out how to carry over their practices into this new environment.

Of course both stores share some similarities. Each of our teams had to overcome challenges. But by being flexible and trying out new things, we found that remote first practices have helped to improve our workflows.

There are two points that particularly stand out for us. Firstly, it’s all about communication. Communication is much more difficult when we are not in the same place, but as humans it is engrained in our DNA. We now have the remote tools to allow us to be more creative in the ways we communicate; to explore more, to play more. We need to use this creativity to overcome any remote hurdles.

Secondly, it’s important to have a positive outlook. We are all in this situation together and we can’t just opt out of it. However it is more than just that, we are in the midst of the biggest work revolution since the nineteenth century. Coronavirus is not the cause, it is only an accelerant for this transformation. Our ways of working will change. What we can do is to be a part of this change, to influence it, to make it positive. Let us re-imagine and re-design the way we work as an industry and as a society.

What will our working environments look like?
Our relationships within our teams?
What about our daily schedules?
Our workflows?

Once this is over, all of us will form this new Remote Generation. We just don’t know what it will look like yet.

10x your collaboration on writing tests

2020-02-03T11:21:10+00:00

Collaboration is the process of two or more people or organisations working together to complete a task or achieve a goal.

There is an African proverb:

“If you want to go fast, go alone. If you want to go far, go together.”

Have you ever noticed any silos in your teams? Have you ever come across an “them vs us” situation when it comes to your tests. Do you find automation is sidelined from the software development process, and treated as an afterthought?

What you need is a little collaboration!

I am Qambar Raza, the Senior Software Engineer in Test for iPlayer and Sounds.
And
I am Sheila Bhati, I’m a Senior Tester in iPlayer mobile.

We decided to collaborate on this blog post, about our experiences of how we’ve helped improve collaboration within our teams.

Change understood by everyone

Scenario 1: Change understood by only one person

Have you come across a project which heavily relies on a certain member of the team knowing everything about it ? During stand-ups you will see that person talking about what’s right and what is not and the whole team would nod in agreement.

Scenario 2: Change is partially understood by everyone

What about releases? Have you ever been scared to release something to production because you don’t know what else is included in the release apart from your own change? This becomes more complicated with time when the change starts bundling up to a point where you are releasing 50 commits in one release. How confident would you be with that?

How did we solve it?

For scenario 1, we propose XP practices which means constant pairing on writing code and cycling the pairs for tickets to spread the knowledge across the team.

For scenario 2, everyone in the team should have the ability to understand the change that is being made in the system clearly. This is only possible if the size of change is kept small. In an ideal world that would be one atomic commit that gets released to production after it goes through all the phases of Software Development Lifecycle.

If change is small, then it will be easy to understand and communicate, not only within the team but also outside the team to stakeholders. Everyone in the software delivery chain would be aware of what and why the change was made and would be able to support their customers better.

We understand that sometimes it is not possible to do atomic commits and the change could include multiple commits. Although we highly discourage this practice we have a temporary solution. Within a department where multiple teams are involved in the change you can use the method of “huddle” when the change is being released to production. It helps you share knowledge between teams about the changes committed by members of each team and ask questions about risks.

The problem with doing a bundled release is the rollback or revert process. For example you release five changes together to live and, out of the five, one of the features is completely broken. How would you deal with that? Would you just do a full rollback? Or do you prefer a roll forward approach or patch based approach? The roll forward approach takes longer as you would be putting a “proper” fix in the release and for that you will need developer effort. The patch approach since its a quick fix there are chances of side effects. Rollback would mean that all the features that you just demonstrated to your customers are taken away from them. This will damage your trust with the customers and could have a big impact on your organisations reputation.

A better approach is to keeping things simple, releasing everything you have from commit to production has several benefits:

Team members are happy and onboard as they understand the change
Customer happy as less disruption and confusion in the product
Stakeholders will be happy because they can understand what is live and what did not
The Test Team would not have to create complex test scenarios in order to approve the change which means testing would be faster
Your overall pipeline process would be smoother and faster

In order to understand the impact of a change as a team, we need to create a shared understanding of the change. So how can teams go about building that shared understanding?

Help create a shared understanding between developers and testers by encouraging developer and tester pairing

When work in a team isn’t aligned and automation is put in place retrospectively rather than at the time of development, it can increase the burden on manual exploratory testing and ultimately increase risk of bug leakage. Which potentially requires rework on issues found late on in the development cycle. Collaboration between Dev and Test teams helps to ensure test automation is part of the definition of done. By not having to develop automation retrospectively you can maintain focus on the current task, smooth the process of delivery, and the team will have more confidence to deliver features faster.

In our experience by introducing pairing practices, dev and test can agree which tests are required and where to include them at UI level, integration or unit test level. This helps in a number of ways:

Creating a shared understanding of test coverage
Reducing duplication of tests and the effort to maintain them
Exploratory testing focuses more ways to improve a product, rather than being a bug safety net.

Overall it contributes to a reduction of risk and can help teams go faster.

This is just one blog post out of the series that we are planning to write to share our experience with you. Please feel free to comment and share how you collaborate within your teams.

Step into Tech update

2019-03-22T16:13:15+00:00

Step into Tech is a D+E initiative to make a positive impact on gender balance in our software engineering community. It's essential that organisations like ourselves make positive interventions like this to take on the challenge of gender diversity within the technology sector. This isn't all we need to do; much more is required, and it's great to see us turn this idea into action.

"It's been fantastic to track the progress of this first cohort of 16 women, as they made their way through the initial selection stage, onto the training programme and then to see how much they have all learned when they presented their projects on graduation evening. It makes me very proud to be the sponsor of this initiative, something that's going to make a real impact; I can't wait to meet our next intake!" Matt Great, Director of Platform, �� Design+Engineering.

"The success of this programme is evidence that there are other routes into software engineering as well and not just the traditional routes; as long as the key behaviours can be demonstrated the technical skills can be taught. I know from speaking to all of the students, that many do feel that The Step into Tech programme really has been a life changing experience and opened up a new world of opportunities that some thought were out of reach. I am so proud to have to have been the project lead in getting this programme off the ground and to experience first-hand the positive impact this has had with our first cohort and the teams across Design + Engineering. I look forwarding to planning the next one!" Sue Mosley, HR Business Partner.

A fresh approach to flex

2019-02-25T13:51:32+00:00

We live in dynamic times - the rate of change and progress is extraordinary - and at the �� we continue to drive innovation on a global scale. To do this, we need the best teams that represent society and the audiences we serve. In �� Design and Engineering (D+E), I want to create a culture that attracts the best talent and makes people want to stay and do the best work of their career; even in a really competitive field like technology. For me, a key characteristic of this culture is that it recognises that people need balance in their lives and accommodates flexible working.

My own story

That difficult balance between work and home is something we all understand. I became a dad for the second time last year. It is obviously a hugely important time for us as a family as we get to know our daughter (and sister) and watch her explore the world. But it’s a busy one too, with sleepless nights, my son’s activities and my wife returning to her own demanding job. I want to be present for my children as they grow but I also want to give my all to leading the ��’s Design and Engineering team through very challenging and exciting times, so it takes careful diary management, compromise and understanding to make it all work.

I know I’m really lucky as I have a great team around me. We have all discussed how to make it work; they support me and, in turn, I support them to achieve our own versions of work-life balance. It means that I’m able to drop my son off at school at least once a week and I’m home early on another day to spend time with both children. In the team we have two job-sharing PAs and others who work from home and take extra time off outside term time. I am determined to develop a culture that accommodates different needs so we are flexible about working hours whatever the reason.

None of this is easy and, with D+E people all over the country, I don’t always succeed in accommodating everyone’s needs as well as I’d like to. But I’m honest about the competing priorities in my life and encourage others to be too.

In D+E, I’m championing pilots to bring in new people from a range of backgrounds. A Career Returners Programme will make the division a more accessible environment for women and men who have taken a career break and wish to return to the workplace. Meanwhile, our "Step into Tech" programme provides a free 14 week, part-time training programme giving people the necessary skills to apply for software engineering entry-level roles. But the success of these initiatives - in terms of attracting and retaining the best, diverse talent - also relies on us being able to offer flexible working practices that work for everyone.

This is why I believe that, throughout the ��, we need to take a fresh look at flexible working. The �� has recently conducted a review around Culture and Progression and flexible working placed in the top 3 priorities for both women and men working. It’s clear from research that the workforce of the future will place an even higher value on a good work life balance and a sense of purpose beyond financial success.

A new flexible working policy for the ��

Of course, many people already work flexibly in the �� and you can see some of those men and women’s stories on our D+E careers site. Their reasons for working flexibly are as diverse as the working patterns they’ve adopted. Parents, carers, downsizers, portfolio workers – there are many reasons and ways to work flexibly.

And there’s certainly more we can do to make this possible. Just as we are introducing technology at the �� that enables people to work differently, like Skype for Business, so must our attitudes to work change: measuring performance not attendance; designing flexible working practices into our jobs and making flexibility open to all.

That is why I am so pleased to see a revised, more inclusive, flexible working policy in place at the ��.

It has been designed to enable us to do all we can to accommodate flex working - recognising the potential benefits to both the business and individual. It includes an increased range of flexible options, supporting full time and reduced hours, such as staggered working hours, compressed hours and remote working. It also outlines a new approach to job shares and new working from home guidelines.

Applying this policy will, of course, take some practice. There will be some roles that are easier to flex than others, some roles will have specific operational barriers, some roles offer no control over when or where you work. Others may feel that moving into a more senior role just isn’t an option on a part-time basis. But this mustn’t stop us overcoming the fears associated with change and shifting the value we place on presenteeism. And we must also overcome the bias that part-time working means part-time ambition.

With this new policy in place, I’m keen we challenge ourselves on the barriers that are preventing more flexible working patterns – both full time and part-time – in the ��. I will be asking my teams in D+E to take a fresh look at flex: to think about those barriers and how to overcome them. I want us to enable and nurture a new generation of talent in the �� - those who might have thought our doors wouldn’t open because of their background, education or gender. I want to see job-shares and part-time workers at the most senior levels of the organisation and in every part of the ��. I also want to work in an environment where we can all be honest about the other priorities in our lives – whatever they are - and have the flexibility to spend time on them. Find out more about flexible working on the �� Design + Engineering Careers site:

https://www.bbc.com/backstage/design-engineering/flexible-working

My flexible working story: why I am based at home

2019-02-19T11:12:13+00:00

I think if you’d told me five years ago that I would be working completely remotely, I definitely wouldn’t have believed you.

I was the person who dragged their feet into the office between 10.30 and 11am and didn’t leave until about 8 or 9pm. I was the person who treasured being able to work from home on Thursdays but worried endlessly what people were thinking about me being at home, and worked through lunch hastily responding to any small alert on my phone just in case it was something work-related, paranoid that not replying would be the undoing of me. In the office I felt rushed, stressed, and anxious.

I had years of people telling me that I was “lucky” to be able to work from home one day a week. Lots of this apparent jealously seemed to stem from an admission from these same people that they “wouldn’t be able to do it”, and would go so far as to suggest that people who worked from home were actually bunking off.

I feel it’s quite important to make that point. Bunking off. As if, by being in the office you are suddenly incapable of taking a two-hour lunch break or three 45-minute coffee breaks with colleagues that definitely aren’t friends that you will chat to about anything but work. As if being physically seen gives you something that not being physically seen doesn’t.

I think it’s fear. People are scared of what happens when they have to control their environment and don’t applaud themselves for ‘turning up’ and considering the job done. And this fear perpetuates a myth that remote workers are all lazy do-for-nothings. I can tell you, fast forward to now — nearly two years since I started working remotely — I have NEVER been more busy at work. I start at 9.30, sometimes earlier, and I finish at about half 5. I’m not anxious, I’m not stressed, and I am taking the time to enjoy what I do.

So why did I apply for flexible working? What prompted this complete overhaul that leads me to my current “lucky” remote working status? Is it all it’s cracked up to be, cocktails on the beach and unlimited Netflix? Well, on the last bit, short answer — no. Long answer — hahahahahaha. No. I mean, for starters, I don’t have a Netflix account (and I could enter here some rubbish about it being because I work for the �� and iPlayer is fabulous which, whilst it might be true, isn’t the reason — I simply don’t get a lot of pleasure from watching TV. There. I said it. Why do I work at the ��, I hear you ask? Sure. Well, the �� is actually more than just TV. It’s ‘I’m Sorry I Haven’t A Clue’. It’s the �� Weather app. It’s satellites and hardware and awesome branding. Anyway, I digress). Let’s get to it. Why did I apply for flexible working? Plenty of reasons, and here are a few.

Reason #1: because I can

On June 30th 2014, flexible working in the UK was forever changed with the introduction of a few legal changes. It meant that anyone who had worked at a company for over 6 months could apply for flexible working, and employers have to use one of 8 justifications to deny the request. If it’s reasonable, there is no way they can refuse just because they don’t like it. Which is great news if you want to explore options to work from home more, or shift your hours around, or work part-time to fit in caring duties, or a hobby, or anything else.

Before this, the only people who were eligible to apply for flexible working options were parents with children under the age of 17 and carers. What’s interesting about this is that there is often a perception that these people working part-time around carer or parental duties are women. And if that’s what you assumed, you’ll be surprised to hear that more men have flexible working arrangements than women. Interesting, huh?

Anyway. So, the law changed, and I could apply for flexible working. I should probably exaggerate here that the law changed so I was ABLE TO APPLY for flexible working — nothing in the law grants me the right to have it though. Luckily, I have a supportive team and a supportive manager at work who were open to trying it out. In fact, it was my manager who first suggested that a flexible working arrangement might help me.

Reason #2: the dreaded commute

The Central Line from Mile End is absolute mayhem from about 7.45am until about 10.15am. Remember when I said that a few years ago I rolled in at about 10.30 or 11am? That wasn’t because I particularly wanted to, but it was more because otherwise I ended up getting to work completely stressed out and on the verge of an anxious breakdown. And I wouldn’t leave the office until late, so I’d be hungry and sad.

On a work day at home, I jump out of bed between 8 and 8.30 and start between 9 and 9.30am. I finish at 5.30pm. And then I can kick back and read a book or cook something tasty for dinner immediately, because I haven’t got an hour of a hellish commute to look forward to. I can finally work similar hours to everyone else, less stressed, less anxious, and without wrestling with some tourists’ backpack as someone else spills coffee down my leg and there isn’t anything I can do about it. And one thing I’ve noticed — I’ve been far less ill since I stopped commuting every day. Apparently stress can make you more susceptible to illness. Apparently so can standing in a train with 200 strangers every day. Take from that what you will.

Reason #3: orthostatic hypotension

Ever since I was a kid, I’ve had a habit of fainting. I once had to take the day off school because I fell back onto the concrete floor at home and luckily didn’t break my skull open. As I’ve gotten older, I recognise the signs I’m about to pass out a lot better and I can tell when a fainting episode is coming. I went to see the doctor when I was in my teens, but he dismissed it as nothing but ‘little girl syndrome’. I’m still wondering what on earth he meant by that.

In 2016 I fainted in the hallway at home and as I passed out, I felt my body jerk uncontrollably. Terrified I was having a fit, I called my GP (thankfully not the doctor from my teens) and had all sorts of checks carried out. I had an MRI, which was just a lot of loud banging, and I had my heart examined. Thankfully a heart condition was ruled out, as was epilepsy. I was then referred to the hospital in Paddington to take what’s called a tilt table test. You’re strapped onto a bed with a metal plate at the bottom, so they can raise you to standing and you rest your feet on the metal plate. The test is simple. You lie down for 5 minutes in a slightly darkened room, and then you are raised to standing whilst tied to the bed. Your heart rate and blood pressure are monitored throughout and someone sits there for the whole time tapping away at a computer. You stand there in the room for 20 minutes, and then you leave. That’s it. You just stand there. How is this even a test? I thought to myself. I stand all the time. I am a champion at standing. Someone probably applauded the first time I managed it, but since then it’s just part of my daily life.

So I lie there, happy as larry. And then the bed is raised. And it’s all fine, the woman tapping away at her keyboard, tap-tap-tap. Then suddenly — it is NOT okay anymore. I’m feeling a bit weird, a bit warm. Then I’m feeling a weird headache. And nauseous — oh wow, so, so nauseous. “I feel sick,” I tell the woman, “I feel really sick. Can I lay back down?” Nothing, not even a glance. Tap-tap-tap. “No really I feel weird,” I say, beginning to sweat profusely. Still no response. It’s like this for about two minutes, when suddenly my vision begins to darken and my hearing gets muffled and — just like that, the bed suddenly goes back to flat, my vision starts to return, and I feel SO much better.

“You passed out after two minutes and thirty four seconds,” she says, smiling at me. SMILING at me, after she heartlessly ignored my pleas for help.

I walk out of the room with a few things: finally, a diagnosis, and a much better understanding of what’s going on with my body. It turns out the blood is pooling at the bottom of my body when I stand, and my blood pressure isn’t strong enough to push it back up so my body just cuts out; my heart stops and my blood pressure drops. “It’s the body’s way of restarting,” she says to me, “it’s cool.” And she’s right, it is kind of cool. And it suddenly starts to explain the anxiety attacks I have on the commute into work — suddenly feeling hot and sick and needing to get off the train. Turns out, whilst there may have been an anxiety there, it actually stemmed from a medical condition which I hadn’t known about. It means I need to sit down if I’m doing a longer journey on the tube, and if it’s rush hour, I won’t be able to stand still without being able to move for longer than a couple of minutes. So in part, the diagnosis of this condition allowed me to explore flexible working; a way for me to avoid commuting altogether. I can imagine that there are plenty of happy people on the Central Line who are pleased I no longer hold up their journey by being one of those ‘passengers taken ill on a train’ that makes everyone in London so angry.

Reason #4: desk space is like gold dust

Most of my stakeholders are in other offices across the ��, and even if they’re in the same office, the majority of my work is done over the phone or over Skype. It’s rare for me to go to a meeting in person. So what’s the point in me taking up space that should be going to people who need a specific set up? If I can take my calls from anywhere, then I can vacate a space for someone who needs it. In the office we don’t have enough desk space for everyone to have their own. We run out of meeting spaces and quiet booths to make calls — because everyone wants to find somewhere private to have a chat. Not only can I free up rooms I’d otherwise take for my private chats, I can have as much space as I need and I don’t need to clear my desk at the end of the day. Any space I’d occupy in the office goes to the people that need their equipment at a fixed desk, and my private calls can be taken whilst sitting at home. I no longer need to run around the office panicking as I try and find a quiet spot. At mine, everywhere is a quiet spot.

Reason #5: I am a catering nightmare

“Do you have any dietary requirements?” is a question that I hate. Mostly because it’s quite a challenge to cater for me, and I feel very guilty about it. I’m a gluten-free vegetarian. Where can I eat for lunch that is safe? Er…well, not many places. Remembering to bring in a packed lunch is a faff, and takes up space that’s already filled with all the things I’m already carting around with me. At home all I need to do is go to the kitchen, open the fridge, and voila — a safe haven of uncontaminated food where I don’t have to politely wait for 15 minutes to check if something has gluten in it, only to get a blank stare and then 5 minutes of quiet whispering in the kitchen before I get the standard “we can’t guarantee our food is allergen free” and sigh before playing russian roulette with the salad options. It’s much safer for me, and much less stressful for the people who might be going for lunch with me, to just eat at home where I know I’m going to be a-okay. Plus, it’s so much cheaper!

It’s worth saying that even now, two years in, many people I speak to on the phone don’t even realise that I’m working remotely. Things haven’t changed drastically, and I’m perfectly able to manage my team and my workload without feeling the need to go into an office.

I think it’s quite important to share my story because flexible working isn’t just about childcare and being a carer. It’s about a whole new approach to working. It’s not flexible working at all, really — it’s alternative working. There’s actually nothing flexible about it, it’s just a different kind of arrangement that works better for me. For other people, those water cooler moments might help motivate them, or maybe being in a fancy location surrounded by bustling crowds or office ‘banter’. Maybe they prefer to only be there part-time and maybe that’s how to get the best out of them. It just happens that what’s best for me isn’t being in the office 9–5.

Caz works at the �� as a Senior Product Manager and has been working remotely since 2017. You can find out more about the ��’s approach to flexible working by having a look here: https://www.bbc.com/backstage/design-engineering/flexible-working

Building a �� Product Management community

2019-02-12T11:25:53+00:00

Last Thursday over 100 �� Product Managers got together in Salford with a load of flip charts, post-its and Lego, and set about building a Product Management community. We spent the day talking to each other, hearing from internal and external speakers, and planning our next steps.

The goals of the day were to collectively come up with practical next steps and a clear idea of what our product community will be and what we get from it. We want the community to increase collaboration and shared learning, support and motivate us and help us get better at what we do.

To start us off on the right foot, we had Emily Webber talk to us about Communities of Practice. She shared her experiences of building communities in large organisations and small meet-ups. Emily explained the benefits of having a community that provides a support network, helping us to learn and develop skills, sharing knowledge and scale our ways of working. Emily talked about practical tips for how to form a community and then ensure that it sticks around long enough to mature and stabilise — a challenge for a group of busy product managers.

Emily Webber

Community: what next?

As a group we thought about how we can use this community to make being a Product Manager at the �� even better and how we make those things happen. This is our current to do list:

CONNECT: We should have an easy way to find other �� product managers and be able to see what they work on and their interests, and be able to get in touch with them.

SHARE: The community can help us give ourselves time for learning and developing our skills, possibly through shadowing, pairing on tasks or attending each others meetings and offering feedback — but with a focus on how we do things, not what we’re working on.

MEET: Events should include visible, themed, informal meet-ups, which bring people together who are working on similar things or have similar problems.

External perspectives

As well as talking about how to build our community, we also wanted to have some time to talk about how we actually do product. The discipline of product is evolving fast, as is the industry that we work in. We wanted to look out to the wider product management world to hear how other people do it, the challenges they face and how they have overcome them.

Gadi Lahav from the FT talked us through how having a single north-star metric can help you stay focussed on your real goal and guide you in making better product decisions to achieve that goal. As you would expect from the FT, the approach Gadi described was smart and accurate — understanding your metrics and what they mean is key to getting the most out of your data. We heard about some product case studies which have informed the product strategy and show how Gadi and his team are continually challenging the work they are doing.

Lucy Küng

Lucy Küng from Reuters Institute blew us away with her research on how the media industry is reacting to the changing world around it. The complexity of older companies makes the challenge they face from start-ups even bigger, success lies in collaboration at all levels of the organisation and acknowledging that technology is now at the heart of everything we do — not just ‘the plumbing’. Lucy went through her observations on the role of product in big change — how it sits at the nexus of content, tech and business, which means product people have to talk all those languages.

“The ability of media companies to innovate and compete … is fully dependent on how they view product and product management … New players seem to get it. Now it is time for the rest to fully appreciate product innovation”
— Quote from Lucy’s research

Rightmove’s Melanie McKay talked about the challenges she’s faced and how product can transform companies — the talk has already been quoted in meetings I’ve been in! Melanie shared tips for staying focussed and achieving your goals even when shiny feature requests are trying to distract you.

Melanie McKay

Lego Challenge! + Prototyping

To give us a chance to think about how we do things day to day (and as an excuse to play with some Lego) we had an hour or so thinking about prototyping; what makes it hard to prototype; what works, what doesn’t work, what could help and how. The room was noticeably livelier once we let the lego loose — finally the chance to make something!

The feedback from the session included some direct lessons — we should maintain the feeling of fast progress and continual learning in our work. One of the benefits of using Lego was the lack of barrier to entry — everyone could get stuck in straight away, pretty different to how a cross-functional team would normally rely on the developers to build a prototype. Can hack days feel more like this, instead of the non-developer drop-out after lunch, could we hack in Sketch or similar to achieve this?

A couple of people said they liked the exercise and would use it for team building or as a warm up for discovery, which is a nice, unexpected outcome of the session.

Lessons for prototyping:

Don’t get caught up in the detail
Build in a modular way that can be put together after
Fail fast, learn fast
Needed to keep sight of goal (and have principles) to keep the prototype focussed
Diversity of experience is valuable, how do can we recreate this in day to day prototyping?

So…

I think we can claim the day a success — we achieved our goals, defined next steps and have formed a team to foster the community. The discussions on the day were around how we make this community work rather than questioning the benefits of it — which I think is thanks to the aligned perspectives we heard at the start from Chris Condron (Director of Digital Products), Matthew Postgate (CTPO) and Emily. Chris said that product needs to be at the heart of the changes that we are making at the �� and this was reiterated in Lucy’s talk later in the afternoon. Matthew gave us some context for the changes we are undertaking and specific ways of working which will help us work together and achieve more:

Ladder up to the ��
Assume good intent
Talk to the source
Disagree and commit

It feels like we have started to do something really cool here; the community is something that we can build, grow together; it belongs to all of us. We will use it to help us learn and develop individually, and as an organisation.

Who actually are we?

Here are some responses to a survey we are running to find out more about the product managers in our community…

And if you’re interested in joining us, check out our vacancies — �� Careers

Women in tech event - get involved

2019-01-09T11:44:36+00:00

As part of its ongoing Diversity programmes, �� Design + Engineering is hosting its next Women in Tech event on Thursday 17th January 2019 in Salford, Media City. The evening will consist of several short talks from internal and external speakers, themed around what it's like to be a woman in technology.

Confirmed speakers include Shefaly Yogendra, Chief Operating Officer of Ditto AI, a Manchester-based company specialising in explainable AI, and Sarah Tulip, Operations Director of Software Cloud, a Leeds-based technology business

You can find more details here, including the opportunity to book a place.

Step into Tech kicks off

2018-11-27T13:13:54+00:00

This month Design + Engineering in partnership with our external training provider – Tech Returners – kicked off the inaugural Step into Tech programme in Salford. This 14 week, part-time, programme will teach women, external and internal to the ��, the basic concepts around software engineering and the course curriculum has been designed around a new role in the Software Engineering job family, Associate Software Engineer. At end of this programme, the cohort will have the necessary skills needed to apply for an entry level role of Associate Software Engineer within the �� Design + Engineering Division.

The programme kicked off with several D+E colleagues welcoming the group to the ��. Following introductions from Sue Mosley, the HR Business Parter who is leading the programme, Matt Grest, Director of Platform provided an overview of Design + Engineering and the areas within the division and Sam Hill, Head of Software Engineering, gave an engaging outline of what software engineering at the �� looks like. Charlotte Hoare, Software Engineering Team Lead and Laura Howarth-Kirke, Senior Software Engineer, who are mentors on the Step into Tech programme, also shared their journey into Software Engineering with the group.

Lots of colleagues from the various job families across D + E have volunteered their time to go along to talk about their job function and what it means to be part of �� D+E – thank you to everyone who has got involved so far.

Sue Mosley, HR Business Partner, said: "It's so pleasing to have witnessed first-hand the enthusiasm from this group of women during the Step into Tech kick-off session. It is amazing to see how engaged they are with the programme already. From this group, 14 out of the 16 are from non-technical backgrounds with non-related degrees or qualifications – the fact we have encouraged such a positive group of budding software engineers to join the scheme shows that we are in a great position to increase gender diversity across D+E"

Charlotte Hoare, Software Engineering Team Lead and mentor on the programme said: "I was excited to be asked to mentor on the Step into Tech programme, and am even more excited now having met the 16-strong cohort! The curriculum we have lined-up and the enthusiasm in the room on day one have made me feel like we're taking real, tangible steps towards redressing the gender balance in the tech sector. I'm excited to follow the progress of this cohort and of Step into Tech in the future."

One of the new students on the programme, Emma, said: "When I heard I had been selected to join the first Step Into Tech programme I was so excited to get started. I have always wanted to get into technology but didn't know how I could break into the industry without going to University. This programme is giving me the opportunity to not only learn the skills required to get started in a technology career, it also helps me to understand and feel more confident in how I could apply for an entry level role, hopefully within the ��."

Visit our careers page: /careers/

Opening up our data science course materials

2018-10-23T11:30:00+00:00

Today, the �� Datalab team is releasing onto the open web the course materials it developed for newcomers to data science at the ��.

Data science, and particularly machine learning, is trending like never before. At just 12 minutes (!), NIPS tickets sold out quicker than Burning Man this year and if anyone still needs convincing, check out this plot:

It shows us that as recently as this year, both terms overtook the word “hipster” in web searches. While this may not be great news for avocado sales, it does look like it’s a good time to be someone working with data! But as ever, with exposure can often come confusion. So first, let’s try and get some definitions straight.

The �� handles terabytes (read - “a lot”) of new data every day, and data science is the field of study that helps us use that data to make better decisions and deliver greater value to our audiences. Machine learning, meanwhile, is just one class of statistical techniques widely used in data science that, as it turns out, is particularly powerful. However, it is not magic. Instead it is a collection of tools and techniques that use mathematics to draw conclusions from data.

It could be argued that nothing indicates more the need to publish a training course than the moment a topic surpasses in web traffic a cool word millennials (usedto?) use. But our team did have other reasons for opening this course up. Here are just three:

1. To get people excited about learning more data science and machine learning; particularly when data literacy is so high on many employers’ wish lists.

2. To share some of the interesting problems faced by the �� in the data space.

3. To demonstrate how large organisations such as the �� can use their audience’s data to generate a positive impact.

Continuing to create engaging content, while the expectations of our (especially younger) audience members are constantly shifting, is one of our greatest challenges. To ensure we meet these new expectations, it is important for us to analyse and understand the conditions and behaviour patterns that lead to more, or less engagement.

In this course, we use data to explore the question: “What makes �� audiences engaged?”. If you have at least a basic understanding of Python programming (statistics would be a bonus!) and a healthy interest in taking your first steps in data science, we think you will have a lot of fun exploring our course.

And if you found this training easy and had fun doing it, why not join us?

We take readers on a four-part journey that follows the typical pattern of many data-led projects. Each part is expected to take readers around one hour to complete and focuses upon: data exploration, data transformation, classification models and regression models.

In data exploration, we first look into how to formulate our data science problem and perform some preliminary analyses to get a better feel for our data. In data transformation we then introduce readers to some basic machine-learning theory and walk through the process of how we prepare our data for ingestion into our statistical models. In the final two parts (classification and regression), the actual machine-learning starts, where we explain how to train, evaluate and choose the most appropriate model for our purpose.

The dataset that you get to work on contains the logs from 10,000 �� iPlayer users. As you might expect, a public service broadcaster like the Beeb doesn’t take data privacy lightly. So while the dataset we use is ‘real’, you can be sure that we have enforced particularly strong anonymisation so that the identity of the users is impossible to recover.

With an introductory course like this, we don’t expect to make anyone an expert in data science overnight. However, we do hope that those of you who do take it will have a lot of fun, while also gaining some valuable insight into the decisions we make when working with data at the ��. The topics covered in the online course only scratch the surface of the data science problems we encounter daily at the ��.

If you would like to find out more about the challenges we face and how we are using data science and machine learning to find innovative solutions to connect with audiences, please get in touch!

We are always looking to improve the content of the course, so if you have any feedback or ideas for further instalments we would really like to hear from you.

Link to course: https://github.com/bbc/datalab-ml-training

Step into Tech with �� Design + Engineering

2018-09-18T12:33:28+00:00

Just 17% of Tech/ICT workers in the UK are female, while only one in ten females are currently taking A-Level computer studies, and yet there is a looming digital skills gap where the UK needs one million more tech workers by 2020 (source:Tech Talent Charter). Organisations need to work together and take learnings from each other as to how we can solve this problem.

Here at �� D+E, we are committed to address the gender imbalance within the division and look at what initiatives we can implement to improve this, my role is to lead on this programme of work which is sponsored by our Chief Technology and Product Officer, Matthew Postgate.

We launched our Career Returner programme advert, which will support experienced women (and men) who have taken an extended career break of 2 or more years back into mid-senior level roles within our Design + Engineering division. The next action we have taken is to address what we can do to inspire more females to take up a career within software engineering. We have learnt from what other organisations have successfully achieved in this space and we will follow suit.

Our Step into Tech programme is a free 14 week (part-time) training programme, with our first pilot delivered onsite at �� Media City. Students will be taught the basic concepts around software engineering and at the end of the course will have the necessary skills needed to apply for an entry level software engineer role within the �� Design + Engineering Division. Not only will this scheme be open to external applicants, but also to �� employees and this will encourage progression from other areas of the �� into the Design+Engineering division.

By introducing these various initiatives, we’re taking a step forward in making progress to address the gender imbalance in the technology sector. The more organisations who do take action, the faster we will fix the problem.

It’s not just about fixing the talent pipeline; we have committed to a number of initiatives that are focused around Culture and Progression to ensure we are retaining our women and making the �� an even greater place for women.

To find out more about our Step into Tech programme click here.

Supporting people back into the workplace after an extended career break

2018-09-10T12:26:27+00:00

I joined ��’s Design + Engineering division in April this year with a specific remit, and that is to look at ways we can improve gender diversity across the division and to put these thoughts into action. We have a shared issue with so many other organisations who struggle to attract women into technology roles – there is a distinct lack of this talent in the pipeline and we all have to work together and take the necessary steps to change that.

�� Design + Engineering want to open up new avenues of opportunity – and the first programme of work that I have been leading has now launched with our advert now running for the ‘pilot’ of our very first Career Returner Programme. There’s a lot of people out there, women and men, who take career breaks for many different reasons, and a high proportion of these people are so keen to get back into the workplace, this is a relatively untouched pool of talent and we want to do what we can to help them to return to the workplace into a suitable and relevant role.

It’s exciting to be a part of something that is really going to have such a significant impact for these individuals who are so keen to get back to work. We will ensure all our career returners receive the coaching support and additional training they need to get them up to speed within an inclusive and collaborative environment.

To learn more about our Career Returner Programme and the roles we have available please go to this link here.

A Technology Capability Framework for broadcasters

2018-07-31T15:48:37+00:00

Andy Leigh, Head of Architecture for Broadcasting and Nick Hopewell, Lead Architect for Broadcasting Architecture, are part of �� Design + Engineering’s Technology Strategy and Architecture team.

The UK’s public service broadcasters are facing greater challenges than at any time since the 1970s from US tech companies dominating global media. As �� Director General Tony Hall recently stated, we are at a time of “breath-taking, seismic change”. Due to big market interventions from conglomerates such as Disney and Comcast, the media world is consolidating at a speed not seen before, and the �� needs to change radically to meet this challenge.

In order to help the �� keep pace with the new global players, we set about creating a Technology Capability Framework to support a common vocabulary between the ��’s Design and Engineering division and the rest of the ��, providing a mechanism to assess the current, required, strength and performance of capabilities as a part of our strategic planning.

Defining the ��’s business imperatives and capabilities

This piece of work came about as a result of the Technology Strategy and Architecture team conducting a strategic analysis. Many organisations have now developed generic capability models that describe the capabilities that a business uses to fulfil its objectives and reach their maturity. We wanted to use a capability model that was relevant to the �� and, so we started to think about the ��’s capabilities. We interviewed over 60 stakeholders around the ��, from COOs to Directors of Technology and Finance, about what the �� does and what technologies were currently being used to support those business areas.

Out of this work, we developed the ��’s technology capability framework. The framework diagram below identifies the top level of the technology architecture, capturing the core building blocks that can be used to describe the enterprise’s technology capability domains. In fact, to go one stage further, if you were building the �� from scratch, or indeed any other broadcast media organisation, we believe this model would not change significantly.

The four middle blocks represent what the �� does day in, day out – it plans content, it creates or buys that content, it distributes or sells it (in the case of commercial subsidiaries) and finally, audiences engage with our content and we measure their engagement to find out what people like; this information then feeds back in to the planning and so the process begins again.

The content that we make or buy is part of an increasingly important supply chain – this is what allows us to deliver the content our audiences want to consume in this increasingly on-demand world. To run the �� we need support from areas such as Finance, HR, Technology and Facilities. We need to have the right infrastructure in place, from all the physical hardware and those that we consume as services. As part of the strategic analysis we identified a set of foundations which we believe will need to become embedded in everything new that we build as part of envisaging a new ��.

This capability framework will provide a tool for assisting the organisation to make a wide range of technology investment decisions and change initiatives to achieve its future goals.

Connecting the technology capabilities to the business priorities

The idea of a technology capability framework is not new. In fact, increasingly it is becoming an accepted way of providing a common language between business operations and technology that ensures that business priorities trigger key technology decisions. For instance, offering a more personalised audience experience across all our products and services is a core strategic priority for the ��. By using the capability framework, we can more easily identify where we need to invest in new technology capabilities to provide a content centric view to support this business imperative.

We can also use it to identify opportunities for transformation, discover areas where there is duplication and determine where organisational change needs to happen. For instance, as the �� seeks to reinvent itself for an online-first audience, we are using this framework to establish where technology capabilities need to be transformed to deliver new, flexible solutions to support our strategic goals.

So we have shown how capability modelling can provide a simple, stable view of the business, while creating a common language among decision makers; and, by and large, the business capabilities won’t change significantly over the next two to three years. It is how things get done which really changes.

When we started the strategic analysis 16 months ago, we identified a set of foundations which we believe will need to become imbedded in everything new that we build as part of envisaging a new ��. We didn’t have in our original model the capabilities for Connected Data and Artificial Intelligence and digital ecosystem, as we had not yet identified the importance of these specific capabilities to the organisation’s future. By adding these two capabilities as part of the bedrock of what the �� does, we have been able to identify the need to invest in these technology capabilities. We have already started to establish these new capabilities; for example, in the area of connected data and the establishment of data science and machine learning with the creation of new roles for a head of data architecture within the technology strategy and architecture teams.

Of course, other new things will turn up from time to time. 15 years ago, the personalisation capability would have been very different to what �� Sign In has delivered today. Now, in an internet focused world, it’s the biggest thing that’s changed. The ability to personalise content to engage audiences is now one of the most strategically important goals of media organisations. To enable the �� to offer people the opportunity to discover its products and services in new ways, the organisation needs to develop entirely new ways of working, transforming existing capabilities and establishing the maturity of newly introduced capabilities.

A media framework fit for digital transformation

We hope this framework will be useful for other similar organisations and our partners. We are already using it within Design + Engineering to help assess the current state of our technology capabilities, and define what we need to build and improve to fulfil our objective to drive the digital transformation of the ��.

It is important to remember that capability modelling is a technique for representing an organisation's set of activities, independent of its organisational structure. You’re not going to find the individual �� Divisions listed in this model, which is how it should be.

However, this framework is an endless work in progress. Is there a better way of describing what we do? We would like to open up the debate and get people talking about what are the significant capabilities that a modern media organisation needs to be successful. By sharing this capability model more widely, we hope to get your feedback and suggestions for improvements.

A round up of sound

2018-05-08T11:51:19+00:00

The theme so far this month in the world of �� technology has been Sound, with a showcase event last week at the New Broadcasting House Radio Theatre. Sounds Amazing was a joint production by �� R&D and �� Academy bringing together lots of ideas and demonstrations from the world of audio. Much of it has been written up elsewhere, so here's a brief round-up of some of those highlights and other news.

We learnt more about how spatial audio works and the difference between binaural and object-based sound. And as the summer approaches, soon it will be the Proms with more binaural experiences such as these
There was a demonstration from the Blue Planet 2 sound production team about the scale of sound editing. Each episode has around 170 sound tracks and takes roughly 15 days to edit and mix. There's more on the underwater soundscape here
We heard about �� Radio's ambitions around podcasting, following the recent appointment of a podcast commissioning editor. It's now estimated that 10% of the population are listening to podcasts
Zillah Watson, head of the newly created VR Hub, spoke about some of their recent commissions including the 360 video documentary Damming the Nile. More here on how it was made.
For VR fans, there's also a new immersive tour of the old Alexandra Palace studios, which takes you back to the early days of television
And finally, a sound treat. My colleagues in Archive Development have just released a library of 16,000 sound effects. While still �� copyright, they've available for personal, education or research purposes.

Technology + Creativity at the �������� Feed