Ep 11: There’s No I In Team

(But There Is In Chris)

Today’s recording is a bit echoey, and that’s because I recorded this episode at a venue called Madlab, who very kindly lent me a room for this interview.

This episode is an interview with Chris Northwood, who is Lead Dev as BBC Connected Studios, working on a fantastic project called BBC Taster.

Disclaimer: Chris is talking to me in a personal capacity, not on behalf of or representing the BBC.

We talk about how software development works in the BBC , and Chris’ team in particular, and the benefits of having QA embedded in a Scrum team.

Chris Northwood co-runs Manchester Tech Nights, a meetup aimed at Manchester’s technology community, and happens every other month. Find out more by going to http://manchestertechnights.org/.

Find Chris on twitter @cnorthwood

Ep 10: Crouch, Touch, Pause, Engage

Or, Scrum Mastery

Ok, so I’m going to talk about organising things and being scrum master. So, in the interests of transparency; I’ve not had any training or certification and we use a Scrum-influenced Agile methodology, but tweaked for our needs as a company.

I am scrum master/in charge of organising sprints across a few projects who have small sprints of work every month, so again, its part time scrum mastery and part time QA, and not full on Scrum Master role.

So firstly, what is a Scrum Master? A Scrum Master is accountable for removing impediments to work or the team. They ensure the team can deliver work and product goals.

They do this in a number of ways, including keeping up to date with the team using regular check ins (including daily scrums), training stakeholders and product owners in scrum processes and workflows, help the product owner maintain a healthy backlog of items to ensure the project velocity is maintained, promoting organisation, things like that.

I tried to relate the concept of scrum to scrummage – In rugby a scrum refers to a tight-packed formation of players with their heads down who attempt to gain possession of the ball. The players lock together and move forward as one against the opposing team. There are now four commands a referee gives when arranging a scrum: crouch, touch, pause, engage, and I think you can sort of apply that to the software scrum process.

Crouch: This is when everyone gets ready – the product owners are prioritising the backlog, the developers are estimating any new work that’s come into the backlog.

Touch: Sprint Planning meeting

Pause: Time for approval of AC by client, any technical planning the devs need to do. We aim to get this done by the ‘Touch’ phase, so sometimes this is an actual pause so devs/QA/etc can clear up anything else on other projects in preparation for the next phase.

Engage: Work starts

(after that the analogy falls over, as most analogies do after a while).

The difference between a Scrum Master and a Project Manager is that of people management. While I manage the project, I do not manage the people. True Scrum setups do not have a project manager role, as the idea is to promote self management, whereas generally teams report to project managers. And this is the case with our set up – the team does not report to me, I don’t manage them, I help schedule their time in as needed with our Operations Manager, but that’s as far as it goes.

To be a Scrum master is to be very servant-leader-y – you have to make sure the work is being done, and you have to ensure any impediments to that are out of the way. So you’re both being told what’s needed and need to tell people what needs to get done. I also ensure that the process is being adhered to, which can be a challenge. I’ve had to get both developers and clients on board with doing things this new way.

I like doing, I enjoy being a facilitator because I’m good at it, and I enjoy organising things and getting ducks in rows for people, and its a role I’m constantly learning in, there’s always new ways to communicate with people and explain hows and whys, there’s always a project that has different needs (a project where the product owner is the sole person in charge of the website has different needs to the product owner who has many stakeholders feeding into the priorities and work that needs to be carried out). And this feeds into planning, some product owners will need more warning about upcoming sprint planning meetings so they can check with their multiple stakeholders about priorities.

I like the challenge of it all, making it all fit, being both strict enough to meet resourcing needs, but still trying to fit the Agile/Scrum way of thinking and working.

The context I get from knowing the business as a Scrum Master make me better at writing AC and testing.

Being a Scrum Master – as untrained as I am – is something I really enjoy, and it’s an area I’m always looking for things to read and learn about. Its a complex set of skills, and I am constantly learning. I’m hoping its something I can continue to learn and get better at as time goes on.

Further Reading:
http://scrummethodology.com/the-scrummaster-role/
https://en.wikipedia.org/wiki/Scrum_(software_development)#Scrum_master

Ep 8: Rage Against the QA

This week I talk to Mike Bell, Drupal Dev, friend, and colleague about the relationship between QA, Dev, and Client.

We talk about how QAs and Devs think differently, reporting bugs to devs, writing AC, and the affect of planetary movements on testing. I also try and fail to remember the term Galumphing and James Bach, the name of the person who coined it.

Mike Bell can be found on Mike Bell, and will be talking at PHPNW15 this year. He’s previously spoken at NWDUG and various Drupal Camps.

In between recording this episode and posting it, its been announced that Mike will be talking as part of a keynote at DrupalCamp Barcelona! Read more about his talk here: https://events.drupal.org/barcelona2015/sessions/mental-health-and-open-source