There are lots of conferences now in the software testing and delivery industry. In fact, there are far too many for most people to ever make it to. With limited budgets and restricted time many people have to make the hard choice between attending just a handful of conferences.
I believe Nordic Testing Days should be one of those event you definitely try to get to.
This was my second year running and it was epic.
To be fair, I am biased, I was one of the many Keynote speakers, but my view still stands – it’s a great event.
I was lucky enough to do a tutorial and a Keynote and I thoroughly enjoyed both. So a big thank you to Helena and Grete and all of the team behind Nordic Testing Days – you’ve created something really special.
There seems to be a growing problem with DevOps and Marketing not aligning.
So what about DevMOps = Dev + Marketing + Ops
Ok – so we may want to rename it but recently I cannot believe how many conversations I’ve had or heard that were about how continuous delivery DevOps teams and marketing teams are struggling to find a synergy between their objectives, goals and work.
In the Open Spaces at the Pipeline Conference this topic was hotly debated. There were some interesting challenges and ideas put forward, but it did feel like those of us in DevOps obviously had the right solution …I’m not convinced.
So what sorts of problems exist between DevOps and Marketing?
Here’s some examples:
A team releases frequently but their marketing team are not used to this frequency and pace and therefore struggle to keep up. The marketing team don’t know how to effectively message before and after a release as there isn’t much time, or it’s not always clear what is being built. I.e What’s coming up for customers? What’s now available? What can we now sell? What value are we adding to the service/platform/product?
A team releases frequently but some of their customers are unable to use the new changes/features immediately. Who do they market to? How do they differentiate the message? What if marketing don’t want some customers to see the new changes/features? At what point does it go General Availability (GA).
A team releases frequently but the marketing team don’t know how to piece the work together to pitch it as value to their customers. (i.e. The release all contain incremental changes but not big value features).
A team’s marketing and advertising department need to secure the big bang marketing plan, conference spaces and other materials. Hence they need a deadline and commitment to scope. For example, a big video game launch or securing advertising slots well in advance of the feature being available. Some companies have social media campaigns, marketing material, trade shows and other shizzle that they need to do to drive sales to the stuff DevOps are creating. Do they do this after the release, before it (but when is it due) or during the software development?
At the pipeline conference there were some good discussions about this topic. That’s where I created the idea of DevMOps. Dev + Marketing + Ops.
At Pipeline the general feeling was that DevOps needed to CHANGE marketing.
That’s not my view. Why should DevOps change marketing – is there nothing that DevOps needs to change, or do DevOps teams always have everything right?
I know there are marketing conferences happening all over the world where marketers are sat discussing frequent releases and how they can work better with DevOps.
It’s just a shame there are very few conferences where both industries are together talking about this. If you know of any please leave a comment. Sounds like a potential new conference?
At these marketing events you may find marketers talking about frequent releases and how to keep up, infrequent releases or missed deadlines, why DevOps can never give a solid estimate :), and a whole host of other topics associated with Software Development and Delivery.
The only way to solve the problem (if in fact there even is one) is to get all parties talking to each other. The first suggestion would be to avoid assuming that as a DevOps team (we) have the answers. Maybe we do, but at the Pipeline Conference (great conference by the way) it felt like the DevOps guys in the open space discussion knew how to solve the marketing problems, sometimes by simply changing where and how marketing is done. For example, why not just use Twitter to announce when the feature goes live? That’s a great suggestion but what if your customers aren’t on social media, or the person who signs the cheque wants a more formal marketing approach and sales call? Mostly it felt like the problem was the marketing team slowing down DevOps. And that might be true but…
I believe that to address any potential problems between DevOps and Marketing we must start with trust, followed by a conversation.
Trust that the marketing team know what they are doing and that they are indeed good at marketing (I’ve not worked with many that aren’t BTW), trust that the DevOps team know what they are doing, trust that the senior execs and management have hired the right people to grow the business.
If we trust that each department will do the right thing (and that their intentions are good) then getting people together to solve a business problem should be a positive experience. If you don’t have that respect and trust……well….that’s a deeper underlying issue right there…and not one for this post.
By talking with each other the DevMOps team will find out what the real problems are and whether a combined effort would be better than attempting to solve the problems alone (hint – I suspect it will).
One thing we should be careful of though is assuming that we know how to do someone else’s job. I see this often in IT folk and it’s often the root cause of many issues between departments.
If marketing are good at marketing and DevOps are good at providing a continuous service then by talking through the problems you’ll arrive at a synergy. The result…DevMOps.
So, are you having problems with DevOps and Marketing?
How have you solved your problems?
Do your DevOps teams do marketing themselves or include marketing in platform/service roll-out decisions?
Do you have a DevMOps team?
What constraints do you have around your marketing and deployment?
I loved my time as a scrum master. It was an interesting and rewarding role.
But being a scrum master mostly sucks. And here’s why.
1. You spend more money than you earn on stationery
Post-it notes, sharpies, blu-tack, index cards, pens, pencils, stickers, badges, dry wipe markers – the list is endless. You’re not able to walk past a stationery shop without at least looking in.
You spend more time working out the right stationery to use than actually doing the job. You buy a Moleskine notebook just because it feels “right” and then proceed to fill it with bad handwriting and stationery shopping lists.
You justify the expense. You tell yourself that it will make you more productive. It doesn’t.
You spend time making your Kanban boards neat and tidy. You chastise the team for using the wrong colour sticky note. You apply dot voting at every conceivable meeting. You even end up buying a special stationery container or toolbox.
You become (or already are) a stationery freak.
2. If you do your job well people think you’re not needed
As soon as you start to do your job well and the team start trucking along you’ll soon have questions asked about how useful or relevant you are to the team. The team seem to no longer need you. The process is working. You’ve outstayed your welcome.
So the team go it alone. Then they realise the value someone doing the role of Scrum Master adds. So they rotate the role around their team or plead for you to come back. The more impressive your ability to get the team trucking, the more questions that are asked about your usefulness. That sucks.
3. You’re constantly having to learn more about humans
Your job as a scrum master is to help the team work well together. This is hard. Humans are strange and unpredictable. They have feelings, emotions and relationships. They don’t act the same way all of the time. This is annoying.
This leads good scrum masters down the path of self awareness and self learning. They seek out knowledge and self understanding of how they interact, how the team interact and how to help teams perform well.
Good scrum masters learn about motivation, communication, behavioural economics and a whole host of other social science related work. This leads you to try and understand more than is humanly possible. But you try. Then you get a headache, then you realise how little you know, then you have to lie down, then you realise that being a scrum master sucks.
4. Your obsession with process bleeds in to your personal life
When you’re really on top of your game you start to see “process” everywhere. You start to visualise these processes, map these processes out, improve these processes and then automate these processes. This is fine – but you start to try this in every aspect of your personal life, from your children’s teeth brushing routine to your food shopping.
You start to annoy everyone in your life with your constant process analysis and you start to alienate the very people you’re trying to help by improving the “process”.
It becomes an obsession and you can’t help yourself. It now sucks to be you outside of work.
5. You end up having to do everything that unblocks the team
Eventually you start to do everything possible to unblock the team and keep them trucking. You take the servant leader to heart and start making your team drinks, cleaning whiteboards and offering to drive your team around. You get lunch for the team and buy them cakes every day.
Fairly soon your team can’t even function as humans without you. At which point it sucks even more to be a scrum master. Not only do you have to look after yourself but now the team.
6. You’re always having to justify why agile works (even when it is working)
Even when software is going out of the door, your customers are getting features and the team are happy you’ll still have to justify to everyone why agile works.
It’s just part of the job – constant and unwavering defense of agile – at all times, always.
7. You have to stop people trying to increase velocity by x% month on month
After you first release your velocity point metrics you have to start defending against claims that the velocity is not increasing very much sprint on sprint.
“It was 10 last week and it’s 10 this week. It was 12 the week before that and 9 the week before that one. Why are you not getting better? Why is velocity not going up?”
8. You’re always having to re-invent fun ways of engaging people in doing a retro
It sucks being a scrum master especially when you turn up to the retrospective to find your team sat there looking sad…and angry….and bored.
It sucks constantly having to come up with new games to play in a retro to get people even mildly excited about talking about what went well during the sprint.
9. Your artistic talents are constantly being “criticised”
At every possible moment in time you will want to draw something, it’s a natural urge for scrum masters. You’ve already heavily invested in books about sketch-noting. You’ve bought Moleskines and Sharpies and now you’re keen to show off your artistic talents.
The problem is your drawing still sucks. And now you can’t help yourself but to draw at all opportunities. So you’re artistic talents are forever attracting critique, comments and ridicule.
10. Your reading list is too long
If you’re serious about your career then you’ll take self learning very seriously indeed. At some point you will have at least 2 million books on your reading list, 3000 RSS subscriptions and be following 4 million agile experts on Twitter (yes there are that many…possibly). All of which will mean your head hurts constantly and you feel like you’re missing out on stuff.
11. You have to get used to people calling you names
As you progress in your career you have to start embracing the fact that people will call you names. Don’t get me wrong – people are not being malicious – they just find it funny to come up with names for someone who isn’t really needed on the team anyway.
Expect some of the following:
Scrum Dawg Millionaire, Scrummy, Scrumling, Servant Leader, Project Manager (damn that one hurts), Scrum Rockster, Scrumstar, scrummer, scummy and a whole host of others.
Joking aside the role of scrum master is epically good fun, especially so when you do it at a company like NewVoiceMedia.
THIS POSITION HAS NOW BEEN FILLED
Right now we’re hiring for a talented scrum master who is wanting to expand their world. We’re not after a seasoned pro – we’re after someone who is open to learning from talented peers, who is keen to find themselves in an environment that truly nurtures self learning and who is keen to work for a company making massive strides in the industry. Maybe you’ve reached your peak where you are and you want to take on some more challenges?
Maybe you’re starting out as a scrum master and looking for somewhere to grow your experience?
If you like stationery:
If you can help to create self organised teams:
If you’re keen to learn more about social science, agile process and human behaviour:
If you find yourself creating personal Kanban, use process flow techniques in your own life and live and breath agile:
If you’re happy mucking in and helping the team out by doing work the team needs doing:
If you’re a true evangelism for the common sense approach to agile (i.e. what do our customers need us to do):
If you’re truly interested in measuring (qualitatively and quantitatively) the improvements your team are making (and not just relying on velocity):
If you’re interested in finding fun ways to learn, communicate and share:
If you’re not afraid to make mistakes, share your ideas and be open to feedback :
If you’re already battling a growing reading list:
And if you’re happy to step outside of the frame of scrum master and fix the problems & capitalise on the opportunities that exist in the space and work between roles:
Then please get in touch. We’d like you to consider joining us at NewVoiceMedia.
THIS POSITION HAS NOW BEEN FILLED
And even if you’re not doing any of the above but it lights your fire to think of working in this way, then get in touch also.
If you’re interested in joining us either email me at firstname.lastname@example.org or visit our recruitment page to find further application details.
We’re keen to hire someone who isn’t waiting for permission to do the right thing for our customers. We’re keen to hire someone who will do the work our customers need us to and not do just the work a job spec may say somewhere.
Ultimately, we’re keen to hire a scrum master who just gets that shipping software and delighting customers is our number one aim.
If that’s you, and you can work in Basingstoke, Hampshire, UK, then please get in touch…even if “scrum master” is not your current job title.
*Despite some of the challenges being a scrum master it is actually a really fun job. It’s a great role to have but like most roles, it’s not without some stereotypical aspects to it – I’ve highlighted those here in this post.