The fantastic Feminist Frequency channel on YouTube recently shared the two videos embedded below. They talk about how games use women as background decoration- sexualised and abused non-playable characters.
These aren’t just videos and ideas relevant to people working in the games industry or playing games, but for everyone; they bring to life themes relevant to all of us, but possibly seldom consider.
Bringing agile ways of working to teams comprised entirely of people focused on business (ie. the non-tech folk) is a challenge. It’s notoriously hard to do, because the kind of work that’s undertaken isn’t easily shared, paired on, broken into sprint or sub-sprint length tasks. It’s not impossible, though. Here’s some of my experience (a work in progress).
Bringing agile ways of working to a team used to waterfall methodologies, reporting, and documentation will never happen overnight. Prepare to be very, very patient.
Understand the journey
Start by understanding what it is you want to achieve by bringing agile to your team. It’s not a magic pill that suddenly makes you more efficient, not by a long shot. Take a look at the things you aren’t doing well as a team, examine the reasons why that’s so, and then objectively evaluate whether or not practices from the world of agile delivery are even appropriate. They may not be, and certainly don’t assume that an ‘all or nothing’ approach will work.
What’s not so great? On joining a team there was a very clear structure (in terms of org chart) and clear reporting lines. Roles were well defined, but largely in silos. As a result collaboration wasn’t great, and nor was communication. Earphones were often in use throughout the day.
What’s the cause? Having a formal hierarchy and roles in silos makes it very difficult to collaborate. Visibility is poor, and so opportunities to contribute don’t exist.
What’s the agile journey? A full roll out of a formal agile methodology isn’t needed, but bits of one are useful.
Create visibility by employing some kind of information radiator (eg. JIRA). Create a space to interact by reviewing stories (eg. Backlog grooming). Create a collaborative environment by showcasing work and inviting discussion (eg. Monthly showcases).
One of the things on my mind a lot right now is ‘culture’. What kind of work environments do I thrive in? What’s important to me? What kind of values do people think are important to me, and do I live them? What values are important to those around me and the company I work for? Do I respect those values? Do I agree?
Lots of pondering, I’m sure you’ll see.
In my research I came across this great post on SlideShare, Culture from Reed Hastings. It’s all about culture and values at Netflix. It’s inspiring how simple they are, how much confidence is placed in people, and how these aren’t just buzzwords, but rather lived and meaningful values.
The art of the random is the art of beleaguering business analysts, without a shadow of a doubt. I can analyse something to within an inch of its life, build the most exquisite operational process, and still fail. Why? Because the more randomness a system allows, the more difficult a process is to define (or, at least, control).
Candy Crush (along with a lot of the games we produce at King) introduces a lot of random behaviour to the process, because that’s the game’s secret sauce (or is that ‘secret candy’?). I want to share some of the challenges folk in a similar situation face because of this, and how we can [try to] overcome them.
So, what kind of randomness are we talking about?
The idea of ‘reporting’ is disgusting and pervasive. I hate it.
That’s not to say that there isn’t a place for governance and oversight. I’m not about to argue against that. I’m talking about the idea of reporting driven development, the idea of a ‘status meeting’. I’m talking about the idea that you are being watched.
Now, if you’re on a project where your development, targets, and daily work are driven by reporting your status something is, in my humble opinion, wrong. It’s an indicator to me that you are concentrating decision making authority for too much to too few. It’s an indicator that your team feels ‘watched’. It tells me that at a fundamental level the communication on that project is broken.